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>
Tom de Vries [Mon, 10 Nov 2025 17:21:39 +0000 (18:21 +0100)]
[pre-commit] Set verbose=false for check-whitespace
Currently, the pre-commit check check-whitespace has verbose=true:
...
$ pre-commit run --all-files check-whitespace
check-whitespace........................................................Passed
- hook id: check-whitespace
- duration: 0.3s
$
...
That's not necessary, since:
- check-whitespace has no output if the check passes, and
- pre-commit shows the output anyway if the check fails.
Fix this by removing the verbose setting, getting us instead:
...
$ pre-commit run --all-files check-whitespace
check-whitespace........................................................Passed
$
...
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Mon, 10 Nov 2025 14:37:13 +0000 (15:37 +0100)]
[gdb/testsuite] Drop address from test name in gdb.mi/mi-memory-changed.exp
I ran the testsuite twice, once with target board unix, and once with target
board unix/-fPIE/-pie, compare the two sum files, and got for test-case
gdb.mi/mi-memory-changed.exp:
...
< PASS: $exp: set var *(unsigned int *) 0x4011b0 = 0xe5894855
---
> PASS: $exp: set var *(unsigned int *) 0x5555555551c3 = 0xe5894855
...
Fix this by dropping the concrete address from the test name:
...
PASS: $exp: set var *(unsigned int *) 0x${main_addr} = ${main_insn}
...
Tom de Vries [Mon, 10 Nov 2025 14:27:30 +0000 (15:27 +0100)]
[gdb/testsuite] Drop address from test name in gdb.arch/amd64-shadow-stack-corefile.exp
I ran the testsuite twice, compare the two sum files, and got for test-case
gdb.arch/amd64-shadow-stack-corefile.exp:
... 3077c3077
< PASS: $exp: OS corefile: pl3_ssp contents from core file 0x7f7a38
3fffe0
---
> PASS: $exp: OS corefile: pl3_ssp contents from core file 0x7f179e
...
Fix this by dropping the address from the test name.
Jan Beulich [Mon, 10 Nov 2025 10:36:25 +0000 (11:36 +0100)]
bfd/ELF: _bfd_elf_ppc_at_tls_transform() is exposed to gas
As a non-private function, it shouldn't have a "_bfd_" prefix, but merely
a "bfd_" one. Hence commit 50efe229ddf5 ("bfd/ELF: mark internal functions
hidden") also wrongly added ATTRIBUTE_HIDDEN to it.
Jan Dubiec [Fri, 7 Nov 2025 06:55:19 +0000 (07:55 +0100)]
ld: Fix a H8/300 specific test case
It seems that glob patterns no longer work in the test suite, at least
on some host/dejagnu/shell combinations. In any case it is better
here not to create a single relax-7?.o file from the two source files,
but to create two separate objects for linking.
ld/
* testsuite/ld-h8300/relax-7.d: Replace the glob pattern with
multiple "source" options.
Indu Bhagat [Sun, 9 Nov 2025 08:34:27 +0000 (00:34 -0800)]
libsframe: rename encoder to ectx for readability
Addressing (an old) review comment suggesting this housekeeping item.
Use consistent naming style in libsframe. sframe_decoder_ctx objects
are named 'dctx', so use 'ectx' for sframe_encoder_ctx objects.
Make necessary changes in all the applicable declarations and definitions.
Tom de Vries [Sun, 9 Nov 2025 08:18:43 +0000 (09:18 +0100)]
[gdb/testsuite] Fix main in gdb.trace/mi-trace-frame-collected.exp
With test-case gdb.trace/mi-trace-frame-collected.exp I run into:
...
gdb compile failed, gdb.trace/actions.c: In function 'main':
gdb.trace/actions.c:139:1: warning: old-style function definition \
[-Wold-style-definition]
139 | main (argc, argv, envp)
| ^~~~
...
Fix this by rewriting main into a prototyped function.
Indu Bhagat [Sun, 9 Nov 2025 07:33:22 +0000 (23:33 -0800)]
libsframe: fix checks in flip_fde
Adjust the sanity checks for flip_fde workflow and optional trailing
section padding to account for the case of ihp->sfh_fdeoff != 0 or
ihp->sfh_freoff != total FDEs size.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
libsframe/
* sframe.c (flip_sframe): Fix checks in flip_fde to accommodate
cases when sfh_fdeoff != 0 or when SFrame FREs are placed after
a gap from SFrame FDEs.
Tom de Vries [Sun, 9 Nov 2025 07:07:57 +0000 (08:07 +0100)]
[gdb/testsuite] Use -std=c99 in gdb.base/callfuncs.exp
In test-case gdb.base/callfuncs.exp I run into:
...
gdb compile failed, gdb.base/callfuncs.c: In function 't_func_values':
gdb.base/callfuncs.c:611:12: error: too many arguments to function \
'func_arg1'; expected 0, have 2
611 | return ((*func_arg1) (5,5) == (*func_val1) (5,5)
| ~^~~~~~~~~~~ ~
...
Fix this by using -std=c99.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/32756
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756
H.J. Lu [Thu, 6 Nov 2025 00:20:26 +0000 (08:20 +0800)]
readelf: Display the base symbol version as empty string
Update readelf to display the base symbol version as
Symbol table for image contains 5 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000003008 0 OBJECT GLOBAL DEFAULT 10 bar@@
2: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1
3: 0000000000003008 0 OBJECT GLOBAL DEFAULT 10 bar@@VERS_1
4: 0000000000003000 0 OBJECT GLOBAL DEFAULT 10 foo@
instead of
Symbol table for image contains 5 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000003008 0 OBJECT GLOBAL DEFAULT 10 bar
2: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1
3: 0000000000003008 0 OBJECT GLOBAL DEFAULT 10 bar@@VERS_1
4: 0000000000003000 0 OBJECT GLOBAL DEFAULT 10 foo
That is bar@@ and foo@ vs bar and foo.
binutils/
PR binutils/33599
* readelf.c (process_version_sections): Replace 0x8001 with
(VERSYM_HIDDEN | VERSYM_BASE).
(get_symbol_version_string): Likewise. Return "" for the base
version.
Tom Tromey [Thu, 16 Oct 2025 14:58:38 +0000 (08:58 -0600)]
Write entire buffer in gdbserver write_prim
We had a customer bug report which was eventually tracked down to
gdbserver not fully sending a target description to gdb. (This
presented as a timeout on the gdb side.)
The customer was using the WINAPI code, which does this:
In this setup, I think it's possible to have a partial write.
However, gdbserver does not account for this possibility, despite the
fact that write_prim documents this.
This patch attempts to fix the problem by always writing the full
buffer in write_prim. In this case the customer fixed their bug in a
different way, so we haven't actually tested this in the wild.
v2: Return bool from write_prim.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
Simon Marchi [Wed, 5 Nov 2025 04:18:24 +0000 (23:18 -0500)]
gdb/dwarf: pass is_debug_types to dwarf2_per_cu constructor, make field private
Make the field private to make it clear it is never meant to change.
Pass its value through the constructor, and add a getter. The only
place that passes true is the signature_type constructor.
Change-Id: Ifb76bc015bca16696fd66cdf45c048b4ba713479 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Wed, 5 Nov 2025 04:18:23 +0000 (23:18 -0500)]
gdb/dwarf: make some fields in dwarf2_per_cu private
Except for the m_length field, that is already private and has a setter,
make the fields whose values are passed through the constructor private.
The idea is that their values should be constant throughout the life of
the object. Add some getters and update the callers.
I wasn't sure if making some bitfields public and some private would
change how they are packed, so I checked with "ptype/o", it does not.
Change-Id: I7087bebf69e44d16a36c1dd4d7edf9b8bf085343 Approved-By: Tom Tromey <tom@tromey.com>
CXX elfread.o
/home/smarchi/src/binutils-gdb/gdb/elfread.c: In function ‘symfile_segment_data_up elf_symfile_segments(bfd*)’:
/home/smarchi/src/binutils-gdb/gdb/elfread.c:145:12: error: ‘is_debuginfo_file’ was not declared in this scope
145 | if (!is_debuginfo_file (abfd)
| ^~~~~~~~~~~~~~~~~
Simon Marchi [Thu, 6 Nov 2025 21:04:29 +0000 (16:04 -0500)]
gdb/testsuite: issue "no repeat" command before "no previous command to relaunch" test
I see this failure:
$ make check TESTS="gdb.base/with.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
FAIL: gdb.base/with.exp: repeat: reinvoke with no previous command to relaunch
It seems like that failure has always been there and I didn't notice?
I'm not sure what is the intent of the test exactly. It sounds like it
is meant to test what happens when you use command "with language ada"
as the very first command of a GDB session? However, clean_restart and
gdb_load issue some commands before that test. The different between
the native-extended-gdbserver board and the other boards is: for other
boards, the previous command is a "file" command, which is a "no repeat"
command, which gives the expected error message. With the
native-extended-gdbserver board, the previous command is "set remote
exec-file", which is a repeatable command.
"Fix" it by making a "no repeat" command just before the test, so that
it works the same regardless of the target board.
Change-Id: I254faf196f49e9efd492fc9dd5f6ce7b96f72af7 Approved-By: Tom Tromey <tom@tromey.com>
Jens Remus [Fri, 7 Nov 2025 16:09:55 +0000 (17:09 +0100)]
s390: Bind defined symbol locally in PIE
Symbols defined in PIE should be bound locally, the same as -shared
-Bsymbolic.
Port x86 commit 4e0c91e45402 ("Bind defined symbol locally in PIE")
change of relocate_section as well as linker tests to s390. Similar as
done for other architectures with the following commits:
- AArch64: ac33b731d214 ("[AArch64] Bind defined symbol locally in PIE")
- ARM: 1dcb9720d62c ("[ARM] Bind defined symbol locally in PIE")
- RISC-V: 39c7793ba8be ("RISC-V: Bind defined symbol locally in PIE")
- x86: 4e0c91e45402 ("Bind defined symbol locally in PIE")
With this change symbols defined in an executable (i.e. PDE or PIE) are
bound locally, as they cannot be interposed. In the same way as symbols
defined in a shared library linked with -Bsymbolic are bound locally.
This also ensures that all defined symbols are bound locally in
static PIE.
Do not port the x86 change of check_relocs (now scan_relocs). None of
the linker tests where the change in condition triggers (e.g. bootstrap,
cdtest) produce different readelf -Wa output. The change appears to
affect accounting of space required for dynamic relocations. Instead of
accounting them in check_relocs and later filtering them away in
allocate_dynrelocs, they would not get accounted in the first place:
The change in the expression would only have an effect if the following
conditions are all met in addition to PIE: ALLOC, PC-relative
relocation, global symbol, not defined weak, and defined regular. In
this specific case the accounting of the PC relative relocation in
h->dyn_relocs would be skipped for PIE. But allocate_dynrelocs later
eliminates any PC-relative dynamic relocations if PIC (= PIE or shared
library) and SYMBOL_CALLS_LOCAL.
bfd/
PR ld/33141
* elf64-s390.c (elf_s390_relocate_section): Bind defined symbol
locally in PIE.
Jan Beulich [Fri, 7 Nov 2025 14:00:51 +0000 (15:00 +0100)]
bfd/ELF: _bfd_elf_link_create_dynamic_sections() is exposed to ld
As a non-private function, it shouldn't have "_bfd_" prefixes, but merely
a "bfd_" one. Even if, sadly, it needs exposing just for the sake for
VxWorks.
Jan Beulich [Fri, 7 Nov 2025 13:59:45 +0000 (14:59 +0100)]
bfd/ELF: _bfd_elf_large_com_section is exposed to gas and x86-only
As a non-private data item, it shouldn't have a "_bfd_" prefix, but merely
a "bfd_" one. Furthermore, as being x86-only (forever since its
introduction), it doesn't need to be present in libbfd.{a,so} at all for
other targets.
Jan Beulich [Fri, 7 Nov 2025 13:43:47 +0000 (14:43 +0100)]
bfd/ELF: mark internal functions hidden
This reduces the dynamic symbol table quite a bit (almost 200 symbols) and
allows the compiler to be more aggressive about inlining (as it sees fit,
of course).
Jan Beulich [Fri, 7 Nov 2025 07:09:58 +0000 (08:09 +0100)]
x86: support SALC
Now that the SDM (finally) at least mentions it (without giving it a
proper instruction page, though), let's (again: finally) also support it
in assembler and disassembler.
Tom Tromey [Sun, 19 Oct 2025 19:06:40 +0000 (13:06 -0600)]
Fix use of "main" in gdb_index with C++
In commit f283e80f (Fix use of "main" marker in gdb index), I changed
the DWARF reader to understand that the C language's "main" might
appear in the .gdb_index, and should not be ignored.
This week I realized that this same problem can affect C++ as well.
I'm not sure why I didn't consider this at the time.
This patch fixes the bug. It's somewhat of a hack, I guess, but also
at least understandable.
Simon Marchi [Thu, 6 Nov 2025 21:13:07 +0000 (16:13 -0500)]
gdb/testsuite: adjust add-inferior test for native-extended-gdbserver board
I see this failure:
$ make check TESTS="gdb.base/with.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
FAIL: gdb.base/with.exp: per-inferior parameters: add-inferior
The add-inferior command produces more output than expected when using
the native-extended-gdbserver board, because it is already connected to
a remote target:
Rainer Orth [Thu, 6 Nov 2025 16:18:16 +0000 (17:18 +0100)]
gas: Default to -mrelax-relocations=no on Solaris/x86 [PR19520]
I recently noticed a complex case statement in gas/configure.ac controlling
the setting of ac_default_x86_relax_relocations on Solaris/x86. Since it
included all versions of Solaris, it could be massively simplified.
Looking closer however, I found that it was introduced in
based on PR gas/19520. This PR reported that the new R_386_GOT32X
etc. relocations weren't supported on older versions of Solaris,
breaking gcc bootstrap. In response, they were disabled on all Solaris
versions except Solaris 12, where they had been implemented in the
native toolchain based on my findings.
However, Solaris 12 has been rechristened to 11.4 before release,
effectively disabling DEFAULT_GENERATE_X86_RELAX_RELOCATIONS on all
versions of Solaris/x86.
Since Solaris 11.4 cannot be distinguished from earlier versions in
cross configurations, this patch fixes this by removing
--enable-x86-relax-relocations completely, instead disabling
DEFAULT_GENERATE_X86_RELAX_RELOCATIONS in tc-i386.c on Solaris. It also
adds testcases to verify the -mrelax-relocations default.
Tested on {i386,amd64}-pc-solaris2.11 and {i686,x86_64}-pc-linux-gnu.
Tom Tromey [Thu, 6 Nov 2025 15:33:08 +0000 (08:33 -0700)]
Fix build after command_classes change
Commit 7028626eff3 (gdb: make command classes be bitmaps) broke the
build, causing the compiler to issue an error message about the global
scm-cmd.c:command_classes being redefined as a different type.
Renaming the global fix the problem.
Andrew Burgess [Tue, 4 Nov 2025 09:59:09 +0000 (09:59 +0000)]
gdb/python: fix gdb.Block repr output
I noticed that when printing a gdb.Block object in Python, I would
occasionally get corrupted, nonsensical output, like this:
<gdb.Block <anonymous> {intintyinty_1inty_3inty_5... (-5 more symbols)}>
The symbol list is missing commas, it should be:
int, inty, inty_1, inty_3, inty_5, ...
And the '-5 more symbols' is clearly not right.
The problem is in python/py-block.c, we use this line to calculate the
number of symbols in a block:
const int len = mdict_size (block->multidict ());
Then we loop over the symbols in the block like this:
for (struct symbol *symbol : block_iterator_range (block))
...
The problem here is that 'block_iterator_range (block)' can loop over
more symbols than just those within 'block'. For global and static
blocks, block_iterator_range() takes into account included CUs; and so
can step through multiple global or static blocks. See
block_iterator_step and find_iterator_compunit_symtab in block.c for
more details.
In contrast, 'mdict_size (block->multidict ())' only counts the
symbols contained within 'block' itself.
I could fix this by either fixing LEN, or by only iterating over the
symbols within 'block'.
I assume that printing a gdb.Block object is used mostly for debug
purposes; the output isn't really user friendly, so I cannot imagine a
user script that is relying on printing a gdb.Block as a way to inform
the user about blocks in their program. As such, I think it makes
more sense if the symbols listed are restricted to those strictly held
within the block.
And so, instead of block_iterator_range, I've switched to iterating
over the multidict symbols. Now the calculated LEN will match the
number of symbols being printed, which fixes the output seen above.
However, as we're now only printing symbols that are within the block
being examined, the output above becomes:
<gdb.Block <anonymous> {}>
All the symbols that GDB previously tried to print, are coming from an
included CU.
For testing, I've made use of an existing DWARF test that tests
DW_AT_import. In the wild I saw this in an inferior that used
multiple shared libraries that has their debug information stored in a
separate debug file, and then parts of that debug information was
combined into a third separate file using the DWZ tool. I made a few
attempts to craft a simpler reproducer, but failed. In the end it was
easier to just use a DWARF assembler test to reproduce the issue.
I have added some more typedef symbols into the DWARF test, I don't
believe that this will impact the existing test, but makes the
corrupted output more obvious.
Tom de Vries [Thu, 6 Nov 2025 09:39:33 +0000 (10:39 +0100)]
[gdb/testsuite] Fix DUPLICATE in callfuncs.exp
With test-case gdb.base/callfuncs.exp I get:
...
UNTESTED: gdb.base/callfuncs.exp: failed to prepare
...
UNTESTED: gdb.base/callfuncs.exp: failed to prepare
DUPLICATE: gdb.base/callfuncs.exp: failed to prepare
...
Fix this by moving a with_test_prefix up one level.
RISC-V: Fix missing instruction classes in error messages
Add 6 missing instruction class cases to riscv_multi_subset_supports_ext()
to provide proper extension names in error messages instead of producing
"internal: unreachable INSN_CLASS_*" errors.
These instruction classes exist in riscv_multi_subset_supports() but were
missing from riscv_multi_subset_supports_ext(), causing the assembler to
produce internal errors when instructions are used without the required
-march specification.
Currently, there is no way for a new user to have an idea of common
useful commands and behaviors from the GDB interface itself, without
checking the example session in the documentation. This command class
aims to close that gap by providing a set of quickstart commands that
allows for any simple debug session to happen without anything too
egregious missing.
The set of commands was chosen somewhat arbitrarily, based on what I
used or missed the most. The one overarching important thing, however,
is that the list is kept short, so as to not overwhelm new users. This
is confirmed by the newly introduced selftest, essential_command_count,
which ensures there are 20 or fewer essential commands.
Here's the reasoning for some of the choices:
* The command "start" was picked over "run" because combining it with
"continue" achieves the same effect, and I prefer it over needing to set
a breakpoint on main to stop at the start of the inferior.
* The command "ptype" is chosen because I believe it is important to
provide a way for the user to check a variable's type from inside GDB,
and ptype is a more complete command than the alternative, "whatis".
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
This commit makes it so GDB's command classes can be represented with a
single bit, allowing for a command to have multiple classes. This is
primarily done as preparation for the next patch, but it can provide
value on its own as some commands could be described as belonging to
multiple classes, such as "record" being obscure and related to running
the inferior.
BFD: Remove unused file position member of `struct orl'
The `pos' member of `struct orl' has never been used. Remove it along
with the enclosing union so as not to propagate clutter with a later
change, which adds that union as a distinct type. No functional change.
Tom de Vries [Wed, 5 Nov 2025 15:16:01 +0000 (16:16 +0100)]
[gdb/testsuite] Yet another attempt to fix gdb.threads/thread-specific-bp.exp
When running test-case gdb.threads/thread-specific-bp.exp using taskset to
select an Efficient-core in a loop, it fails 19 out of 100 runs.
For example, like this:
...
(gdb) continue -a^M
Continuing.^M
^M
Thread 1 "thread-specific" hit Breakpoint 4, end () at thread-specific-bp.c:29^M
29 }^M
(gdb) FAIL: $exp: non_stop=on: continue to end
[Thread 0x7ffff7cbe6c0 (LWP 2348848) exited]^M
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
...
The way we're trying to match this gdb output is:
...
gdb_test_multiple "$cmd" "continue to end" {
-re "$\r\n${gdb_prompt} .*${msg_re}\r\n" {
pass $gdb_test_name
}
-re "\r\n${msg_re}\r\n.*$gdb_prompt " {
pass $gdb_test_name
}
}
...
The problem is that the two -re clauses above do not match the output ending
in a prompt, so the default fail in gdb_test_multiple triggers.
Fix this by splitting this up in two gdb_test_multiple calls:
- the first matches a prompt (with or without preceding $msg_re), making sure
that the default fail doesn't trigger, and
- the second matches $msg_re, if that was not already matched by the first call.
Using this approach, the test-case passes 100 out of 100 runs.
Tested on x86_64-linux, also with make-check-all.sh.
Tom de Vries [Wed, 5 Nov 2025 15:07:54 +0000 (16:07 +0100)]
[gdb/testsuite] Remove gdb.dwarf2/dw2-ranges.exp
On openSUSE Leap 15.6 x86_64 with test-case gdb.dwarf2/dw2-ranges.exp I ran
into:
...
(gdb) file dw2-ranges^M
Reading symbols from dw2-ranges...^M
warning: stabs debug information is not supported.^M
(gdb)
...
The test-case checks a combination of dwarf and stabs.
Now that stabs is no longer supported, checking the combination is no longer possible.
Indu Bhagat [Wed, 5 Nov 2025 06:59:11 +0000 (22:59 -0800)]
gas: sframe: fix PR gas/33277
In SFrame stack trace format, the representation of stack offsets allows
for either 1-byte, 2-byte or 4-byte integers.
Add new internal function sframe_fre_stack_offset_bound_p () which
checks if the given offset is within bounds (at most as a 4-byte
integer). Use this to check if CFA offset is within bounds, if not skip
emitting the FDE, and warn the user.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
gas/
PR gas/33277
* gen-sframe.c (sframe_fre_stack_offset_bound_p): New
definition.
(sframe_xlate_do_def_cfa): Check bounds of offset.
(sframe_xlate_do_def_cfa_offset): Likewise.
hppa64: Fix some issues handling dynamic relocaltions
This change fixes the allocation logic in allocate_dynrel_entries and
elf64_hppa_finalize_dynreloc. It also fixes addend calculation for
segment based relocations.
Some applications now link successfully on HP-UX but there are still
issues with external weak symbols. This breaks linking with libgcc.
It looks like we need support for .rela.data.rel.ro, ...
2025-11-04 John David Anglin <danglin@gcc.gnu.org>
bfd/ChangeLog:
* elf64-hppa.c (allocate_dynrel_entries): Correct hh->want_opd
if condition.
(elf64_hppa_finalize_dynreloc): Likewise. Use symbol address
instead of OPD address. Include sec->output_offset in value2
calculation.
(elf64_hppa_finalize_opd): Likewise.
(elf64_hppa_finalize_dlt): Likewise.
(elf_hppa_final_link_relocate): Fix symbol address calculation.
Jens Remus [Tue, 4 Nov 2025 10:51:07 +0000 (11:51 +0100)]
s390: Emit relocation for 32-bit immediate operand
IBM Z instruction format RIL-a has a 32-bit immediate operand in
instruction bits 16 to 47. Enable the assembler to emit a 32-bit
direct or PC-relative relocation when processing a fixup, similar
as it is already done for 16-bit immediate operands in bits 16-31.
projects / thirdparty / binutils-gdb.git / log
