Re-using the entire VEX decode hierarchy for the respective major opcode
has led to those two also being decoded as-if valid. Follow the earlier
USE_X86_64_EVEX_{PFX,W}_TABLE approach to avoid this happening.
As suggested during review already, all such entries have their first
slot as Bad_Opcode, so by adding two more enumerators we can avoid doing
that decode step altogether.
Adjustments made for the directive (by set_intel_syntax()) need also
making for the command line option. Break out respective code into a new
helper function, to also be invoked during command line processing.
Further also set register_prefix when processing -mnaked-reg.
With identical source and destination it can be covered by the NDD-to-
legacy conversion logic as well, even if in this case the original insn
doesn't use an NDD encoding. The size savings are even better here, for
the replacement (BSWAP) not having a ModR/M byte.
dwarf.c can hit "Assertion '(start) <= (end)' failed" on truncated
sections, due to get_encoded_eh_value wrongly returning a full count
for truncated words.
* dwarf.c (get_encoded_eh_value): Return zero for truncated words.
PR ld/31289 tests failed for fr30-elf, frv-elf, ft32-elf, iq2000-elf,
mn10200-elf, ms1-elf and msp430-elf targets:
FAIL: ld-elf/fatal-warnings-2a
FAIL: ld-elf/fatal-warnings-2b
FAIL: ld-elf/fatal-warnings-3a
FAIL: ld-elf/fatal-warnings-3b
FAIL: ld-elf/fatal-warnings-4a
FAIL: ld-elf/fatal-warnings-4b
even though PR ld/31289 targets xfail for [is_generic] targets. These
targets not only don't use the generic_link_hash_table linker, but also
don't use the standard ELF emulation. Add is_standard_elf for ELF
targets which use the standard ELF emulation and replace [is_generic]
with ![is_standard_elf] in PR ld/31289 tests.
binutils/
PR ld/31289
* testsuite/lib/binutils-common.exp (is_standard_elf): New.
ld/
PR ld/31289
* testsuite/lib/binutils-common.exp (is_generic): Return 1 for
fr30-*-*, frv-*-elf, ft32-*-*, iq2000-*-*, mn10200-*-*,
moxie-*-moxiebox*, msp430-*-* and mt-*-*.
* testsuite/ld-elf/fatal-warnings-2a.d: Replace [is_generic]
with ![is_standard_elf].
* testsuite/ld-elf/fatal-warnings-2b.d: Likewise.
* testsuite/ld-elf/fatal-warnings-3a.d: Likewise.
* testsuite/ld-elf/fatal-warnings-3b.d: Likewise.
* testsuite/ld-elf/fatal-warnings-4a.d: Likewise.
* testsuite/ld-elf/fatal-warnings-4b.d: Likewise.
Call output_unknown_cmdline_warning if there are no input files so that
$ ld -z bad-option
reports
ld: warning: -z bad-option ignored
ld: no input files
instead of
ld: no input files
PR ld/31289
* ldmain.c (main): Call output_unknown_cmdline_warning if there
are no input files.
On Fedora 39 aarch64 I run into:
...
(gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=2114437^M
Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=2114437^M
relaying data between gdb and process 2114437^M
warning: remote target does not support file transfer, \
attempting to access files from local filesystem.^M
Reading symbols from /lib/ld-linux-aarch64.so.1...^M
_start () at ../sysdeps/aarch64/dl-start.S:22^M
warning: 22 ../sysdeps/aarch64/dl-start.S: No such file or directory^M
(gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb
...
For contrast, on openSUSE Leap 15.4 x86_64 I have:
...
(gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=18797^M
Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=18797^M
relaying data between gdb and process 18797^M
warning: remote target does not support file transfer, \
attempting to access files from local filesystem.^M
Reading symbols from /lib64/ld-linux-x86-64.so.2...^M
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)^M
0x0000000004002550 in _start () from /lib64/ld-linux-x86-64.so.2^M
(gdb) PASS: gdb.base/valgrind-infcall.exp: target remote for vgdb
...
The fail happens in vgdb_start because the regexp only matches the
"in _start ()" variant, not the "_start () at":
...
gdb_test "$vgdbcmd" " in \\.?_start .*" "target remote for vgdb"
...
Which variant you get is determined by presence of debug info.
Fix this by also matching the "_start () at" variant.
Tested aarch64-linux and x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Since gcc commit d3f48f68227 ("c++: non-dependent .* operand folding
[PR112427]"), with gdb we run into PR gcc/113599 [1], a wrong-code bug, as
reported in PR build/31281.
Work around this by flipping inherit order:
...
-class thread_info : public refcounted_object,
- public intrusive_list_node<thread_info>
+class thread_info : public intrusive_list_node<thread_info>,
+ public refcounted_object
...
An argument could be made that this isn't necessary, because this occurred in
an unreleased gcc version.
However, I think it could be useful when bisecting gcc for other problems in
building gdb. Having this workaround means the bisect won't reintroduce the
problem. Furthermore, the workaround is harmless.
Tested on Fedora rawhide x86_64.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31281
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
On Fedora rawhide aarch64, I run into:
...
(gdb) PASS: gdb.base/eh_return.exp: set breakpoint on address
run ^M
Starting program: eh_return ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
[Inferior 1 (process 1113051) exited normally]^M
(gdb) FAIL: gdb.base/eh_return.exp: hit breakpoint (the program exited)
...
This happens as follows: the test-case sets a breakpoint on the last
instruction of function eh2:
...
(gdb) break *0x00000000004103ec^M
...
and expects to hit the breakpoint, but instead the "br x6" is taken:
...
0x00000000004103e0 <+176>: cbz x4, 0x4103ec <eh2+188>^M
0x00000000004103e4 <+180>: add sp, sp, x5^M
0x00000000004103e8 <+184>: br x6^M
0x00000000004103ec <+188>: ret^M
...
In contrast, with fedora f39 we have:
...
0x00000000004103bc <+156>: ldp x2, x3, [sp, #48]^M
0x00000000004103c0 <+160>: ldp x29, x30, [sp, #16]^M
0x00000000004103c4 <+164>: add sp, sp, #0x50^M
0x00000000004103c8 <+168>: add sp, sp, x4^M
0x00000000004103cc <+172>: ret^M
...
and the breakpoint is reached.
Fix this by detecting that the breakpoint is not hit, and declaring the test
unsupported.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31291
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31291
Currently, in AIX attach-twice.exp testcase is untested due to the below error.
gdb/testsuite/gdb.base/attach-twice.c:43:7: error: too few arguments to function 'ptrace'
This is because in AIX ptrace has five arguments. This patch is a fix for the same such that
this test case runs in AIX and other targets as well.
There are 2 problems with --fatal-warnings for unknown command-line
options:
1. --fatal-warnings doesn't trigger an error for an unknown command-line
option when --fatal-warnings is the last command-line option.
2. When --fatal-warnings triggers an error for an unknown command-line
option, the message says that the unknown command-line option is ignored.
This patch queues unknown command-line option warnings and outputs queued
command-line option warnings after all command-line options have been
processed so that --fatal-warnings can work for unknown command-line
options regardless of the order of --fatal-warnings.
When --fatal-warnings is used, the linker message is changed from
ld: warning: -z bad-option ignored
to
ld: error: unsupported option: -z bad-option
The above also applies to "-z dynamic-undefined-weak" when the known
"-z dynamic-undefined-weak" option is ignored.
PR ld/31289
* ldelf.c (ldelf_after_parse): Use queue_unknown_cmdline_warning
to warn the ignored -z dynamic-undefined-weak option.
* ldmain.c (main): Call output_unknown_cmdline_warnings after
calling ldemul_after_parse.
* ldmisc.c (CMDLINE_WARNING_SIZE): New.
(cmdline_warning_list): Likewise.
(cmdline_warning_head): Likewise.
(cmdline_warning_tail): Likewise.
(queue_unknown_cmdline_warning): Likewise.
(output_unknown_cmdline_warnings): Likewise.
* ldmisc.h (queue_unknown_cmdline_warning): Likewise.
(output_unknown_cmdline_warnings): Likewise.
* emultempl/elf.em (gld${EMULATION_NAME}_handle_option): Use
queue_unknown_cmdline_warning to warn unknown -z option.
* testsuite/ld-elf/fatal-warnings-1a.d: New file.
* testsuite/ld-elf/fatal-warnings-1b.d: Likewise.
* testsuite/ld-elf/fatal-warnings-2a.d: Likewise.
* testsuite/ld-elf/fatal-warnings-2b.d: Likewise.
* testsuite/ld-elf/fatal-warnings-3a.d: Likewise.
* testsuite/ld-elf/fatal-warnings-3b.d: Likewise.
* testsuite/ld-elf/fatal-warnings-4a.d: Likewise.
* testsuite/ld-elf/fatal-warnings-4b.d: Likewise.
Without this patch the r_offset field of struct external_reloc is
uninitialised when using objcopy.
* coff/riscv64.h (SWAP_IN_RELOC_OFFSET): Define.
(SWAP_OUT_RELOC_OFFSET): Define.
In an earlier patch, I wrote:
... It also adds some machinery so that attach stops can be
suppressed, which I think is the right thing to do.
However, after some discussions here at AdaCore, I now believe this to
be incorrect -- while DAP says that expected "continue" events should
be suppressed, there is no corresponding language for expected "stop"
events, and indeed "stop" events explicitly mention cases like "step".
This patch arranges for the stop event to be emitted again.
A user found that gdb would not correctly print a field from an Ada
record using the scalar storage order feature. We tracked this down
to a combination of problems.
First, GCC did not emit DW_AT_endianity on the enumeration type.
DWARF does not specify this, but it is an obvious and harmless
extension. This was fixed in GCC recently:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642347.htmlhttps://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5d8b60effc7268448a94fbbbad923ab6871252cd
Second, GDB did not handle this attribute on enumeration types. This
patch makes this change and adds a test case that will pass with the
patched GCC.
So far, the GCC patch isn't on the gcc-13 branch; but if it ever goes
in, the test case in this patch can be updated to reflect that.
Reviewed-By: Keith Seitz <keiths@redhat.com>
arm_epilogue_frame_this_id has a comment saying that it fall backs to using
the current PC if the function start address can't be identified, but it
actually uses only the PC to make the frame id.
This patch makes the code match the comment. Another hint that it's what
is intended is that arm_prologue_this_id, a function almost identical to
it, does that.
The problem was found by code inspection. It fixes the following testsuite
failures:
FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 9: check frame-id matches
FAIL: gdb.reverse/solib-reverse.exp: reverse-next third shr1
FAIL: gdb.reverse/solib-reverse.exp: reverse-next second shr1
FAIL: gdb.reverse/solib-reverse.exp: reverse-next first shr1
FAIL: gdb.reverse/solib-reverse.exp: reverse-next generic
FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function one
FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function one
FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function two
FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function two
Tested on arm-linux-gnueabi-hf.
This patch is based on an out-of-tree patch that fedora has been
carrying for a while. It tests if GDB is able to properly unwind a
threaded program in the following situations:
* regular threads
* in a signal handler
* in a signal handler executing on an alternate stack
And the final frame can either be in a syscall or in an infinite loop.
The test works by running the inferior until a crash to generate a
corefile, or until right before the crash. Then applies a backtrace to
all threads to see if any frame can't be identified, and the order of
the threads in GDB. Finally, it goes thread by thread and tries to
collect a large part of the backtrace, to confirm that everything is
being unwound correctly.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Approved-By: Luis Machado <luis.machado@arm.com>
For R_LARCH_TLS_{LE_HI20_R,LE_ADD_R,LD_PC_HI20,GD_PC_HI20, DESC_PC_HI20}
relocations, start a new frag to get correct eh_frame Call Frame Information
FDE DW_CFA_advance_loc info.
Gcc may generate "\t.align\t%d,54525952,4\n" before commit
b20c7ee066cb7d952fa193972e8bc6362c6e4063. To write 54525952 (NOP) to object
file, we call s_align_ptwo (-4). It result in alignment padding must be a
multiple of 4 if .align has second parameter.
Use default s_align_ptwo for .align.
Restructure the architecture extensions table, add a new table for architecture
version dependencies, add missing architecture extensions, and improve some
extension descriptions.
This matches the dependencies in the architecture, in LLVM, and even in the
original Binutils commit message that mistakenly included it only in armv9.4-a.
When a user attempts to use the "list ." command with an inferior that
doesn't have debug symbols, GDB would crash. This was reported as PR
gdb/31256.
The crash would happen when attempting to get the current symtab_and_line
for the stop location, because the symtab would return a null pointer
and we'd attempt to dereference it to print the line.
This commit fixes that by checking for an empty symtab and erroring out
of the function if it happens.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31256
Approved-By: Tom Tromey <tom@tromey.com>
The op struct includes an array of strings, but doesn't use braces
around that array when initializing. This causes a ton of warnings
when using -Wmissing-braces. Add them to fix.
The code this tool generates is the same before & after.
The match_never() function has been removed and thus step_once() crashes
during instruction decoding. Fixed it by checking for null pointer before
invoking function attached to match_func member of riscv_opcode structure
Some compilers warn in the frv code:
sem.c:24343:41: error: incompatible function pointer types passing
'void (SIM_CPU *, UINT, UDI)' (aka 'void (struct _sim_cpu *, unsigned int, unsigned long)')
to parameter of type
'void (*)(SIM_CPU *, UINT, DI)' (aka 'void (*)(struct _sim_cpu *, unsigned int, long)') [-Wincompatible-function-pointer-types]
This is due to frvbf_h_acc40U_set using UDI for setting the new value,
but using the common sim_queue_fn_di_write API which uses DI. The same
size, but different sign. We could change frvbf_h_acc40U_set to take a
DI without changing behavior in practice: the UDI is already passed via
the queue function which accepts a DI, and frvbf_h_acc40U_set already
casts the input to UDI before running any operations on it. However,
these files are all generated, so manual changes here would be reverted.
Seems like we can only change the register type for all APIs in the cpu
definition. This builds cleanly, and passes sim unittests. Not sure if
it's 100% the answer, but seems to be the best we have currently.
Bug: https://sourceware.org/PR29752
Tom Tromey noticed that dw2-zero-range.exp reported a duplicate test
name. This happens because have_index calls get_index_type with the
default test name. Refactor the test to avoid this, while cleaning a
few other things, the most important being:
- factor out the relocated and unrelocated parts in their own procs
- give different names to generated binaries in different variations,
such that all binaries are left in the test output directory (this
makes it easier to debug a specific variation)
Change-Id: I7cdf7a344834852fbb035d7e0434559eab6b1e94
Before running our tests, we made a fake installation into ./tmpdir.
This installation changes libopcodes.la in the build area.
Gas testing may fail if gas and gprofng tests are run in parallel.
I create a script to run gprofng. Inside this script, LD_LIBRARY_PATH,
GPROFNG_SYSCONFDIR are set.
putenv_libcollector_ld_misc() first uses $GPROFNG_PRELOAD_LIBDIRS to create
directories for SP_COLLECTOR_LIBRARY_PATH ($SP_COLLECTOR_LIBRARY_PATH is used
to set up LD_PRELOAD).
gprofng/ChangeLog
2024-01-19 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/31252
PR gprofng/30808
* src/envsets.cc (putenv_libcollector_ld_misc): Use
$GPROFNG_PRELOAD_LIBDIRS first to build SP_COLLECTOR_LIBRARY_PATH.
* testsuite/config/default.exp: Create a script to run gprofng.
* testsuite/lib/display-lib.exp: Fix typo.
GCC 14 will warn about calling calloc with swapped size and count
arguments.
binutils/srconv.c: In function ‘nints’:
binutils/srconv.c:598:36: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
598 | return (int *) (xcalloc (sizeof (int), x));
| ^~~
binutils/srconv.c:598:36: note: earlier argument should specify number of elements, later size of each element
binutils/
* srconv.c (nints): Swap xcalloc arguments.
(wr_du): Likewise.
(wr_dus): Likewise.
GCC 14 will warn about calling calloc with swapped size and count
arguments.
binutils-gdb/binutils/coffgrok.c: In function ‘do_sections_p1’:
binutils-gdb/binutils/coffgrok.c:116:72: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
116 | struct coff_section *all = (struct coff_section *) (xcalloc (sizeof (struct coff_section),
| ^~~~~~
binutils-gdb/binutils/coffgrok.c:116:72: note: earlier argument should specify number of elements, later size of each element
binutils/
* coffgrok.c (empty_scope): Swap xcalloc arguments.
(empty_symbol): Likewise.
(do_lines): Likewise.
(doit): Likewise.
(coff_grok): Likewise.
GCC14 warns about the order of the arguments to calloc
libsframe/sframe-dump.c: In function ‘dump_sframe_header’:
libsframe/sframe-dump.c:70:39: warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
70 | flags_str = (char*) calloc (sizeof (char), SFRAME_HEADER_FLAGS_STR_MAX_LEN);
| ^~~~
libsframe/sframe-dump.c:70:39: note: earlier argument should specify number of elements, later size of each element
Fix this by swapping the size and count arguments.
libsframe/
* sframe-dump.c (dump_sframe_header): Swap arguments to calloc
GCC 14 will detect when the size and count arguments of calloc are
swapped.
binutils-gdb/opcodes/tic4x-dis.c: In function ‘tic4x_disassemble’:
binutils-gdb/opcodes/tic4x-dis.c:710:32: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
710 | optab = xcalloc (sizeof (tic4x_inst_t *), (1 << TIC4X_HASH_SIZE));
| ^~~~~~~~~~~~
binutils-gdb/opcodes/tic4x-dis.c:710:32: note: earlier argument should specify number of elements, later size of each element
binutils-gdb/opcodes/tic4x-dis.c:712:40: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args]
712 | optab_special = xcalloc (sizeof (tic4x_inst_t *), TIC4X_SPESOP_SIZE);
| ^~~~~~~~~~~~
binutils-gdb/opcodes/tic4x-dis.c:712:40: note: earlier argument should specify number of elements, later size of each element
opcodes/ChangeLog:
* /tic4x-dis.c (tic4x_disassemble): Swap size and count xcalloc
arguments.
A user pointed out that gdb will print a Python exception when it gets
an EOF in DAP mode. And, it turns out that an EOF like this also
causes gdb not to exit. This is due to the refactoring that moved the
JSON reader to its own thread -- previously this caused an exception
to propagate and cause an exit, but now it just leaves the reader
hung.
This patch fixes these problems by arranging to handle EOF more
gracefully.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31217
In one spot, DW_OP_GNU_push_tls_address is handled differently from
DW_OP_form_tls_address. However, I think they should always be
treated identically.
Approved-by: Kevin Buettner <kevinb@redhat.com>
m32c/cpu.h defines mem as enum value, which causes GCC 14 to emit
sim/m32c/gdb-if.c: In function ‘sim_read’:
sim/m32c/gdb-if.c:162:33: error: declaration of ‘mem’ shadows a previous local [-Werror=shadow=local]
162 | sim_read (SIM_DESC sd, uint64_t mem, void *buf, uint64_t length)
| ~~~~~~~~~^~~
In file included from ../../binutils-gdb/sim/m32c/gdb-if.c:38:
sim/m32c/cpu.h:83:3: note: shadowed declaration is here
83 | mem,
| ^~~
Fix this by renaming mem to addr in all sim_read and sim_write functions.
Most already used addr instead of mem. In one file, sim/rx/gdb-if.c, this
also meant renaming the local addr variable to vma.
With GCC 14 -Werror=shadow=compatible-local flags the reuse of single
capital letters used in aarch64/cpustate.h enums
88 | expand_logical_immediate (uint32_t S, uint32_t R, uint32_t N)
| ~~~~~~~~~^
In file included from ../../binutils-gdb/sim/aarch64/aarch64-sim.h:27,
from ../../binutils-gdb/sim/aarch64/simulator.c:33:
217 | N = 1 << N_IDX
| ^
sim/aarch64/simulator.c: In function ‘expand_logical_immediate’:
sim/aarch64/simulator.c:88:60: error: declaration of ‘N’ shadows a previous local [-Werror=shadow=compatible-local]
sim/aarch64/cpustate.h:217:3: note: shadowed declaration is here
