Tom Tromey [Wed, 19 Nov 2025 09:42:34 +0000 (02:42 -0700)]
Remove a call to blockvector::map
block_starting_point_at checks blockvector::map before doing a lookup.
This patch removes this call, a step toward making the blockvector API
a bit more opaque. It arranges to find the necessary blockvector just
once, in gather_inline_frames, and then uses the 'lookup' method to
find the desired block.
Note that this is a slight change of semantics, in that the old code
looked only in the map while the new code looks in the blockvector,
regardless of whether a map was made. However, I don't think this
should matter, and furthermore this seems like an abstraction
violation, with the inline-frame code knowing details of how buildsym
decided to create the blockvector.
in the longer run, I think only the 'lookup' method should be provided
by blockvector -- that is, separately checking the map should be
impossible. The idea here is that eventually, for lazy CU expansion,
we will want to be able to expand the blockvector. This may be easier
with a different underlying data structure, so perhaps the map will go
away entirely. After this patch, one such use remains.
Tom de Vries [Sat, 22 Nov 2025 15:44:48 +0000 (16:44 +0100)]
[gdb/testsuite] Rewrite strings in gdb.ada/unchecked_union.exp
In test-case gdb.ada/unchecked_union.exp, git --check reports some whitespace
issues:
...
$ git diff-tree --check $(git hash-object -t tree /dev/null) HEAD \
-- gdb/testsuite/gdb.ada/unchecked_union.exp \
| grep -c "indent with spaces"
12
...
The problem is that this style of string is used containing space-indented
text:
...
set inner_string { case ? is
when 0 =>
small: range 0 .. 255;
second: range 0 .. 255;
when ? =>
bval: range 0 .. 255;
when others =>
large: range 255 .. 510;
more: range 255 .. 510;
end case;
}
...
Fix this by changing the string into a list of strings:
...
set inner_string \
[list \
" case ? is" \
" when 0 =>" \
" small: range 0 .. 255;" \
" second: range 0 .. 255;" \
" when ? =>" \
" bval: range 0 .. 255;" \
" when others =>" \
" large: range 255 .. 510;" \
" more: range 255 .. 510;" \
" end case;"]
...
which also fixes the odd position of the first line in the original version.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR build/33616
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33616
Alan Modra [Fri, 21 Nov 2025 23:22:18 +0000 (09:52 +1030)]
PR 33639 .debug_loclists output
The fuzzed testcase in this PR prints an almost endless table of
offsets, due to a bogus offset count. Limit that count, and the total
length too.
PR 33639
* dwarf.c (display_loclists_unit_header): Return error on
length too small to read header. Limit length to section
size. Limit offset count similarly.
Alan Modra [Fri, 21 Nov 2025 22:52:10 +0000 (09:22 +1030)]
PR 33638, debug_rnglists output
The fuzzed testcase in this PR continuously outputs an error about
the debug_rnglists header. Fixed by taking notice of the error and
stopping output. The patch also limits the length in all cases, not
just when a relocation is present, and limits the offset entry count
read from the header. I removed the warning and the test for relocs
because the code can't work reliably with unresolved relocs in the
length field.
PR 33638
* dwarf.c (display_debug_rnglists_list): Return bool. Rename
"inital_length" to plain "length". Verify length is large
enough to read header. Limit length to rest of section.
Similarly limit offset_entry_count.
(display_debug_ranges): Check display_debug_rnglists_unit_header
return status. Stop output on error.
Alan Modra [Fri, 21 Nov 2025 22:45:00 +0000 (09:15 +1030)]
som foreign syms
The makes use of the copy_private_symbol_data change in order to
prevent bogus writes seen when running objcopy with binary input and
som output. It doesn't fix "FAIL: binary symbol", because the som
backend also doesn't copy binary sections to the output, a fact that I
didn't notice until I'd gone quite some way into fixing symbols..
* som.c (som_bfd_copy_private_symbol_data): Make som symbols
for non-som input.
Alan Modra [Fri, 21 Nov 2025 22:43:26 +0000 (09:13 +1030)]
bfd_copy_private_symbol_data
Allow copy_private_symbol_data to replace osym if a target desires.
Change isym similarly for symmetry. The idea is to make it possible
to give the asymbol an output target specific extension. Some
targets, eg. som, use such an extension when outputting symbols,
behaving badly if the input object is not som. There are no
functional changes in this patch; It just changes the signatures.
Alan Modra [Fri, 21 Nov 2025 22:39:12 +0000 (09:09 +1030)]
copy_private and merge_private functions
These are all called via BFD_SEND on the output bfd xvec. Thus there
is no need to verify the output bfd flavour. There *is* a need to
verify the input bfd flavour. Also of course target specific data
shouldn't be accessed until the input target is verified. Tidy these
issues in many places.
bfd_copy_private_section_data, bfd_copy_private_symbol_data, and
bfd_merge_private_bfd_data are macros. Delete prototypes created via
synopsis entry in comments.
timurgol007 [Fri, 21 Nov 2025 11:06:02 +0000 (14:06 +0300)]
RISC-V: Fixed opcodes for some bitmanip instructions
Currently some of the instructions in bitmanip extensions can not be obtained
using DECLARE_INSN macros. I generated them using riscv-opcodes and added to
other opcodes.
The problem happens as follows. In core_target_open, we do:
...
if (thread == NULL)
thread = add_thread_silent (target, ptid_t (CORELOW_PID));
...
and then in add_thread_silent:
...
struct thread_info *
add_thread_silent (process_stratum_target *targ, ptid_t ptid)
{
gdb_assert (targ != nullptr);
inferior *inf = find_inferior_ptid (targ, ptid);
...
find_inferior_ptid returns nullptr, which eventually causes the segfault.
So, why can't we find an inferior with CORELOW_PID?
A bit earlier in core_target_open, we do:
...
/* Find (or fake) the pid for the process in this core file, and
initialise the current inferior with that pid. */
bool fake_pid_p = false;
int pid = bfd_core_file_pid (target->core_bfd ());
if (pid == 0)
{
fake_pid_p = true;
pid = CORELOW_PID;
}
The warning is emitted because the pseudo-section .reg is missing, because
elf32_arm_nabi_grok_prstatus expects the PRSTATUS note to have size 148, but
instead we have:
...
$ eu-readelf -n core | grep -i prstatus
CORE 156 PRSTATUS
CORE 156 PRSTATUS
CORE 156 PRSTATUS
CORE 156 PRSTATUS
...
I'm assuming this is a bug for CONFIG_BINFMT_ELF_FDPIC=y configurations, fixed
by v5.9 linux kernel commit 16aead81018c ("take fdpic-related parts of
elf_prstatus out").
The core was generated using a kernel with CONFIG_BINFMT_ELF_FDPIC=y and
v5.3.18.
We can try to work around this bug in elf32_arm_nabi_grok_prstatus, but
that's out of scope for this commit, which focuses on fixing the segfault.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR corefiles/33560
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33560
gdb: include NT_I386_TLS note in generated core files
includes a pointer value in the test name. The value changes from run
to run making it harder to compare test results. Fix this by giving
the test an actual name.
There's no change to what is being tested with the commit.
Jan Beulich [Fri, 21 Nov 2025 08:05:36 +0000 (09:05 +0100)]
bfd/COFF: mark a function exposed to ld as non-private
As a non-private function, _bfd_coff_read_internal_relocs() shouldn't have
a "_bfd_" prefix, but merely a "bfd_" one. Tidy arguments passed whle at
it.
Jan Beulich [Fri, 21 Nov 2025 08:05:18 +0000 (09:05 +0100)]
bfd/PEI: mark internal functions hidden
This reduces the dynamic symbol table a bit (over a hundred symbols when
building all targets) and allows the compiler to be more aggressive about
inlining (as it sees fit, of course).
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.
projects / thirdparty / binutils-gdb.git / log
