Jan Beulich [Fri, 21 Nov 2025 08:05:02 +0000 (09:05 +0100)]
bfd/XCOFF: mark internal data hidden
This reduces the dynamic symbol table a bit (about a dozen symbols) and
allows the compiler to be more aggressive about inlining (as it sees fit,
of course).
Jan Beulich [Fri, 21 Nov 2025 08:04:42 +0000 (09:04 +0100)]
bfd/ECOFF: mark internal functions hidden
This reduces the dynamic symbol table a bit (about 30 symbols) and allows
the compiler to be more aggressive about inlining (as it sees fit, of
course).
Jan Beulich [Fri, 21 Nov 2025 08:03:57 +0000 (09:03 +0100)]
bfd/COFF: mark internal functions hidden
This reduces the dynamic symbol table a bit (about 50 symbols) and allows
the compiler to be more aggressive about inlining (as it sees fit, of
course).
Andrew Burgess [Tue, 21 Jan 2025 17:22:04 +0000 (17:22 +0000)]
gdb: include NT_I386_TLS note in generated core files
This commit extends GDB for x86/Linux to include the NT_I386_TLS note
in generated core files (i.e. created with `generate-core-file` or
`gcore` command). This note contains the 3 per-thread TLS related
GDT (global descriptor table) entries, and is present for i386
binaries, or those compiled on x86-64 with -m32.
The approach I have taken to achieve this, is to make the 3 GDT
entries available within 3 new registers. I added these registers to
the org.gnu.gdb.i386.linux target description feature, as this feature
seemed perfectly named. As the new registers are optional I don't see
any harm in extending this existing feature. I did consider adding a
new feature with `tls` in the name, but this seemed excessive given
the existing feature.
Which GDT entries are used for TLS varies between i386 and x86-64
running in 32-bit mode. As such the registers are named with suffixes
0, 1, and 2, and it is left to GDB or gdbserver, to find the correct
GDT entries (based on the precise target) and place the contents into
these registers.
With this done, adding the relevant regset is sufficient to get the
tls contents emitted as a core file note. Support for emitting the
note into the generated core file relies on some BFD changes which
were made in an earlier commit:
The three new registers are readable and writable. Writing to one of
the new registers will update the relevant kernel GDT entry.
Each TLS GDT is represented by a 'struct user_desc' (see 'man 2
get_thread_area' for details), the first 4 bytes of each 'user_desc'
is the 'entry_number' field, this is the index of the GDT within the
kernel, and cannot be modified. Attempts to write to this region of
the register will be ignored, but will not give an error.
I did consider not including this part of the user_desc within the
register value, but this becomes difficult when we consider remote
targets, GDB would then need to figure out what these indexes were so
that the core file note could be generated. Sure, we probably could
figure the correct index values out, but I figure, why bother, we can
just pass them through in the register and know for certain that we
have the correct values.
For testing, there's a new test that covers the basic functionality,
including read/write access to the new registers, and checking that
the NT_386_TLS note is added to the core file, and that the note
contents can be read by GDB.
I also manually tested opening a core file generated from an old
GDB (so no NT_386_TLS notes) using a GDB with this patch. This works
fine, the new tls registers are not created as the NT_GDB_TDESC
note (the target description) doesn't include the new registers.
Out of interest I also patched an old version of GDB to avoid creating
the NT_GDB_TDESC, and created a core file. This core file contained
neither the NT_386_TLS nor NT_GDB_TDESC. When opening this core file
with a patched GDB, the new registers do show up, but their contents
are given as <unavailable>, which is exactly what we'd expect, GDB
builds a target description based on the architecture, the
architecture says these registers should exist, but they are missing
from the core file, hence, <unavailable>.
I also tested using a patched GDB with an old version of gdbserver,
the new registers don't show up as the old gdbserver doesn't send them
in its target description. And a core file created using the gcore
command in such a setup leaves no NT_386_TLS notes added, which is
what we'd expect.
And I also tested a new gdbserver running with an old version of GDB.
As the new tls registers are now mentioned in the target description,
then obviously, the old GDB does see the registers, and present them
to the user, however GDB doesn't know how to use these registers to
create a NT_386_TLS, so that note isn't added to any core files.
Also, while a new GDB places the tls registers into the 'system'
group, an old GDB doesn't do this, so the registers end up in the
'general' group by default. This means they show up within 'info
registers' output. This isn't ideal, but there's not much that can be
done about this.
Overall, I feel the combinations of old and new tools has been tested,
and the behaviours are what we'd want or expect.
I'm tagging this commit with PR gdb/15591, even though this patch
isn't directly related. That bug is for improving GDB's testing of
TLS support in core files. The test in this commit does do some very
simple reading of a TLS variable, but there's only two threads, and
one TLS variable, so it's not extensive. Additionally, the test in
this commit is x86 only, so this should not be considered a full
resolution to that bug. But still, it's something.
Tom Tromey [Thu, 6 Nov 2025 15:06:33 +0000 (08:06 -0700)]
Do not apply properties to arch-allocated types
A user reported that gdb would crash when debugging a certain Fortran
executable.
The bug is that the DWARF reader may try to apply dynamic properties
to an arch-allocated type. This came as a bit of a surprise, but the
issue is that the function-type-allocation code could end up creating
an arch-owned type, when the return type is arch-owned.
This patch fixes the problem, and any other potential future problems,
by arranging for all types created by the DWARF reader to be
objfile-owned.
A better long-term solution might be the fabled "type GC", where the
arch/objfile distinction is finally removed. However, this is more
difficult to implement.
Jaro Fietz [Fri, 14 Nov 2025 20:55:08 +0000 (21:55 +0100)]
Fix dwarf2 "assertion failed" on bra without skip dwarf expression op
When interpreting dwarf expressions, the function
dwarf2_get_symbol_read_needs walks over all instructions via
the call graph by using a to-visit and a visited list.
Upon reaching a bra operation, it pushes both the next op and the
branch target into the to-visit list.
If the branch-target can be reached linearly from the next op,
the branch-target will be visited twice.
At the top of the visit-loop, there is an assertion that a visited
instruction must never be visited again.
This assertion fails in the above case.
For example a DIE with DW_AT_location: 30 31 28 0 0 9f
(DW_OP_lit0; DW_OP_lit1; DW_OP_bra: 0; DW_OP_stack_value)
will result in
.././binutils-gdb/gdb/dwarf2/loc.c:1905: internal-error: dwarf2_get_symbol_read_needs: Assertion `visited_ops.find (op_ptr) == visited_ops.end ()' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Adding a skip operation which makes the branch-target not linearly
accessible from the next op, makes the example work. For example a
DIE with DW_AT_location: 32 31 28 3 0 2f 1 0 96 9f (DW_OP_lit2;
DW_OP_lit1; DW_OP_bra: 3; DW_OP_skip: 1; DW_OP_nop; DW_OP_stack_value)
produces the correct result $1 = 2.
This patch replaces the failing assertion with a continue to properly
skip an already visited dwarf expression op.
This makes the first example work correctly and result in $1 = 0.
Running the testsuite resulted in different results upon every run
(arch-linux 6.17.7-arch1-1 x86_64).
Comparing the results of 3 runs of the unmodified code with three
runs containing the fix does not yield a significant difference:
unmodified version: # of expected passes 126821, 126813, 126838
fix version: # of expected passes 126866, 126801, 126817
gprofng: New tool for converting gmon.out file to experiments
This patch introduces the capability to convert a gmon.out file into a
gprofng experiment.
The gmon.out file format includes a histogram record, a call graph
record, and basic block execution count records. A gprofng experiment
folder consists of various files, of which four are particularly
important:
- log.xml: Contains the profile timer setup and defines the profile
data structure fields.
- map.xml: Contains the memory map information of the profiled
executable.
- profile: Holds the time profile information.
- data.frameinfo: Records the stack trace at a specific sampling
moment, with each trace linked to the time profile information
stored in the profile file.
This patch adds a new tool to gprofng that reads the gmon.out file and
the profiled executable. With the executable, we can reconstruct
information about the profiled symbols and the memory map layout. The
gmon.out file provides details about the execution duration for each
symbol, as well as data used to build the call graph. This new patch
is a subcommand for the display command.
New gmon subcommand options:
--version print the version number and exit.
-h/--help print usage information and exit.
-o <exp_name> specify the name for (and path to) the experiment directory; the
the default path is the current directory.
-O <exp_name> the same as -o, but unlike the -o option, silently overwrite an
existing experiment directory with the same name.
The new tool can be executed using the command line:
$ gprofng display gmon EXEC_FILE GMON_FILE
N.B. If EXEC_FILE or GMON_FILE is missing the default a.out and
gmon.out names are considered.
Upon successful execution, an experiment file is created that can be
processed with existing gprofng tools. For example:
$ gprofng display text -calltree EXPERIMENT
This command will display the call tree from the converted gmon file.
Tom de Vries [Thu, 20 Nov 2025 09:46:54 +0000 (10:46 +0100)]
[contrib] Accept _("") and operator() in check_GNU_style_lib.py
Currently contrib/check_GNU_style_lib.py warns about '_("foo")', expecting
'_ ("foo")' instead:
...
$ cat tmp.patch
...
+const char *
+foo (void)
+{
+ return _("foo");
+}
$ ./contrib/check_GNU_style.py tmp.patch
=== ERROR type #1: there should be exactly one space between function name \
and parenthesis (1 error(s)) ===
test.c:4:10: return _("foo");
$
...
However '_("")' is an exception [1] to the rule, so skip the ERROR in this
case.
Likewise for 'operator()', which seems common enough:
...
$ find gdb* -type f \
| egrep -v '/testsuite/|ChangeLog' \
| xargs grep "::operator()" \
| wc -l
27
...
for example in gdb/dwarf2/read.c:
...
dwo_file_hash::operator() (const dwo_file_up &file) const noexcept
...
Simon Marchi [Tue, 18 Nov 2025 03:38:23 +0000 (22:38 -0500)]
gdb/dwarf: use offset in dwarf_expr_context::read_mem
The `offset` variable is the offset within the passed-in object where
`addr` falls. We use it to verify whether `addr` falls within that
object's bounds, but then the memcpy fails to consider it, meaning that
we always copy from the beginning of the passed-in object, even if
`addr` lands in the middle of the object. Fix that by adding `offset`
to the source argument of the memcpy. I caught this by writing a patch
later in this series, so this fix is covered by the test added in that
later patch.
Also, I find it a bit odd to compute the offset of `addr` within the
passed-in object, before knowing if `addr` even lands within the
passed-in object's address range. If `addr` is before the object's
address, it does an unsigned underflow, which I guess works, but is not
really intuitive. Change it to check whether `addr` falls within the
object first, and if so, compute the offset of `addr` within the object.
Change-Id: Ibbacab6d57e693e02e2bdfec4f3a7d42d9a1bd4b Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Wed, 12 Nov 2025 19:59:13 +0000 (12:59 -0700)]
Make blockvector a little more self-contained
This patch changes blockvector to be a little more self-contained.
The idea here is that code outside of blockvector shouldn't really
know how it operates. After this patch, this still doesn't fully
happen -- a couple spots check the result of map() and make decisions
based on that -- but this is a step toward making that happen. The
longer term idea here is that this is needed to enable lazier CU
expansion.
Meanwhile, this patch seems like a simple cleanup. Relocation is now
handled by the blockvector itself and the non-const map() method can
be removed.
There wasn't a great spot to move the section_offsets typedef. I
chose defs.h. I've also updated the comment there as it has been out
of date for a long time. I've also removed an obsolete comment from
the symbol-relocation code.
Regression tested on x86-64 Fedora 40.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Wed, 19 Nov 2025 10:53:35 +0000 (11:53 +0100)]
[gdb/build] Handle gdbsupport and gdbserver in gdb.pot
Currently, when making gdb.pot:
...
$ cd build/gdb
$ make po/gdb.pot
test -d po || mkdir po
sh -e /data/vries/gdb/src/gdb/po/gdbtext /usr/bin/xgettext gdb . /data/vries/gdb/src/gdb
$
...
only strings from build/gdb and gdb are added.
Also add strings from gdbsupport and gdbserver.
Update gdb/po/gdbtext to handle the .cc files in gdbsupport and gdbserver.
defines VER_NDX_LOCAL to 0 with a comment, "Symbol has local scope". This
leads to different interpretations by different linker implementations.
However Solaris as well as ld and ld.so in glibc always treat symbols
with version index 0 as unversioned symbols with global binding. As
discussed in
in hindsight, VER_NDX_NONE might be a better name. Ali from Oracle is
working on clarifying what version index 0 really means for unversioned
symbols with global binding. In the meantime, update gold to treat
symbols with version index 0 as unversioned with global binding.
Simon Marchi [Mon, 17 Nov 2025 21:32:56 +0000 (16:32 -0500)]
gdb: revert std -> gdb unordered_map change in x86-nat.c
This particular change in commit 965deba1208 ("gdb: use
gdb::unordered_{set,map} at a few places") causes some regressions,
for instance when running gdb.base/catch-fork-kill.exp:
(gdb) PASS: gdb.base/catch-fork-kill.exp: fork-kind=fork: exit-kind=exit: fork: continue to child fork
continue^M
Continuing.^M
[Attaching after Thread 0x7ffff7e74740 (LWP 490949) fork to child process 490952]^M
[New inferior 2 (process 490952)]^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".^M
=================================================================^M
^[[1m^[[31m==490919==ERROR: AddressSanitizer: heap-use-after-free on address 0x7c9bac051d88 at pc 0x55f46adc7583 bp 0x7ffc862a1e90 sp 0x7ffc862a1e80
Function x86_linux_nat_target::low_new_fork calls function
x86_debug_reg_state twice in a row. The first one returns a reference
to an x86_debug_reg_state object in the map. The second causes an
insertion to be made, moving the first object, rendering the first
reference invalid.
Revert the change and add a comment indicating that the location of
x86_debug_reg_state objects is important.
Simon Marchi [Mon, 17 Nov 2025 17:57:32 +0000 (12:57 -0500)]
gdb/netbsd: fix fallout of thread_info ptr to ref change
Fix:
CXX netbsd-nat.o
/home/smarchi/src/binutils-gdb/gdb/netbsd-nat.c: In function 'void nbsd_resume(nbsd_nat_target*, ptid_t, int, gdb_signal)':
/home/smarchi/src/binutils-gdb/gdb/netbsd-nat.c:481:10: error: base operand of '->' has non-pointer type 'thread_info'
481 | if (tp->ptid.lwp () == ptid.lwp ())
| ^~
... following the changes that made thread iterators yield references
instead of points (e.g. 1ad8737b3c5 ("gdb: change inf_threads_iterator
to yield references")).
Tom de Vries [Mon, 17 Nov 2025 16:33:04 +0000 (17:33 +0100)]
[gdb] Rewrite strings in producer_parsing_tests
I noticed some odd-looking strings in producer_parsing_tests, like this one:
...
static const char extern_f_14_0[] = "\
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on \
Intel(R) 64, \
Version 14.0.1.074 Build 20130716";
...
Rewrite this in a more regular style:
...
static const char extern_f_14_0[]
= ("Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on"
" Intel(R) 64, Version 14.0.1.074 Build 20130716");
...
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Mon, 17 Nov 2025 16:33:03 +0000 (17:33 +0100)]
[gdb] Fix producer_is_gas comment
The comment for producer_is_gas in gdb/producer.h:
...
/* Returns nonzero if the given PRODUCER string is GAS and sets the MAJOR
and MINOR versions when not NULL. Returns zero if the given PRODUCER
is NULL or it isn't GAS. */
bool producer_is_gas (const char *producer, int *major, int *minor);
...
uses 'nonzero' and 'zero', while the return type is bool.
Fix this by using 'true' and 'false' instead.
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Thu, 13 Nov 2025 21:43:56 +0000 (16:43 -0500)]
gdb: use gdb::unordered_{set,map} at a few places
Use the gdb:: set/map types instead of the std:: ones. I only changed
places in files I can build on my dev machine.
I needed to explicitly default the move constructor and assigment
operator in proc_mem_file. I think this is ok, as nothing takes the
address of a proc_mem_file, requiring it not to move.
I also needed to do it for refcnt_fd, in solib-rocm.c. It's a bit odd
to prevent moving / copying a refcnt_fd, as this struct doesn't directly
hold a resource, but I think I get why it was done.
Change-Id: If6f2d7ba3b1ae338eba38b0ab9f987400e661dff Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Mon, 17 Nov 2025 16:29:31 +0000 (17:29 +0100)]
[gdb/i18n] Use c++ in po/gdbtext
I came across a script gdb/po/gdbtext:
...
$ ./po/gdbtext
Usage: ./po/gdbtext <xgettext> <package> <directory> ...
...
When using it, I get:
...
$ ./po/gdbtext xgettext gdb ../gdb ../gdbsupport/ ../gdbserver/
unittests/memory-map-selftests.c:30: warning: unterminated string literal
unittests/memory-map-selftests.c:41: warning: unterminated string literal
$
...
due to raw strings being used in unittests/memory-map-selftests.c.
Fix this by updating the language used in ./po/gdbtext to C++.
Ezra Sitorus [Mon, 17 Nov 2025 12:45:58 +0000 (12:45 +0000)]
gdb/aarch64: Tests for fpmr
Add tests for FPMR support in gdb/gdbserver. These tests check
availability of FPMR, reading/writing to FPMR, core file generation and
preservation under sighandler frame unwinding.
A run of the full gdb testsuite has been done on aarch64-none-linux-gnu
without FPMR support. The gdb.arch tests were run on Shrinkwrap with
FPMR support.
Approved-By: Luis Machado <luis.machado.foss@gmail.com>
Ezra Sitorus [Mon, 17 Nov 2025 12:45:58 +0000 (12:45 +0000)]
bfd/ELF: Core file support for AArch64 FPMR
The Floating Point Mode Register is a new register which controls the
behaviour of FP8 instructions. This is handled by the Linux kernel
through a new NT_ARM_FPMR register set.
This patch adds required code to support core file dumps with
NT_ARM_FPMR in them.
Jan Vrany [Mon, 17 Nov 2025 10:15:28 +0000 (10:15 +0000)]
gdb: change find_compunit_symtab_by_address to find_symbol_by_address
This commit changes objfile::find_compunit_symtab_by_address and
corresponding quick_symbol_functions::find_compunit_symtab_by_address
to find_symbol_by_address return symbol.
This will allow simplifying find_symbol_at_address (the only caller of
find_compunit_symtab_by_address) by removing the special-case for
-readnow and moving the logic down to readnow_functions.
Markus Metzger [Fri, 1 Aug 2025 09:53:44 +0000 (09:53 +0000)]
gdb, remote: fix set_thread () in start_remote ()
remote_target::start_remote_1 () calls set_continue_thread (minus_one_ptid)
with the intent to
/* Let the stub know that we want it to return the thread. */
set_continue_thread (minus_one_ptid);
I interpret it such that it expects a later get_current_thread () to
return the thread selected by the target:
/* We have thread information; select the thread the target
says should be current. If we're reconnecting to a
multi-threaded program, this will ideally be the thread
that last reported an event before GDB disconnected. */
ptid_t curr_thread = get_current_thread (wait_status);
This results in the packet sequence Hc-1, qC.
Hc simply sets cont_thread:
else if (cs.own_buf[1] == 'c')
cs.cont_thread = thread_id;
write_ok (cs.own_buf);
and qC returns the general thread. This doesn't match.
It also has some special treatment for null_ptid and minus_one_ptid:
Similarly, Hg has some special treatment for null_ptid:
if (cs.own_buf[1] == 'g')
{
if (thread_id == null_ptid)
{
/* GDB is telling us to choose any thread. Check if
the currently selected thread is still valid. If
it is not, select the first available. */
thread_info *thread = find_thread_ptid (cs.general_thread);
if (thread == NULL)
thread = get_first_thread ();
thread_id = thread->id;
}
cs.general_thread = thread_id;
The comment at Hg matches the intent of GDB for sending Hc-1.
Change the set_thread () call in remote_target::start_remote_1 () to
set_general_thread (any_thread_ptid);
This results in GDB sending Hg0 and gdbserver preserving the currently
selected thread that is later returned in response to qC.
CC: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 17 Nov 2025 05:03:48 +0000 (00:03 -0500)]
gdb: build solib-svr4-linux.o when building for targets xtensa*-*-*linux*
When building a GDB configured with --target=xtensa-buildroot-linux-uclibc, we get:
CXXLD gdb
/usr/bin/ld: xtensa-linux-tdep.o: in function `xtensa_linux_init_abi(gdbarch_info, gdbarch*)':
/home/simark/src/binutils-gdb/gdb/xtensa-linux-tdep.c:115:(.text+0x102): undefined reference to `make_linux_ilp32_svr4_solib_ops(program_space*)'
Fix it by adding solib-svr4-linux.o to the list of objects build for
targets xtensa*-*-*linux*.
This change fixes issues with dynamic relocations. We now support
R_PARISC_FPTR64 relocations for local symbols for both LTOFF and
simple FPTR64 relocations. Allocation of dynrel relocations is
revised along the lines of ia64. OPDs are reduced in size to 16
bytes so .opd section is now identical to that generated by the
HP linker.
Small applications now link and run successfully on HP-UX but better
stub support is needed for executables larger than roughly 8 MB.
Many PCREL22F branches can't reach their target. This prevents
building any recent version of gcc.
2025-11-16 John David Anglin <danglin@gcc.gnu.org>
bfd/ChangeLog:
* elf64-hppa.c (OPD_ENTRY_SIZE): Change to 16 bytes.
(elf64_hppa_check_relocs): Revise maybe_dynamic calculation.
Revise R_PARISC_FPTR64 case to request dynrel when hh is
not NULL. Add local symbols to local dynamic symbol table.
Always add global symbols to dynamic symbol table when a
dynrel may be needed.
(allocate_global_data_opd): Update OPD entry allocation
for reduced OPD size.
(allocate_dynrel_entries): Rework along the lines of ia64.
(elf64_hppa_late_size_sections): Revise DLT allocation.
Revise OPD allocation.
(elf64_hppa_finalize_opd): Revise for reduced OPD size.
Remove unnecessary NULL check.
(elf64_hppa_finalize_dlt): Remove unnecessary NULL check.
(elf64_hppa_finalize_dynreloc): Rework along the lines of
ia64. Correct relocation handling.
(elf_hppa_final_link_relocate): Don't zero first two words
of OPD. Update relocation handling to output EPLT and
FPTR64 relocations for local symbols.
H.J. Lu [Sat, 15 Nov 2025 23:21:48 +0000 (07:21 +0800)]
ld-elfvers: Remove vers8.c
commit c8a8d3bb27743c6894b7d5406a84e809965b9266
Author: Ian Lance Taylor <ian@airs.com>
AuthorDate: Thu Mar 13 02:46:09 1997 +0000
Commit: Ian Lance Taylor <ian@airs.com>
CommitDate: Thu Mar 13 02:46:09 1997 +0000
Wed Mar 12 21:44:19 1997 Eric Youngdale <eric@andante.jic.com>
* ld-elfvers/vers.exp, *: New tests for symbol versioning.
* config/default.exp: Set ar and strip.
Maximilian Ciric [Fri, 14 Nov 2025 20:58:06 +0000 (20:58 +0000)]
MIPS/GAS: Select symbolic GPR and FPR names based on current ABI setting
Add GPR and FPR symbolic register names to GAS for all ABI choices,
selecting the set of names based on the ABI being assembled for.
This extends the existing feature where the oldabi and newabi would
provide different symbolic GPR names to the assembler. Both EABIs and
o64 are now supported along with symbolic FPR names for all ABI choices.
Signed-off-by: Maximilian Ciric <max.ciric@gmail.com>
Simon Marchi [Thu, 13 Nov 2025 21:51:58 +0000 (16:51 -0500)]
gdb: add microblaze-linux.xml to XMLTOC, regenerate microblaze-linux.c
microblaze-linux.c is out of date compared to the other .c files in the
features directory. I think it's because it's missing from XMLTOC. Add
it there and run the "cfiles" target, causing the updates to
microblaze-linux.c.
I thought that we could get rid of regformats/microblaze-linux.dat,
since microblaze-linux is described with an XML target, but apparently
not, I don't really understand (or forget) how these things work.
Change-Id: Idaa55980b3bbdcc6597e9bf332d5824759ef9d0f Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 13 Nov 2025 21:46:53 +0000 (16:46 -0500)]
gdb: remove tic6x .dat files
The tix6x gdbserver port was modified to use target descriptions in
commit 506fe5f49967 ("Change tic6x target descriptions"). The old
regformats .dat files were kept as a way to make sure the new target
descriptions matched the old register decsriptions. I think by now it's
not necessary to keep the .dat files.
I don't have a way to build-test this though.
Change-Id: Ia90b5ae6381234c6e95555201d3e65ed9be880ea Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 13 Nov 2025 21:00:48 +0000 (16:00 -0500)]
gdb, gdbsupport: use DISABLE_COPY_AND_ASSIGN in a few spots
Replace some explicitly deleted copy constructor and copy assignment
operator with the DISABLE_COPY_AND_ASSIGN macro for consistency
with the rest of the codebase.
Change-Id: If3fe2c4d7b3cb4530eace86d589116f805c7656f Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Tue, 4 Nov 2025 15:56:08 +0000 (08:56 -0700)]
Reject negative children in DAP
This changes DAP to ignore the case where a pretty-printer returns a
negative number from the num_children method. It didn't seem worth
writing a test case for this.
Tom Tromey [Tue, 4 Nov 2025 21:07:12 +0000 (14:07 -0700)]
Have DAP handle multiple breakpoints at same location
A user pointed out that if multiple breakpoints are set at the same
spot, in DAP mode, then changing the breakpoints won't reset all of
them.
The problem here is that the breakpoint map only stores a single
breakpoint, so if two breakpoints have the same key, only one will be
stored. Then, when breakpoints are changed, the "missing" breakpoint
will not be deleted.
The fix is to change the map to store a list of breakpoints.
Tom de Vries [Fri, 14 Nov 2025 10:43:44 +0000 (11:43 +0100)]
[gdb/testsuite] Fix gdb.rust/methods.exp on i686-linux
On i686-linux, with test-case gdb.rust/methods.exp I get:
...
(gdb) print x.take()
$5 = methods::HasMethods {value: 4}
(gdb) FAIL: $exp: print x.take()
...
The instructions for the function methods::HasMethods::take look like this:
... 00007b90 <_ZN7methods10HasMethods4take17hf373500ea3bd6e27E>:
7b90: 8b 44 24 04 mov 0x4(%esp),%eax
7b94: c3 ret
...
which is equivalent to what you get for:
...
$ cat test.c
int foo (int val) { return val; }
$ gcc test.c -O2 -S -o-
...
movl 4(%esp), %eax
ret
...
$
...
The inferior call mechanism however decides that this is a return_method_struct
function, and adds an implicit first parameter pointing to the return value
location. Then two things go wrong:
- the argument is written to a place where the code doesn't read from, and
- the return value is read from a place where the code doesn't write to.
AFAIU, both gdb and rustc are behaving correctly:
- there's no stable ABI and consequently rustc is at liberty to optimize this
function how it wants, and
- gdb cannot be expected to target an unstable ABI.
The solution is to mark the function for interoperability using 'extern "C"'.
Doing so causes a compilation warning:
...
warning: `extern` fn uses type `HasMethods`, which is not FFI-safe
--> gdb.rust/methods.rs:50:28
|
50 | pub extern "C" fn take(self) -> HasMethods {
| ^^^^ not FFI-safe
|
= help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute
to this struct
= note: this struct has unspecified layout
...
which we fix by using '#[repr(C)]'.
Jens Remus [Fri, 14 Nov 2025 08:42:13 +0000 (09:42 +0100)]
s390: Mention GOTIE20 relocation in TLS related comment
Commit bd1ea41b84b0 introduced the R_390_TLS_GOTIE20 relocation, but
missed to update a comment that mentions the related R_390_TLS_GOTIE12
relocation.
bfd/
* elf32-s390.c (allocate_dynrelocs): Mention GOTIE20 relocation
in TLS related comment.
* elf64-s390.c (allocate_dynrelocs): Likewise.
Jens Remus [Fri, 14 Nov 2025 08:42:13 +0000 (09:42 +0100)]
s390: Do not emit orphaned GOT entry for TLS IE to LE transition
Commit 69fc87f180bf introduced TLS support for s390 32-bit and 64-bit.
It defined GOT_TLS_IE_NLT in both elf32-s390.c and elf64-s390.c, but
erroneously assigned it the same value as GOT_TLS_IE in elf64-s390.c.
As a consequence the linker for s390 64-bit erroneously emitted an
orphaned GOT entry when performing TLS Initial Exec (IE) to Local
Exec (LE) transition optimization.
Correct the value of GOT_TLS_IE_NLT in elf64-s390.c. This causes the
liker to actually optimize away the GOT entry when performing IE to LE
transition. While at it add a comment that the suffix NLT denotes
"no literal (pool entry)".
Found while inspecting and cleaning up differences between elf32-s390.c
and elf64-s390.c.
bfd/
* elf32-s390.c (GOT_TLS_IE_NLT): Add comment that NLT denotes
no literal pool entry.
* elf64-s390.c (GOT_TLS_IE_NLT): Likewise. Correct value.
ld/testsuite/
* ld-s390/tlsbin_64.dd: Adjust expected test results.
* ld-s390/tlsbin_64.sd: Likewise.
Jens Remus [Fri, 14 Nov 2025 08:42:13 +0000 (09:42 +0100)]
s390: Check sreldynrelro in elf_s390_finish_dynamic_symbol
Add check for sreldynrelro being NULL, introduced by commit 5474d94f03ae
("dynrelro section for read-only dynamic symbols copied into
executable") in elf32-s390.c function elf_s390_finish_dynamic_symbol,
also to its elf64-s390.c counterpart.
Found while inspecting and cleaning up differences between elf32-s390.c
and elf64-s390.c.
bfd/
* elf64-s390.c (elf_s390_finish_dynamic_symbol): Add
sreldynrelro check from elf32-s390.c.
Fixes: 5474d94f03ae ("dynrelro section for read-only dynamic symbols copied into executable") Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Jens Remus [Fri, 14 Nov 2025 08:42:12 +0000 (09:42 +0100)]
s390: Increment PC-relative relocation count for PC24DBL relocs
Commit fb798c50b2c8 added the R_390_PC24DBL relocation. Due to a copy
and paste error it messed up to increment the PC-relative relocation
count in elf64-s390.c function elf_s390_check_relocs (i.e. duplicate
check for R_390_PC16DBL).
Found while inspecting and cleaning up differences between elf32-s390.c
and elf64-s390.c.
bfd/
* elf64-s390.c (elf_s390_check_relocs): Increment PC-relative
relocation count for R_390_PC24DBL.
Jan Beulich [Fri, 14 Nov 2025 08:03:49 +0000 (09:03 +0100)]
bfd/ELF: properly mark bfd_elf_{,gc_common_}final_link() as private
They're solely used as hook functions (or helpers thereof), so aren't
intended to be invoked directly from outside the library. Add underscore
prefixes and make them hidden.
Jan Beulich [Fri, 14 Nov 2025 08:03:25 +0000 (09:03 +0100)]
bfd/ELF: nds32_convert_{16_to_32,32_to_16}() are exposed to gas
As non-private functions, they should come with full disambiguating
prefixes - add bfd_elf_ to both. Hence commit bf4128d0cc6d2 ("bfd/ELF:
mark internal NDS32 functions hidden") also wrongly added ATTRIBUTE_HIDDEN
to them.
Jan Beulich [Fri, 14 Nov 2025 08:03:06 +0000 (09:03 +0100)]
bfd/ELF: loongarch_{larch_reloc_name_lookup,adjust_reloc_bitsfield}() are exposed to gas
As non-private functions, they should come with full disambiguating
prefixes - add bfd_elf_ to both. Hence commit 2903d813fcc2 ("bfd/ELF: mark
internal LoongArch functions hidden") also wrongly added ATTRIBUTE_HIDDEN
to them.
While loongarch_get_uleb128_length() also falls in the same category,
having it live in libbfd, when outside of gas there's hardly any use to be
expected, isn't very useful. Drop the function altogether and simplify the
clearing of the ULEB128 in md_apply_fix().
For loongarch_larch_reloc_name_lookup() drop gas'es custom declaration;
the libbfd one ought to be used, for producer and consumer to "see" the
same one. Also drop ATTRIBUTE_UNUSED there, as that makes sense only for
parameters in function definitions.
Simon Marchi [Thu, 13 Nov 2025 16:47:08 +0000 (11:47 -0500)]
gdb: fix flake8 warnings in gdb.base/gdb-index-many-types.py
Fix those:
gdb/testsuite/gdb.base/gdb-index-many-types.py:17:18: F821 undefined name 'gdb'
gdb/testsuite/gdb.base/gdb-index-many-types.py:26:42: F821 undefined name 'gdb'
gdb/testsuite/gdb.base/gdb-index-many-types.py:29:16: F821 undefined name 'gdb'
gdb/testsuite/gdb.base/gdb-index-many-types.py:31:19: F821 undefined name 'gdb'
gdb/testsuite/gdb.base/gdb-index-many-types.py:33:16: F821 undefined name 'gdb'
gdb/testsuite/gdb.base/gdb-index-many-types.py:33:51: F821 undefined name 'gdb'
gdb/testsuite/gdb.base/gdb-index-many-types.py:47:17: E722 do not use bare 'except'
[gdb/symtab] Don't deduplicate variables in gdb-index
Which removed the de-duplication of variables. It is worth reading
the earlier commit as all the justifications for that patch also
apply to this one.
Currently, when building the gdb-index we sort the type entries,
moving declarations to the end of the entry list, and non-declarations
to the front. Then within each group, declarations, and
non-declarations, the index entries are sorted by CU offset.
We then emit the first entry for any given type name.
There are two problems with this.
First, a non-declaration entry could be a definition, but it could
also be a typedef. Now sure, a typedef is a type definition, but not
necessarily a useful one.
If we have a header file that contains:
typedef struct foo_t foo_t;
And a CU which makes use of 'foo_t', then the CU will include both a
typedef and a type declaration. The target of the typedef will be the
declaration. But notice, the CU will not include a type definition.
If we have two CUs, one which only sees the above typedef and
declaration, and another which sees the typedef and an actual type
definition, then the final list of entries for this type's name will
be:
1. A typedef entry that points at the declaration.
2. A typedef entry that points at the definition.
3. A definition.
4. A declaration.
Now (4) will get sorted to the end of the entry list. But the order
of (1), (2), and (3) will depend on the CU offset. If the CU which
containing the typedef and declaration has the smallest offset,
then (1) will be sorted to the front of the list of entries for this
type name. Due to the de-duplication code this means that only (1)
will be added to the gdb-index.
After GDB starts and parses the index, if a user references 'foo_t'
GDB will look in the index and find just (1). GDB loads the CU
containing (1) and finds both the typedef and the declaration. But
GDB does not find the full type definition. As a result GDB will
display 'foo_t' as an incomplete type.
This differs from the behaviour when no index is used. With no index
GDB expands the first CU containing 'foo_t', finds the typedef and
type declaration, decides that this is not good enough and carries on.
GDB will then expand the second CU and find the type's definition, GDB
now has a full understanding of the type, and can print the type
correctly.
We could solve this problem by marking typedefs as a distinct
sub-category of types, just as we do with declarations. Then we could
sort definitions to the front of the list, then typedefs, and finally,
declarations after that. This would, I think, mean that we always
prefer emitting a definition for a type, which would resolve this
first problem, or at least, it would resolve it well enough, but it
wouldn't fix the second problem.
The second problem is that the Python API and the 'info types' command
can be used to query all type symbols. As such, GDB needs to be able
to find all the CUs which contain a given type. Especially as it is
possible that a type might be defined differently within different
CUs.
NOTE: Obviously a program doing this (defining a type differently in
different CUs) would need to be mindful of the One Definition Rule,
but so long as the type doesn't escape outside of a single CU then
reusing a type name isn't, as I understand it, wrong. And even if
it is, the fact that it compiles, and could be a source of bugs,
means (in my opinion) that GDB should handle this case to enable
debugging of it.
Even something as simple as 'info types ....' relies on GDB being able
to find multiple entries for a given type in different CUs. If the
index only contains a single type entry, then this means GDB will see
different things depending on which CUs happen to have been expanded.
Given all of the above, I think that any attempt to remove type
entries from the gdb-index is unsafe and can result in GDB behaving
differently when using the gdb-index compared to using no index.
The solution is to remove the de-duplication code, which is what this
patch does.
Now that we no longer need to sort declarations to the end of the
entry list, I've removed all the code related to the special use of
GDB_INDEX_SYMBOL_KIND_UNUSED5 (which is how we marked declarations),
this cleans things up a little bit.
I've also renamed some of the functions away from minimize, now that
there's no minimization being done.
A problem was revealed by this change. When running the test
gdb.cp/stub-array-size.exp with the --target_board=cc-with-gdb-index,
I was seeing a failure using gcc 15.1.0.
This test has two CUs, and a type 'A'. The test description says:
Test size of arrays of stubbed types (structures where the full
definition is not immediately available).
Which I don't really understand given the test's source code. The
type 'A' is defined in a header, which is included in both CUs.
However, the test description does seem to be accurate; in one CU the
type looks like this:
So, for reasons that I don't understand, the type, despite (as far as
I can see) having its full definition available, is recorded only as
declared in one CU.
The test then performs some actions that rely on 'sizeof(A)' and
expects GDB to correctly figure out the size. This requires GDB to
find, and expand the CU containing the real definition of 'A'.
Prior to this patch GDB would sort the two type entries for 'A',
placing the declaration second, and then record only one entry, the
definition. When it came to expansion there was only one thing to
expand, and this is the declaration we needed. It happens that in
this test the definition is in the second CU, that is, the CU with the
biggest offset. This means that, if all index entries were considered
equal, the definition entry would be second. However, currently, due
to the way GDB forces definitions to the front, the entry for the
second CU, the definition, is placed first in the index, and with
de-duplication, this is the only entry added to the index.
After this patch, both the declaration and the definition are placed
in the index, and as the declaration is in the CU at offset 0, the
declaration is added first to the index.
This should be fine. When looking for 'A' GDB should expand the CU
containing the declaration, see that all we have is a declaration, and
so continue, next expanding the definition, at which point we're done.
However, in read-gdb-index.c, in the function
mapped_gdb_index::build_name_components, there is a work around for
gold bug PR gold/15646. Ironically, the bug here is that gold was not
removing duplicate index entries, and it is noted that this has a
performance impact on GDB. A work around for this was added to GDB in
commit:
[gdb/symtab] Make gold index workaround more precise
The problem specifically called out in the bug report is that
namespaces can appear in multiple CUs, and that trying to complete
'ns::misspelled' would expand every CU containing namespace 'ns' due
to the duplicate 'ns' type symbols.
The work around that was added in 8943b874760d9cf3 was to ignore
duplicate global symbols when expanding entries from the index. In
commit f030440daa989ae3 this work around was restricted to only ignore
duplicate type entries. This restriction was required to allow the
earlier de-duplication patch aef36dee93bf194c to function correctly.
Now that I'm taking the work started in aef36dee93bf194c to its
logical conclusion, and allowing duplicate type entries, the work
around of ignoring duplicate global type symbols is no longer needed,
and can be removed.
The associated test for this, added in 40d22035a7fc239a, is also
removed in this commit.
To be clear; the performance issue mentioned in PR gold/15646 is now
back again. But my claim is that gold was right all along to include
the duplicate index entries, and any performance hit we see as a
result, though unfortunate, is just a consequence of doing it right.
That doesn't mean there's not room for optimisation and improvement in
the future, though I don't have any immediate ideas, or plans in this
area. It's just we can't throw out a bunch of index entries that are
critical, and claim this as a performance optimisation.
I am seeing some failure with this patch when using the board file
dwarf5-fission-debug-types. These failures all have the error:
DWARF Error: wrong unit_type in unit header (is DW_UT_skeleton, should be DW_UT_type) [in module ....]
However, I ran the whole testsuite with this board, and this error
crops up often, so I don't think this is something specific to my
patch, so I'm choosing to ignore this.
Andrew Burgess [Wed, 29 Oct 2025 19:39:44 +0000 (19:39 +0000)]
gdb: symbol_search objects of different types are not the same
Consider the C construct:
typedef struct foo
{
int a;
int b;
} foo;
GDB will see two types here, 'struct foo' and the typedef 'foo'.
However, if we use 'info types foo' we will see this:
File test.c:
18: struct foo;
At least that's what I see with current HEAD of master. However, it
is really just luck that we see the 'struct' here. See more below.
When searching for symbols matching 'foo' GDB ends up in the function
global_symbol_searcher::add_matching_symbols, where we consider all
possible matching symbols. This will include the 'struct foo' and the
typedef 'foo'. However, before a new symbols is added to the results,
we attempt to remove duplicates with this code:
/* Match, insert if not already in the results. */
symbol_search ss (block, sym);
if (result_set->find (ss) == result_set->end ())
result_set->insert (ss);
If a symbol is already present in result_set then it will not be added
a second time.
The symbol_search equality check is done using the function
symbol_search::compare_search_syms, this function does a number of
checks, but at the end, any two symbols that are in the same block
within the same file, with the same name, are considered the same,
even if the types of those symbols are different.
This makes sense in most cases, it usually wouldn't make sense to have
two symbols within a single block with different types. But the
'struct foo' and typedef 'foo' case is a bit of a strange one. Within
DWARF and GDB we consider both of these as just types. But in C
types and structure names live in different namespaces, and so we can
have both in the same block. I don't think that GDB should consider
these two as the same, especially if we consider something really
ill-advised like this:
struct foo
{
int a;
int b;
};
typedef int foo;
This is perfectly valid C code, 'struct foo' and the typedef 'foo' are
in different namespaces, and can be used within the same block. But
please, never write C code like this.
Given the above, I think, when asked about 'foo', GDB should, report
both 'struct foo' and the typedef 'foo'.
To do this I propose extending symbol_search::compare_search_syms such
that if two symbol_search objects are in the same block, within the
same file, and they have the same name, then if just one of them is a
typedef, the two objects will not be considered equal. The results
will be sorted by line number if the line numbers are different, or,
if the line numbers are the same, the non-typedef will be sorted
first. This means that for something like this:
I mentioned earlier that it is really just luck that we see 'struct
foo'. I ran into this problem while working on another patch. When
testing with the 'debug-types' board file I was seeing the typedef
being reported rather than the struct. In "normal" DWARF given the
'typedef struct foo { ...} foo;' construct, the compiler will usually
emit the struct definition first, and then the typedef definition. So
when GDB parses the DWARF it sees the struct first. It is the typedef
that becomes the duplicate which is not added to the results list.
But with the 'debug-types' board the compiler moves the struct
definition out to the .debug_types section. And GDB now parses the CU
containing the typedef first, and then expands the structure
definition from the separate section afterwards. As a result, it is
the structure that is now considered the duplicate, and the typedef is
the result that gets reported.
I think this is yet another motivation for this patch. Changes like
this (the use of .debug_types section) shouldn't impact what results
GDB shows to the user.
There is an interesting update to the gdb.base/info-types.exp.tcl test
script. In this case the C results only needed to change to include
the typedef. The C++ results already included both the struct and the
typedef in the expected results. The reason for this is that C places
both the struct baz_t and the typedef for baz_t into the global block,
while C++ places the struct in the global block, and the typedef into
the static block. I have no idea why there's a difference in the
placement, but I'm choosing to believe the difference is correct. But
this explains why only the C results needed to change. If anything
this (I think) is yet another justification for this change; having C
not show the typedef in this case seems weird when the same source
code compiled as C++ does show the typedef.
Tom de Vries [Wed, 12 Nov 2025 10:08:31 +0000 (11:08 +0100)]
[gdb/testsuite] Use -std=c99 in gdb.base/nodebug.exp
With test-case gdb.base/nodebug.exp I run into:
...
gdb compile failed, gdb.base/nodebug.c: In function 'multf_noproto':
gdb.base/nodebug.c:63:1: warning: old-style function definition \
[-Wold-style-definition]
63 | multf_noproto (v1, v2)
| ^~~~~~~~~~~~~
...
Printing the variable in C mode:
...
$ gdb -q -batch outputs/gdb.rust/simple/simple \
-ex "b 161" \
-ex run \
-ex "set language c" \
-ex "p /x str_none"
...
$1 = {0x80000000, Some = {__0 = {vec = {buf = {inner = {ptr = {pointer = {pointer = 0xbfffedd8}, _marker = {<No data fields>}}, cap = {__0 = 0x80000000}, alloc = {<No data fields>}}, _marker = {<No data fields>}}, len = 0x41f083}}}}
...
shows us that the discriminant value is 0x80000000, which matches the "None"
variant:
...
<3><1427>: Abbrev Number: 16 (DW_TAG_structure_type)
<1428> DW_AT_name : Option<alloc::string::String>
<142c> DW_AT_byte_size : 12
<142d> DW_AT_accessibility: 1 (public)
<142e> DW_AT_alignment : 4
<4><142f>: Abbrev Number: 47 (DW_TAG_variant_part)
<1430> DW_AT_discr : <0x1434>
<5><1434>: Abbrev Number: 48 (DW_TAG_member)
<1435> DW_AT_type : <0x2cba>
<1439> DW_AT_alignment : 4
<143a> DW_AT_data_member_location: 0
<143b> DW_AT_artificial : 1
<5><143b>: Abbrev Number: 52 (DW_TAG_variant)
<143c> DW_AT_discr_value : 0x80000000
<6><1440>: Abbrev Number: 4 (DW_TAG_member)
<1441> DW_AT_name : None
<1445> DW_AT_type : <0x145a>
<1449> DW_AT_alignment : 4
<144a> DW_AT_data_member_location: 0
<6><144b>: Abbrev Number: 0
<5><144c>: Abbrev Number: 51 (DW_TAG_variant)
<6><144d>: Abbrev Number: 4 (DW_TAG_member)
<144e> DW_AT_name : Some
<1452> DW_AT_type : <0x146c>
<1456> DW_AT_alignment : 4
<1457> DW_AT_data_member_location: 0
<6><1458>: Abbrev Number: 0
<5><1459>: Abbrev Number: 0
...
but the dynamic type resolves to the "Some" variant instead.
This is caused by signedness confusion.
The DW_AT_discr_value 0x80000000 is encoded as an LEB128 number, and the
signedness is determined by the "tag type for the variant part", which in this
case is unsigned:
...
<1><2cba>: Abbrev Number: 6 (DW_TAG_base_type)
<2cbb> DW_AT_name : u32
<2cbf> DW_AT_encoding : 7 (unsigned)
<2cc0> DW_AT_byte_size : 4
...
However, the value gets interpreted as signed instead (value printed in
resolve_dynamic_struct):
...
(gdb) p /x variant_prop.m_data.variant_parts.m_array.variants.m_array[0].discriminants.m_array[0]
$3 = {low = 0xffffffff80000000, high = 0xffffffff80000000}
...
and then compared against an unsigned 0x80000000 in variant::matches().
Fix this in create_one_variant_part, by passing the required signedness as a
parameter to create_one_variant.
Tested on i686-linux and x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR rust/33620
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33620
Tom de Vries [Tue, 11 Nov 2025 19:47:33 +0000 (20:47 +0100)]
[gdb/testsuite] Fix sizeof test in gdb.rust/simple.exp
On x86_64-linux, with test-case gdb.rust/simple.exp I get:
...
(gdb) print sizeof(e)^M
$52 = 24^M
(gdb) PASS: $exp: print sizeof(e)
...
but on i686-linux I get instead:
...
(gdb) print sizeof(e)^M
$52 = 20^M
(gdb) FAIL: $exp: print sizeof(e)
...
The variable e for which we print the size:
...
let e = MoreComplicated::Two(73);
...
has type MoreComplicated which is defined like this:
...
pub struct HiBob {
pub field1: i32,
field2: u64,
}
...
enum MoreComplicated {
One,
Two(i32),
Three(HiBob),
Four{this: bool, is: u8, a: char, struct_: u64, variant: u32},
}
...
The answer to the question what the size of the enum should be seems to be
non-trivial [1][2], but AFAICT it doesn't seem to be illegal that the size can
differ between different platforms.
Fix this by accepting both 20 and 24 as valid size.
Tested on x86_64-linux and i686-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://doc.rust-lang.org/reference/types/enum.html
[2] https://doc.rust-lang.org/reference/type-layout.html#the-rust-representation
Andrew Burgess [Wed, 26 Jul 2023 15:26:15 +0000 (16:26 +0100)]
gdb: use current executable for 'remote exec-file' in some cases
This commit allows GDB to make use of the file set with the 'file'
command when starting a new inferior on an extended-remote target.
There are however some restrictions.
If the user has used 'set remote exec-file', then this setting is
always used in preference to the file set with the 'file' command.
Similarly, if the qExecAndArgs packet has succeeded, and GDB knows
that the remote target has an executable set, then this will be used
in preference to the file set with the 'file' command; this preserves
GDB's existing behaviour. In effect, when GDB connects to the remote
target, the remote sets the 'remote exec-file' and this prevents GDB
from using the 'file' filename.
And, GDB can only use the file set with the 'file' command if it
believes that both GDB and the remote target will both be able to
access this file. This means that one of these is true:
+ the the remote_target::filesystem_is_local function returns
true (see the implementation of that function for details of when
this can happen). This means GDB and the remote target can see
the same file system, GDB can just use the current executable's
filename as is, or
+ the user has set the 'file' to something with a 'target:' prefix,
e.g. 'file target:/path/to/exec'. In this last case, GDB will use
the exec filename without the 'target:' prefix, this filename is,
by definition, something the remote target can see, or
+ the sysroot has been updated by the user and no longer contains a
'target:' prefix. In this case, if the 'file' filename is within
the sysroot, then it is assumed the remote will also be able to
see a file with the same filename. For example, if the sysroot is
'/aa/', and the current executable is '/aa/bb/cc', then GDB will
tell the remote to run '/bb/cc'. One common case here is when the
sysroot is set to the empty string, which is usually done when GDB
and the remote target can see the same filesystem, in this case
GDB will use the current executable's filename unmodified.
If one of these conditions is met, then GDB will use the current
executable's filename (with possible modifications as mentioned
above), when starting a new extended-remote inferior, in all other
cases, GDB will use the file name set with 'set remote exec-file'.
This change could be useful any time a user is running a remote target
on the same machine as GDB, but I am specifically thinking of the case
where GDB is using a tool other than gdbserver, e.g. valgrind, as this
saves one additional step that a user must remember. The current
steps to start valgrind with GDB, as given on the valgrind
website (https://valgrind.org/docs/manual/manual-core-adv.html) are:
With this GDB work, and once support for the qExecAndArgs packet is
added to valgrind, then the 'set remote exec-file' line can be dropped
from those instructions.
This commit also extends the 'show remote exec-file' command so that
GDB will display the automatic value that it plans to use. Here's an
example of the new output:
$ gdb -q /tmp/hello
Reading symbols from /tmp/hello...
(gdb) set sysroot
(gdb) target extended-remote | ./gdbserver/gdbserver --multi --once -
Remote debugging using | ./gdbserver/gdbserver --multi --once -
Remote debugging using stdio
(gdb) show remote exec-file
The remote exec-file is unset, using automatic value "/tmp/hello".
The last line shows the new output.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I45e0e77b00701aa979e8f7f15f397836b4e19849 Approved-By: Maciej W. Rozycki <macro@orcam.me.uk> Tested-By: Maciej W. Rozycki <macro@orcam.me.uk>
Alan Modra [Tue, 11 Nov 2025 04:03:57 +0000 (14:33 +1030)]
objcopy binary symbol test
A small tidy that allows other symbols or warnings to appear in nm
output, and works around the case problem of windows drive letters
by simply omitting the $srcdir match.
* testsuite/binutils-all/objcopy.exp (binary_symbol): Check
objcopy and nm return status. Don't repeat prune_warnings
already done in binutils_run. Match each symbol separately,
reporting which match failed on a failure. Don't match
$srcdir in implicit test.
Sven Schnelle [Mon, 10 Nov 2025 21:07:17 +0000 (22:07 +0100)]
gdb/hppa: guess g packet size
With qemu supporting 64 bit now, add some code to determine the
register size of a hppa remote target.
Signed-off-by: Sven Schnelle <svens@stackframe.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Iffade4e02d758b9cb20c8f206e812bf3205518f7
Tom de Vries [Mon, 10 Nov 2025 18:36:46 +0000 (19:36 +0100)]
[gdb/testsuite] Force DWARF in gdb.pascal
On i686-linux (and likewise arm-linux), I run into:
...
(gdb) file str-chars^M
Reading symbols from str-chars...^M
warning: stabs debug information is not supported.^M
(No debugging symbols found in str-chars)^M
(gdb) delete breakpoints^M
...
Fix this by using fpc option -gw2.
Tested on i686-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
PR testsuite/33564
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33564
Tom Tromey [Sun, 9 Nov 2025 18:27:30 +0000 (11:27 -0700)]
Add uses of _() to symmisc.c
A review of an earlier version of this series pointed out some missing
_() invocations in symmisc.c. This fixes the ones I thought were
appropriate. In some spots I chose not to add them because the text
didn't seem like something that ought to be translated.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
projects / thirdparty / binutils-gdb.git / log
