aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-07-16gdb: fix issues with handling DWARF v5 rnglists & .dwo files.Caroline Tice5-48/+398
While experimenting with GDB on DWARF 5 with split debug (dwo files), I discovered that GDB was not reading the rnglist index properly (it needed to be reprocessed in the same way the loclist index does), and that there was no code for reading rnglists out of dwo files at all. Also, the rnglist address reading function (dwarf2_rnglists_process) was adding the base address to all rnglist entries, when it's only supposed to add it to the DW_RLE_offset_pair entries (http://dwarfstd.org/doc/DWARF5.pdf, p. 53), and was not handling several entry types. - Added 'reprocessing' for reading rnglist index (as is done for loclist index). - Added code for reading rnglists out of .dwo files. - Added several missing rnglist forms to dwarf2_rnglists_process. - Fixed bug that was alwayas adding base address for rnglists (only one form needs that). - Updated dwarf2_rnglists_process to read rnglist out of dwo file when appropriate. - Added new functions cu_debug_rnglist_section & read_rnglist_index. - Added new testcase, dw5-rnglist-test.{cc,exp} Special note about the new testcase: In order for the test case to test anything meaningful, it must be compiled with clang, not GCC. The way to do this is as follows: $ make check RUNTESTFLAGS="CC_FOR_TARGET=/path/to/clang CXX_FOR_TARGET=/path/to/clang++ dw5-rnglist-test.exp" This following version of clang was used for this testing: clang version 9.0.1-11 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin Change-Id: I3053c5ddc345720b8ed81e23a88fe537ab38748d
2020-07-16[gdb/testsuite] Add pseudo line number program instruction: lineTom de Vries8-99/+100
There's an idiom in dwarf assembly test-cases: ... set line1 [gdb_get_line_number "line 1"] set line2 [gdb_get_line_number "line 2"] set line3 [gdb_get_line_number "line 3"] ... {DW_LNS_advance_line [expr $line1 - 1]} ... {DW_LNS_advance_line [expr $line2 - $line1]} ... {DW_LNS_advance_line [expr $line3 - $line2]} ... Add a pseudo line number program instruction "line", such that we can simply write: ... {line $line1} ... {line $line2} ... {line $line3} ... Build and reg-tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-16 Tom de Vries <tdevries@suse.de> * lib/dwarf.exp (program): Initialize _line. (DW_LNE_end_sequence): Reinitialize _line. (DW_LNS_advance_line): Update _line. (line): New proc. * gdb.dwarf2/dw2-inline-many-frames.exp: Use line. * gdb.dwarf2/dw2-inline-small-func.exp: Same. * gdb.dwarf2/dw2-inline-stepping.exp: Same. * gdb.dwarf2/dw2-is-stmt-2.exp: Same. * gdb.dwarf2/dw2-is-stmt.exp: Same. * gdb.dwarf2/dw2-ranges-func.exp: Same.
2020-07-16Automatic date update in version.inGDB Administrator1-1/+1
2020-07-15gdb/testsuite: Update test pattern in ptype-on-functions.expAndrew Burgess2-1/+6
It was pointed out that the recently added test gdb.fortran/ptype-on-functions.exp fails on older versions of gfortran. This is because the ABI for passing string lengths changed from a 4-byte to 8-byte value (on some targets). This change is documented here: https://gcc.gnu.org/gcc-8/changes.html. Character variables longer than HUGE(0) elements are now possible on 64-bit targets. Note that this changes the procedure call ABI for all procedures with character arguments on 64-bit targets, as the type of the hidden character length argument has changed. The hidden character length argument is now of type INTEGER(C_SIZE_T). This commit just relaxes the pattern to accept any size of integer for the string length argument. gdb/testsuite/ChangeLog: * gdb.fortran/ptype-on-functions.exp: Make the result pattern more generic.
2020-07-15x86: Don't display eiz with no scaleH.J. Lu6-14/+28
Change 67 48 8b 1c 25 ef cd ab 89 mov 0x89abcdef(,%eiz,1),%rbx to 67 48 8b 1c 25 ef cd ab 89 mov 0x89abcdef,%rbx in AT&T syntax and 67 48 8b 1c 25 ef cd ab 89 mov rbx,QWORD PTR [eiz*1+0x89abcdef] to 67 48 8b 1c 25 ef cd ab 89 mov rbx,QWORD PTR ds:0x89abcdef in Intel syntax. gas/ PR gas/26237 * testsuite/gas/i386/evex-no-scale-64.d: Updated. * testsuite/gas/i386/addr32.d: Likewise. * testsuite/gas/i386/x86-64-addr32-intel.d: Likewise. * testsuite/gas/i386/x86-64-addr32.d: Likewise. opcodes/ PR gas/26237 * i386-dis.c (OP_E_memory): Don't display eiz with no scale without base nor index registers.
2020-07-15Fix the generation of relocs for missing build notes.Nick Clifton2-9/+24
* write.c (create_note_reloc): Add desc2_size parameter. Zero out the addend field of REL relocations. Store the full addend into the note for REL relocations.
2020-07-15PR26239, memory leak in _bfd_dwarf2_slurp_debug_infoAlan Modra2-4/+15
PR 26239 * coffgen.c (_bfd_coff_close_and_cleanup): Free dwarf2 info.
2020-07-15Fix an illegal memory access in the BFD library which can be triggered by ↵Nick Clifton2-1/+7
attempting to parse a corrupt PE format file. PR26240 * coffgen.c (coff_get_normalized_symtab): Fix off-by-one error in check for aux entries that overflow the buufer.
2020-07-15[gdb/testsuite] Handle callq -> call disassembly changeTom de Vries2-2/+5
We're currently running into: ... FAIL: gdb.trace/entry-values.exp: disassemble bar ... Since commit 36938cabf0 "x86: avoid attaching suffixes to unambiguous insns", "callq" is disassembled as "call", and the test-case expects "callq". Fix this by expecting "call" instead. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-15 Tom de Vries <tdevries@suse.de> * gdb.trace/entry-values.exp: Expect "call" instead of "callq" if is_amd64_regs_target.
2020-07-15gdb/fortran: Handle dynamic string types when printing typesAndrew Burgess5-4/+47
After commit: commit 8c2e4e0689ea244d0ed979171a3d09c9176b8175 Date: Sun Jul 12 22:58:51 2020 -0400 gdb: add accessors to struct dynamic_prop An existing bug was exposed in the Fortran type printing code. When GDB is asked to print the type of a function that takes a dynamic string argument GDB will try to read the upper bound of the string. The read of the upper bound is written as: if (type->bounds ()->high.kind () == PROP_UNDEFINED) // Treat the upper bound as unknown. else // Treat the upper bound as known and constant. However, this is not good enough. When printing a function type the dynamic argument types will not have been resolved. As a result the dynamic property is not PROP_UNDEFINED, but nor is it constant. By rewriting this code to specifically check for the PROP_CONST case, and treating all other cases as the upper bound being unknown we avoid incorrectly treating the dynamic property as being constant. gdb/ChangeLog: * f-typeprint.c (f_type_print_base): Allow for dynamic types not being resolved. gdb/testsuite/ChangeLog: * gdb.fortran/ptype-on-functions.exp: Add more tests. * gdb.fortran/ptype-on-functions.f90: Likewise.
2020-07-15x86: move putop() case labels to restore alphabetic sortingJan Beulich2-49/+52
... as far as non-fall-through behavior permits.
2020-07-15x86: make PUSH/POP disassembly uniformJan Beulich2-30/+27
Irrespective of their encoding the resulting output should look the same. Therefore wire the handling of PUSH/POP with GPR operands encoded in the main opcode byte to the same logic used for other operands. This frees up yet another macro character.
2020-07-15x86-64: adjust stack insn test caseJan Beulich5-17/+25
The value chosen for the 16-/32-bit immediate cases didn't work well with the subsequent insn's REX prefix - we ought to pick a value the upper two bytes of which evaluate to a 2-byte insn. Bump the values accordingly, allowing the subsequent insn to actually have the intended REX.W.
2020-07-15x86: avoid attaching suffixes to unambiguous insnsJan Beulich196-1170/+1308
"Unambiguous" is is in particular taking as reference the assembler, which also accepts certain insns - despite them allowing for varying operand size, and hence in principle being ambiguous - without any suffix. For example, from the very beginning of the life of x86-64 I had trouble understanding why a plain and simple RET had to be printed as RETQ. In case someone really used the 16-bit form, RETW disambiguates the two quite fine.
2020-07-15mmix bfd: fix bfd_assert for R_MMIX_PUSHJ_STUBBABLE against undef'd symbolHans-Peter Nilsson7-5/+24
Spotted when inspecting gcc testsuite logs, but this already is covered by the ld-mmix testsuite, it's just that the assert is ignored since the regexp match is for a substring and not anchored. With the anchors added but not the bugfix, the ld.log shows that the asserts cause a non-match as intended: Executing on host: sh -c {./ld-new -LX/src/ld/testsuite/ld-mmix -m elf64mmix -o tmpdir/dump tmpdir/undef-2.o tmpdir/start.o 2>&1} /dev/null dump.tmp (timeout = 300) ./ld-new: BFD (GNU Binutils) 2.34.50.20200629 assertion fail X/src/bfd/elf64-mmix.c:2845 ./ld-new: BFD (GNU Binutils) 2.34.50.20200629 assertion fail X/src/bfd/elf64-mmix.c:2845 ./ld-new: BFD (GNU Binutils) 2.34.50.20200629 assertion fail X/src/bfd/elf64-mmix.c:2845 ./ld-new: tmpdir/undef-2.o:(.text+0x0): undefined reference to `undefd' failed with: <./ld-new: BFD (GNU Binutils) 2.34.50.20200629 assertion fail X/src/bfd/elf64-mmix.c:2845 ./ld-new: BFD (GNU Binutils) 2.34.50.20200629 assertion fail X/src/bfd/elf64-mmix.c:2845 ./ld-new: BFD (GNU Binutils) 2.34.50.20200629 assertion fail X/src/bfd/elf64-mmix.c:2845 ./ld-new: tmpdir/undef-2.o:(.text+0x0): undefined reference to `undefd'>, expected: <\A[^\n\r]*undefined reference to `undefd'\Z> FAIL: ld-mmix/undef-2 Gone with the fix of course, leaving just the intended "undefined reference" like. I'm not going to add anchors manually for all the "error:" strings in the test-suite, not even in the mmix parts. Sorry, but I'll just do it for *these* specific undefined-reference tests. Just a thought: maybe the run_dump_test "error:" string should *automatically* get anchor marks prepended and appended for a single line match as in the patch, "\A[^\n\r]*" prepended and \Z appended unless either anchor mark or \r or \n is present in the regexp? Committed. bfd: * elf64-mmix.c (mmix_elf_relax_section): Improve accounting for R_MMIX_PUSHJ_STUBBABLE relocs against undefined symbols. ld/testsuite: * testsuite/ld-mmix/undef-1.d, testsuite/ld-mmix/undef-1m.d, testsuite/ld-mmix/undef-2.d, testsuite/ld-mmix/undef-2m.d: Add start- and end-anchors to error-string to match just a single-line error-message.
2020-07-14gdb/testsuite/lib/dwarf.exp: fix addr_size parameter commentsSimon Marchi2-3/+8
The comments modified in this patch claim that the addr_size parameters can take the value 32 or 64 (suggesting the value is in bits). In fact, the expected value is in bytes, either 4 or 8. The actual value in the DWARF info is in bytes. And we can see that the default values used (if addr_size == "default") are: if {$_cu_addr_size == "default"} { if {[is_64_target]} { set _cu_addr_size 8 } else { set _cu_addr_size 4 } } gdb/testsuite/ChangeLog: * lib/dwarf.exp (Dwarf::cu, Dwarf::tu, Dwarf::lines): Change valid values in documentation for addr_size to 4 and 8. Change-Id: I4a02dca2bb7992198864e545ef099f020f54ff2f
2020-07-15Automatic date update in version.inGDB Administrator1-1/+1
2020-07-15PR26198 MinGW failure to link regular object file and LTO object fileMarkus Böck3-2/+12
PR 26198 * coffgen.c (_bfd_coff_section_already_linked): Allow for plugin objects both before and after normal object files. * elflink.c (_bfd_elf_section_already_linked): Likewise.
2020-07-14x86-64: Zero-extend lower 32 bits displacement to 64 bitsH.J. Lu10-56/+61
Since the addr32 (0x67) prefix zero-extends the lower 32 bits address to 64 bits, change disassembler to zero-extend the lower 32 bits displacement to 64 bits when there is no base nor index registers. gas/ PR gas/26237 * testsuite/gas/i386/addr32.s: Add tests for 32-bit wrapped around address. * testsuite/gas/i386/x86-64-addr32.s: Likewise. * testsuite/gas/i386/addr32.d: Updated. * testsuite/gas/i386/x86-64-addr32-intel.d: Likewise. * testsuite/gas/i386/x86-64-addr32.d: Likewise. * testsuite/gas/i386/ilp32/x86-64-addr32-intel.d: Likewise. * testsuite/gas/i386/ilp32/x86-64-addr32.d: Likewise. opcodes/ PR gas/26237 * i386-dis.c (OP_E_memory): Without base nor index registers, 32-bit displacement to 64 bits.
2020-07-14gdb: Improve formatting of 'show endian' messagesAndrew Burgess3-23/+23
This commit changes the output of 'show endian'. Here is a session before this commit: (gdb) show endian The target endianness is set automatically (currently little endian) (gdb) set endian big The target is assumed to be big endian (gdb) show endian The target is assumed to be big endian (gdb) After this commit the session now looks like this: (gdb) show endian The target endianness is set automatically (currently little endian). (gdb) set endian big The target is set to big endian. (gdb) show endian The target is set to big endian. (gdb) The changes are: 1. Each line ends with '.', and 2. After setting the endianness GDB is now a little more assertive; 'target is set to' not 'target is assumed to be', the user did just tell us after all!
2020-07-14gdb: Improve formatting of 'show architecture' messagesAndrew Burgess12-20/+36
This commit changes the output of 'show architecture'. Here is a session before this commit: (gdb) show architecture The target architecture is set automatically (currently i386) (gdb) set architecture mips The target architecture is assumed to be mips (gdb) show architecture The target architecture is assumed to be mips (gdb) After this commit the session now looks like this: (gdb) show architecture The target architecture is set to "auto" (currently "i386"). (gdb) set architecture mips The target architecture is set to "mips". (gdb) show architecture The target architecture is set to "mips". (gdb) The changes are: 1. The value is now enclosed in quotes, 2. Each line ends with '.', and 3. After setting the architecture GDB is now a little more assertive; 'architecture is set to' not 'is assumed to be', the user did just tell us after all! gdb/ChangeLog: * arch-utils.c (show_architecture): Update formatting of messages. gdb/testsuite/ChangeLog: * gdb.arch/amd64-osabi.exp: Update. * gdb.arch/arm-disassembler-options.exp: Update. * gdb.arch/powerpc-disassembler-options.exp: Update. * gdb.arch/ppc64-symtab-cordic.exp: Update. * gdb.arch/s390-disassembler-options.exp: Update. * gdb.base/all-architectures.exp.tcl: Update. * gdb.base/attach-pie-noexec.exp: Update. * gdb.base/catch-syscall.exp: Update. * gdb.xml/tdesc-arch.exp: Update.
2020-07-14arc: Detect usage of illegal double register pairsClaudiu Zissulescu5-3/+27
ARC can use odd-even double register pairs in some selected instructions. Although the GNU assembler doesn't allow even-odd registers to be used, there may be cases when the disassembler is presented with such situation. This patch add a test and detects such cases. opcodes/ 2020-07-14 Claudiu Zissulescu <claziss@gmail.com> * arc-dis.c (print_insn_arc): Detect and emit a warning when a faulty double register pair is detected. binutils/ 2020-07-14 Claudiu Zissulescu <claziss@gmail.com> * testsuite/binutils-all/arc/double_regs.s: New test. * testsuite/binutils-all/arc/objdump.exp: Add the above test. Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
2020-07-14x86/Intel: debug registers are named DRnJan Beulich7-8/+19
%db<n> is an AT&T invention; the Intel documentation and MASM have only ever specified DRn (in line with CRn and TRn). (In principle gas also shouldn't accept the names in Intel mode, but at least for now I've kept things as they are. Perhaps as a first step this should just be warned about.)
2020-07-14x86: drop Rm and the 'L' macroJan Beulich2-74/+67
Rm (and hence OP_R()) can be dropped by making 'Z' force modrm.mod to 3 (for OP_E()) instead of ignoring it. While at it move 'Z' handling to its designated place (after 'Y'; 'W' handling will be moved by a later change). Moves to/from TRn are illegal in 64-bit mode and thus get converted to honor this at the same time (also getting them in line with moves to/from CRn/DRn ModRM.mod handling wise). This then also frees up the L macro.
2020-07-14x86: drop Rdq, Rd, and MaskRJan Beulich6-63/+122
Rdq, Rd, and MaskR can be replaced by Edq, Ed / Rm, and MaskE respectively, as OP_R() doesn't enforce ModRM.mod == 3, and hence where MOD matters but hasn't been decoded yet it needs to be anyway. (The case of converting to Rm is temporary until a subsequent change.)
2020-07-14x86: simplify decode of opcodes valid only without any (embedded) prefixJan Beulich2-135/+61
In this case there's no need to go through prefix_table[] at all - the .prefix_requirement == PREFIX_OPCODE machinery takes care of this case already. A couple of further adjustments are needed though: - Gv / Ev and alike then can't be used (needs to be Gdq / Edq instead), - dq_mode and friends shouldn't lead to PREFIX_DATA getting set in used_prefixes.
2020-07-14x86: also use %BW / %DQ for kshift*Jan Beulich2-65/+35
2020-07-14[gdb/testsuite] Fix clone-new-thread-event.c with glibc 2.30Tom de Vries2-2/+8
Starting glibc 2.30, unistd.h declares gettid (for _GNU_SOURCE). This clashes with a static gettid in test source clone-new-thread-event.c: ... gdb compile failed, gdb.threads/clone-new-thread-event.c:46:1: error: \ static declaration of 'gettid' follows non-static declaration 46 | gettid (void) | ^~~~~~ In file included from /usr/include/unistd.h:1170, from gdb.threads/clone-new-thread-event.c:27: /usr/include/bits/unistd_ext.h:34:16: note: previous declaration of 'gettid' \ was here 34 | extern __pid_t gettid (void) __THROW; | ^~~~~~ ... Fix this by renaming the static gettid to local_gettid. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-14 Tom de Vries <tdevries@suse.de> * gdb.threads/clone-new-thread-event.c (gettid): Rename to ... (local_gettid): ... this. (fn): Update.
2020-07-14x86: simplify decode of opcodes valid with (embedded) 66 prefix onlyJan Beulich10-4917/+1655
The only valid (embedded or explicit) prefix being the data size one (which is a fairly common pattern), avoid going through prefix_table[]. Instead extend the "required prefix" logic to also handle PREFIX_DATA alone in a table entry, now used to identify this case. This requires moving the (adjusted) ->prefix_requirement logic ahead of the printing of stray prefixes, as the latter needs to observe the new setting of PREFIX_DATA in used_prefixes. Also add PREFIX_OPCODE on related entries when previously there was mistakenly no decode step through prefix_table[].
2020-07-14x86: drop further EVEX table entries that can be served by VEX onesJan Beulich4-42/+25
A few cases were missed by 6df22cf64c93 ("x86: drop EVEX table entries that can be served by VEX ones").
2020-07-14x86: drop need_vex_regJan Beulich3-53/+41
It was quite odd for the prior operand handling to have to clear this flag for the actual operand handling to print nothing. Have the actual operand handling determine whether the operand is actually present. With this {d,q}_scalar_swap_mode become unused and hence also get dropped.
2020-07-14x86: drop Vex128 and Vex256Jan Beulich3-56/+65
These are only used when VEX.L or EVEX.L'L have already been decoded, and hence the "normal" length dependent name determination is quite fine. Adjust a few enumerators to make clear that vex_len_table[] has been consulted; be consistent and do so for all *f128 and *i128 insns in one go.
2020-07-14x86: replace %LW by %DQJan Beulich4-52/+59
This makes more visible what the two alternatives will be that result from this macro.
2020-07-14x86: merge/move logic determining the EVEX disp8 shiftJan Beulich2-29/+23
Fold redundant case blocks and move the extra adjustments logic into the single case block that actually needs it - there's no need to go through the extra logic for all the other cases. Also utilize there that vex.b cannot be set at this point, due to earlier logic. Reduce the comment there, which was partly stale anyway.
2020-07-14x86: extend %BW use to VP{COMPRESS,EXPAND}{B,W}Jan Beulich4-24/+22
Unlike the earlier ones these also need their operands adjusted. Replace the (mis-described: there's nothing "scalar" here) {b,w}_scalar_mode by a single new mode, with the actual unit width controlled by EVEX.W.
2020-07-14x86-64: fix {,V}PCMPESTR{I,M} disassembly in Intel modeJan Beulich7-47/+44
The operands don't allow disambiguating the insn in 64-bit mode, and hence suffixes need to be emitted not just in AT&T mode. Achieve this by re-using %LQ while dropping PCMPESTR_Fixup().
2020-07-14x86: fold VCMP_Fixup() into CMP_Fixup()Jan Beulich4-74/+58
There's no reason to have two functions and two tables, when the AVX functionality here is a proper superset of the SSE one.
2020-07-14x86: don't disassemble MOVBE with two suffixesJan Beulich6-43/+69
MOVBE_Fixup() is entirely redundant with the S macro already used on the mnemonics, leading to double suffixes in suffix-always mode. Drop the function.
2020-07-14x86: avoid attaching suffix to register-only CRC32Jan Beulich35-750/+171
Just like other insns with GPR operands, CRC32 with only register operands should not get a suffix added unless in suffix-always mode. Do away with CRC32_Fixup() altogether, using other more generic logic instead.
2020-07-14x86-64: don't hide an empty but meaningless REX prefixJan Beulich7-13/+36
Unlike for non-zero values passed to USED_REX(), where rex_used gets updated only when the respective bit was actually set in the encoding, zero getting passed in is not further guarded, yet such a (potentially "empty") REX prefix takes effect only when there are registers numbered 4 and up.
2020-07-14x86: drop dead code from OP_IMREG()Jan Beulich5-40/+24
There's only a very limited set of modes that this function gets invoked with - avoid it being more generic than it needs to be. This may, down the road, allow actually doing away with the function altogether. This eliminates a first improperly used "USED_REX (0)".
2020-07-14x86-64: fold ILP32 test expectationsJan Beulich17-7806/+36
Various of the test expectations get adjusted later in this and a subsequent series, so in order to avoid having to adjust more instances than necessary fold respective test ILP32 expectations with their main 64-bit counterparts where they're identical anyway.
2020-07-13gdbserver: fix memory leak when handling qsupported packetSimon Marchi5-41/+42
When building gdbserver with AddressSanitizer, I get this annoying little leak when gdbserver exits: ==307817==ERROR: LeakSanitizer: detected memory leaks Direct leak of 14 byte(s) in 1 object(s) allocated from: #0 0x7f7fd4256459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x563bef981b80 in xmalloc /home/simark/src/binutils-gdb/gdbserver/../gdb/alloc.c:60 #2 0x563befb53301 in xstrdup /home/simark/src/binutils-gdb/libiberty/xstrdup.c:34 #3 0x563bef9d742b in handle_query /home/simark/src/binutils-gdb/gdbserver/server.cc:2286 #4 0x563bef9ed0b7 in process_serial_event /home/simark/src/binutils-gdb/gdbserver/server.cc:4061 #5 0x563bef9f1d9e in handle_serial_event(int, void*) /home/simark/src/binutils-gdb/gdbserver/server.cc:4402 #6 0x563befb0ec65 in handle_file_event /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:548 #7 0x563befb0f49f in gdb_wait_for_event /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:673 #8 0x563befb0d4a1 in gdb_do_one_event() /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:215 #9 0x563bef9e721a in start_event_loop /home/simark/src/binutils-gdb/gdbserver/server.cc:3484 #10 0x563bef9eb90a in captured_main /home/simark/src/binutils-gdb/gdbserver/server.cc:3875 #11 0x563bef9ec2c7 in main /home/simark/src/binutils-gdb/gdbserver/server.cc:3961 #12 0x7f7fd3330001 in __libc_start_main (/usr/lib/libc.so.6+0x27001) SUMMARY: AddressSanitizer: 14 byte(s) leaked in 1 allocation(s). This is due to the handling of unknown qsupported features in handle_query. The `qsupported` vector is built, containing all the feature names received from GDB. As we iterate on them, when we encounter unknown ones, we move them at the beginning of the vector, in preparation of passing this vector of unknown features down to the target (which may know about them). When moving these unknown features to other slots in the vector, we overwrite other pointers without freeing them, which therefore leak. An easy fix would be to add a `free` when doing the move. However, I think this is a good opportunity to sprinkle a bit of automatic memory management in this code. So, use a vector of std::string which owns all the entries. And use a separate vector (that doesn't own the entries) for the unknown ones, which is then passed to target_process_qsupported. Given that the `c_str` method of std::string returns a `const char *`, it follows that process_stratum_target::process_qsupported must accept a `const char **` instead of a `char **`. And while at it, change the pointer + size paramters to use an array_view instead. gdbserver/ChangeLog: * server.cc (handle_query): Use std::vector of std::string for `qsupported` vector. Use separate vector for unknowns. * target.h (class process_stratum_target) <process_qsupported>: Change parameters to array_view of const char *. (target_process_qsupported): Remove `count` parameter. * target.cc (process_stratum_target::process_qsupported): Change parameters to array_view of const char *. * linux-x86-low.cc (class x86_target) <process_qsupported>: Likewise. Change-Id: I97f133825faa6d7abbf83a58504eb0ba77462812
2020-07-14Automatic date update in version.inGDB Administrator1-1/+1
2020-07-13Fix frame-apply.html collision in GDB manual.Paul Carroll2-3/+9
The addition of an anchor for the "frame apply" command was causing the HTML documentation to include files named both "frame-apply.html" and "Frame-Apply.html", which collide on case-insensitive file systems. This patch removes the redundant anchor and adjusts the two xrefs to it. 2020-07-13 Paul Carroll <pcarroll@codesourcery.com> PR gdb/25716 gdb/doc/ * gdb.texinfo (Frame Apply): Remove anchor for 'frame apply' and adjust xrefs to it.
2020-07-13Skip directory tests in gdb.base/info_sources.exp on remote hostSandra Loosemore2-3/+12
When testing on a remote host, source files from build are copied to an arbitrary location on host. Tests that try to pattern-match host pathnames against directory prefixes on build don't generally work. 2020-07-13 Sandra Loosemore <sandra@codesourcery.com> gdb/testsuite/ * gdb.base/info_sources.exp: Skip directory match tests on remote hosts.
2020-07-13x86: Remove 32-bit sign extension in offset_in_rangeH.J. Lu2-8/+5
When encoding a 32-bit offset, there is no need to sign-extend it to 64 bits since only the lower 32 bits are used. * config/tc-i386.c (offset_in_range): Remove 32-bit sign extension.
2020-07-13Fix gdb.base/savedregs.exp with clangGary Benson2-1/+6
gdb.base/savedregs.exp fails to run with clang, because of: gdb compile failed, /gdbtest/src/gdb/testsuite/gdb.base/savedregs.c:36:37: warning: operator '<<' has lower precedence than '+'; '+' will be evaluated first [-Wshift-op-parentheses] return callee (a1 << a2 * a3 / a4 + a6 & a6 % a7 - a8) + done; ~~ ~~~~~~~~~~~~~^~~~ /gdbtest/build/gdb/testsuite/gdb.base/savedregs.c:36:37: note: place parentheses around the '+' expression to silence this warning return callee (a1 << a2 * a3 / a4 + a6 & a6 % a7 - a8) + done; ^ ( ) 1 warning generated. This commit fixes it by adding the suggested parentheses. gdb/testsuite/ChangeLog: * gdb.base/savedregs.exp (caller): Use parentheses to make expected expression evaluation ordering explicit.
2020-07-13Fix gdb.arch/i386-sse.exp with clangGary Benson2-1/+5
gdb.arch/i386-sse.exp fails to run with clang, because of: gdb compile failed, /gdbtest/src/gdb/testsuite/gdb.arch/i386-sse.c:56:40: warning: passing 'int *' to parameter of type 'unsigned int *' converts between pointers to integer types with different sign [-Wpointer-sign] if (!x86_cpuid (1, NULL, NULL, NULL, &edx)) ^~~~ /gdbtest/src/gdb/testsuite/../nat/x86-cpuid.h:35:41: note: passing argument to parameter '__edx' here unsigned int *__ecx, unsigned int *__edx) ^ 1 warning generated. Fix it by declaring edx unsigned. gdb/testsuite/ChangeLog: * gdb.arch/i386-sse.c (have_sse) <edx>: Make unsigned.
2020-07-13Updated French translation for the gas/ and binutils/ sub-directoriesNick Clifton4-4184/+4798