aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-07-19x86: Change PLT32 reloc against section to PC32H.J. Lu10-6/+81
Commit 292676c1 resolved PLT32 reloc aganst local symbol to section. Since PLT32 relocation must be against symbols, turn such PLT32 relocation into PC32 relocation. gas/ PR gas/26263 * config/tc-i386.c (i386_validate_fix): Change PLT32 reloc against section to PC32 reloc. * testsuite/gas/i386/relax-5.d: Updated. * testsuite/gas/i386/x86-64-relax-4.d: Likewise. ld/ PR gas/26263 * testsuite/ld-i386/i386.exp: Run PR gas/26263 test. * testsuite/ld-x86-64/x86-64.exp: Likewise. * testsuite/ld-i386/pr26263.d: New file. * testsuite/ld-x86-64/pr26263.d: Likewise. * testsuite/ld-x86-64/pr26263.s: Likewise.
2020-07-19ld: optionally emit _etext last, before .dataHans-Peter Nilsson4-4/+21
So, here's my suggestion for making _init .. __etext cover .text + .rodata (including things like the read-only exception tables) for elf64mmix. A quick web search gives that __etext (and friends) isn't well defined, so each target can interpret the "end of text segment" to their own liking. It seems likely this change is also a better fit than the default for other ports, at least those with .rodata after .text in the same segment. The presence of a separate rodata-segment is optional (and not true for elf64mmix). This is reflected in the name as SEPARATE_TEXT / SEPARATE_CODE isn't considered, to keep it simple; each target has to make sure their settings of variables make sense. ld: * scripttempl/elf.sc (ETEXT_LAST_IN_RODATA_SEGMENT): New variable. * emulparams/elf64mmix.sh (ETEXT_LAST_IN_RODATA_SEGMENT): Define. * testsuite/ld-mmix/sec-1.d: Adjust.
2020-07-19Power10 stub selectionAlan Modra13-34/+359
This patch better supports mixing of power10 and non-power10 code, as might be seen in a cpu-optimized library using ifuncs to select functions optimized for a given cpu. Using -Wl,--no-power10-stubs isn't that good in this situation since non-power10 notoc stubs are slower and larger than the power10 variants, which you'd like to use on power10 code paths. With this change, power10 pc-relative code that makes calls marked @notoc uses power10 stubs if stubs are necessary, and other calls use non-power10 instructions in stubs. This will mean that if gcc is generating code for -mcpu=power10 but with pc-rel disabled then you'll get the older stubs even on power10 (unless you force with -Wl,--power10-stubs). That shouldn't be too big a problem: stubs that use r2 are reasonable. It's just the ones that set up addressing using "mflr 12; bcl 20,31,.+4; mflr 11; mtlr 12" that should be avoided if possible. bfd/ * elf64-ppc.c (struct ppc_link_hash_table): Add has_power10_relocs. (select_alt_stub): New function. (ppc_get_stub_entry): Use it here. (ppc64_elf_check_relocs): Set had_power10_relocs rather than power10_stubs. (ppc64_elf_size_stubs): Clear power10_stubs here instead. Don't merge notoc stubs with other varieties when power10_stubs is "auto". Instead dup the stub hash table entry. (plt_stub_size, ppc_build_one_stub, ppc_size_one_stub): Adjust tests of power10_stubs. ld/ * emultempl/ppc64elf.em (power10-stubs): Accept optional "auto" arg. * ld.texi (power10-stubs): Update. * testsuite/ld-powerpc/callstub-1.d: Force --power10-stubs. * testsuite/ld-powerpc/callstub-2.d: Relax branch offset comparison. * testsuite/ld-powerpc/callstub-4.d: New test. * testsuite/ld-powerpc/notoc.d: Force --no-power10-stubs. * testsuite/ld-powerpc/notoc3.d, * testsuite/ld-powerpc/notoc3.s, * testsuite/ld-powerpc/notoc3.wf: New test. * testsuite/ld-powerpc/powerpc.exp: Run new tests. Pass --no-power10-stubs for notoc link.
2020-07-19Automatic date update in version.inGDB Administrator1-1/+1
2020-07-18Remove "linux_multi_process" globalTom Tromey2-6/+6
The "linux_multi_process" is initialized but never modified. I discussed this with Pedro on irc, and he said that, while it was useful when developing this feature, it is now no longer needed. So, this removes it. gdb/ChangeLog 2020-07-18 Tom Tromey <tom@tromey.com> * linux-nat.c (linux_multi_process): Remove. (linux_nat_target::supports_multi_process): Return true.
2020-07-18Automatic date update in version.inGDB Administrator1-1/+1
2020-07-17gdb/riscv: delete target descriptions when gdb exitsAndrew Burgess9-16/+58
It was pointed out on IRC that the RISC-V target allocates target descriptions and stores them in a global map, and doesn't delete these target descriptions when GDB shuts down. This isn't a particular problem, the total number of target descriptions we can create is very limited so creating these on demand and holding them for the entire run on GDB seems reasonable. However, not deleting these objects on GDB exit means extra warnings are printed from tools like valgrind, and the address sanitiser, making it harder to spot real issues. As it's reasonably easy to have GDB correctly delete these objects on exit, lets just do that. I started by noticing that we already have a target_desc_up type, a wrapper around unique_ptr that calls a function that will correctly delete target descriptions, so I want to use that, but.... ...that type is declared in gdb/target-descriptions.h. If I try to include that file in gdb/arch/riscv.c I run into a problem, that file is compiled into both GDB and GDBServer. OK, I could guard the include with #ifdef, but surely we can do better. So then I decided to move the target_desc_up type into gdbsupport/tdesc.h, this is the interface file for generic code shared between GDB and GDBserver (relating to target descriptions). The actual implementation for the delete function still lives in gdb/target-description.c, but now gdb/arch/riscv.c can see the declaration. Problem solved.... ... but, though RISC-V doesn't use it I've now exposed the target_desc_up type to gdbserver, so in future someone _might_ start using it, which is fine, except right now there's no definition of the delete function - remember the delete I used is only defined in GDB code. No problem, I add an implementation of the delete operator into gdbserver/tdesc.cc, and all is good..... except.... I start getting this error from GCC: tdesc.cc:109:10: error: deleting object of polymorphic class type ‘target_desc’ which has non-virtual destructor might cause undefined behavior [-Werror=delete-non-virtual-dtor] Which is caused because gdbserver's target_desc type inherits from tdesc_element which has a virtual method, and so GCC worries that target_desc might be used as a base class. The solution is to declare gdbserver's target_desc class as final. This is fine so long as we never intent to inherit from target_desc (in gdbserver). But if we did then we'd want to make target_desc's destructor virtual anyway, so the error above would be resolved, and there wouldn't be an issue. gdb/ChangeLog: * arch/riscv.c (riscv_tdesc_cache): Change map type. (riscv_lookup_target_description): Return pointer out of unique_ptr. * target-descriptions.c (allocate_target_description): Add comment. (target_desc_deleter::operator()): Likewise. * target-descriptions.h (struct target_desc_deleter): Moved to gdbsupport/tdesc.h. (target_desc_up): Likewise. gdbserver/ChangeLog: * tdesc.cc (allocate_target_description): Add header comment. (target_desc_deleter::operator()): New function. * tdesc.h (struct target_desc): Declare as final. gdbsupport/ChangeLog: * tdesc.h (struct target_desc_deleter): Moved here from gdb/target-descriptions.h, extend comment. (target_desc_up): Likewise.
2020-07-17[gdb/testsuite] Add gdb.base/valgrind-infcall-2.expTom de Vries4-13/+131
In commit ee3c5f8968 "Fix GDB crash when registers cannot be modified", we fix a GDB crash: ... $ valgrind /usr/bin/sleep 10000 ==31595== Memcheck, a memory error detector ==31595== Command: /usr/bin/sleep 10000 ==31595== $ gdb /usr/bin/sleep (gdb) target remote | vgdb --pid=31595 Remote debugging using | vgdb --pid=31595 ... $hex in __GI___nanosleep () at nanosleep.c:27 27 return SYSCALL_CANCEL (nanosleep, requested_time, remaining); (gdb) p printf ("bla") terminate called after throwing an instance of 'gdb_exception_error' Aborted (core dumped) ... This patch adds a test-case for it. Unfortunately, I was not able to trigger the error condition using a regular vgdb_start, so I've added a parameter active_at_startup, and when set to 0 this causes valgrind to be started without --vgdb-error=0. Tested on x86_64-linux. Tested with the commit mentioned above reverted, resulting in: ... (gdb) p printf ("bla")^M terminate called after throwing an instance of 'gdb_exception_error'^M ERROR: GDB process no longer exists GDB process exited with wait status 6152 exp10 0 0 CHILDKILLED SIGABRT SIGABRT UNRESOLVED: gdb.base/valgrind-infcall-2.exp: do printf ... gdb/testsuite/ChangeLog: 2020-07-17 Tom de Vries <tdevries@suse.de> * gdb.base/valgrind-infcall-2.c: New test. * gdb.base/valgrind-infcall-2.exp: New file. * lib/valgrind.exp (vgdb_start): Add and handle active_at_startup.
2020-07-17Use boolean literals in linux-nat.cTom Tromey2-4/+11
I noticed a couple of spots in linux-nat.c that use 0/1 where boolean literals would be more idiomatic. This patch makes this change. gdb/ChangeLog 2020-07-17 Tom Tromey <tromey@adacore.com> * linux-nat.c (linux_nat_target::supports_non_stop) (linux_nat_target::always_non_stop_p): Use "true". (linux_nat_target::supports_disable_randomization): Use "true" and "false".
2020-07-17[gdb/testsuite] Use MACRO_AT_{func,range}Tom de Vries23-198/+64
Use dwarf assembly procs MACRO_AT_func and MACRO_AT_range in test-cases where that's appropriate. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-17 Tom de Vries <tdevries@suse.de> * gdb.dlang/circular.c (found): Use found_label as label name. * gdb.dwarf2/arr-subrange.c (main): Use main_label as label name. * gdb.dwarf2/comp-unit-lang.c (func): Use func_label as label name. * gdb.dlang/circular.exp: Use MACRO_AT_func and MACRO_AT_range. * gdb.dwarf2/ada-linkage-name.exp: Same. * gdb.dwarf2/arr-subrange.exp: Same. * gdb.dwarf2/atomic-type.exp: Same. * gdb.dwarf2/comp-unit-lang.exp: Same. * gdb.dwarf2/cpp-linkage-name.exp: Same. * gdb.dwarf2/dw2-bad-mips-linkage-name.exp: Same. * gdb.dwarf2/dw2-lexical-block-bare.exp: Same. * gdb.dwarf2/dw2-regno-invalid.exp: Same. * gdb.dwarf2/implptr-64bit.exp: Same. * gdb.dwarf2/imported-unit-abstract-const-value.exp: Same. * gdb.dwarf2/imported-unit-runto-main.exp: Same. * gdb.dwarf2/imported-unit.exp: Same. * gdb.dwarf2/main-subprogram.exp: Same. * gdb.dwarf2/missing-type-name.exp: Same. * gdb.dwarf2/nonvar-access.exp: Same. * gdb.dwarf2/struct-with-sig.exp: Same. * gdb.dwarf2/typedef-void-finish.exp: Same. * gdb.dwarf2/void-type.exp: Same.
2020-07-17[gdb/testsuite] Drop src arg of MACRO_AT_{func,range}Tom de Vries17-45/+47
The dwarf assembly procs MACRO_AT_func and MACRO_AT_range have a src parameter, which is set to $srcdir/$subdir/$srcfile in every single call. Drop the src parameter and hardcode usage of $srcdir/$subdir/$srcfile in the procs. Build and reg-tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-17 Tom de Vries <tdevries@suse.de> * lib/dwarf.exp (Dwarf::MACRO_AT_func, Dwarf::MACRO_AT_range): Drop src parameter. * gdb.dlang/watch-loc.exp: Update MACRO_AT_{func,range} calls. * gdb.dwarf2/bitfield-parent-optimized-out.exp: Same. * gdb.dwarf2/dw2-ifort-parameter.exp: Same. * gdb.dwarf2/dw2-opt-structptr.exp: Same. * gdb.dwarf2/dwz.exp: Same. * gdb.dwarf2/implptr-optimized-out.exp: Same. * gdb.dwarf2/implref-array.exp: Same. * gdb.dwarf2/implref-const.exp: Same. * gdb.dwarf2/implref-global.exp: Same. * gdb.dwarf2/implref-struct.exp: Same. * gdb.dwarf2/info-locals-optimized-out.exp: Same. * gdb.dwarf2/opaque-type-lookup.exp: Same. * gdb.dwarf2/var-access.exp: Same. * gdb.dwarf2/varval.exp: Same. * gdb.trace/entry-values.exp: Same.
2020-07-17[gdb/testsuite] Remove Dwarf::externTom de Vries12-28/+14
The file lib/dwarf.exp contains: ... # Declare a global label. This is typically used to refer to # labels defined in other files, for example a function defined in # a .c file. proc extern {args} { foreach name $args { _op .global $name } } ... The assembler directive to refer to labels defined in other files is not .global, but .extern, and that one is ignored by gas. Since we require gas for all dwarf assembly test-cases, remove the proc and all it's uses. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-17 Tom de Vries <tdevries@suse.de> * lib/dwarf.exp (Dwarf::extern): Remove. * gdb.compile/compile-ops.exp: Remove use of Dwarf::extern. * gdb.dlang/circular.exp: Same. * gdb.dwarf2/comp-unit-lang.exp: Same. * gdb.dwarf2/dw2-ifort-parameter.exp: Same. * gdb.dwarf2/dw2-symtab-includes.exp: Same. * gdb.dwarf2/dwz.exp: Same. * gdb.dwarf2/imported-unit-abstract-const-value.exp: Same. * gdb.dwarf2/imported-unit-runto-main.exp: Same. * gdb.dwarf2/imported-unit.exp: Same. * gdb.dwarf2/opaque-type-lookup.exp: Same.
2020-07-17Automatic date update in version.inGDB Administrator1-1/+1
2020-07-17mmix ld: move .init (and _init) first.Hans-Peter Nilsson3-12/+17
This both makes the section layout more similar to that of the general default for ELF and fixes (makes true) an assumption that code and rodata is located between _init and __etext, in libgcc/config/mmix/crti.S. Sadly, that's not actually true for ELF (generally and for elf64mmix), where exception-tables and .rodata is after _etext; I'm pondering what to do about that. The original mmix simulator behavior is that memory magically appears on access, initialized with 0, which is not preferable when chasing bugs by throwing code the size of the gcc test-suite to the simulator. The code in crti.S compatibly enables simulator machinery to identify undefined memory and instead stopping the simulator with an error (going to interactive mode for interactive runs). See http://gcc.gnu.org/legacy-ml/gcc-patches/2012-10/msg01871.html for more, including the mmix-sim.ch "patch file". This fixes only one error in the gcc testsuite, gcc.c-torture/execute/pr20621-1.c with LTO, where for some reason gcc/lto chooses to move (writable) data that is only used to read 0 to .rodata. An access (sufficiently far inside a block) in an unregistered place is flagged as an invalid access. The bpo-9m test that I had to adjust, actually exposes a wart: mmo does not have the notion of symbol types (or sections) and the test-case now has leading zeros at "Main" eventually leading to it being misdiagnosed as being outside .text and .data, thus here mapped to BFD as an absolute symbol. The test is not intended to check the mmo symbol-type machinery, so I'm just tweaking it to be symbol-type-neutral for "Main". Since you have to jump through hoops to see the problem, I don't think this commit is worth putting on the 2.35-branch. ld: * scripttempt/mmo.sc: Move .init first in .text output section. * testsuite/ld-mmix/bpo-9m.d: Adjust accordingly.
2020-07-16Fix POSIX-isms in gdb.base/shell.expSandra Loosemore2-10/+21
Some recent tests added to gdb.base/shell.exp have been failing on Windows host due to assumptions that the shell is a POSIX variant. On Windows, GDB uses CMD.EXE via the system() call to run shell commands instead. There seems to be no obvious CMD.EXE equivalent for "kill -2 $$" to signal the shell process, so this patch skips those tests on Windows host. The second problem addressed here is that CMD.EXE only recognizes double quotes, not single quotes; that change can be made unconditionally since POSIX shells recognize double quotes as well. 2020-07-16 Sandra Loosemore <sandra@codesourcery.com> gdb/testsuite/ * gdb.base/shell.exp: Skip pipe tests dependent on sh on Windows host. Use double quotes instead of single quotes.
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.