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>
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.
projects / thirdparty / binutils-gdb.git / log
