Alan Modra [Sat, 3 Jan 2026 03:12:30 +0000 (13:42 +1030)]
ld/deffilep.y tidies
Formatting. Replace "sizeof (type)" with "sizeof (*varp)" where that
makes sense. Use xcalloc in place of xmalloc+memset. Don't special
case xrealloc of NULL pointer, xrealloc handles that fine.
Tom de Vries [Sat, 3 Jan 2026 15:10:41 +0000 (16:10 +0100)]
[gdb/testsuite] Fix gdb.base/local-env.exp on remote host
With host/target board local-remote-host-native.exp and other remote host
configurations, and test-case gdb.base/local-env.exp I get:
...
(gdb) show environment^M
...
(gdb) FAIL: $exp: show environment displayed variable
...
The test attempt to detect variable GDB_TEST_ENV_VAR in the environment, which
has been set with setenv.
This doesn't work with remote host, so declare the test unsupported. Likewise
in gdb.base/environ.exp.
Tom de Vries [Sat, 3 Jan 2026 15:06:29 +0000 (16:06 +0100)]
[gdb/testsuite] Fix gdb.base/gdb11531.exp with m32 PIE
With test-case gdb.base/gdb11531.exp and target board unix/-m32/-fPIE/-pie I get:
...
(gdb) next^M
34 myrec.x = 5;^M
(gdb) FAIL: gdb.base/gdb11531.exp: watchpoint variable triggers at next
...
For contrast, with target board unix/-m32 I get instead:
...
(gdb) next^M
^M
Hardware watchpoint 2: myrec.x^M
^M
Old value = 0^M
New value = 5^M
main () at /data/vries/gdb/src/gdb/testsuite/gdb.base/gdb11531.c:35^M
35 myrec.y = 3.4;^M
(gdb) PASS: gdb.base/gdb11531.exp: watchpoint variable triggers at next
...
The problem is that the runto_main doesn't set a breakpoint on the same line
in both cases.
Fix this by using runto "$srcfile:34".
[ The underlying problem here is the failure of prologue analysis to deal with
get_pc_thunk. But since there's a PR [1] open about this, and the problem is
unrelated to the test-case, we work around it. ]
Tom de Vries [Sat, 3 Jan 2026 15:04:41 +0000 (16:04 +0100)]
[pre-commit] Move codespell-log back to commit-msg stage
Commit 7acd390ffd9 ("[pre-commit] Move codespell-log to post-commit") moved
the codespell-log hook from the commit-msg to the post-commit stage.
This was deemed to make git rebase too slow [1], so move it back to the
commit-msg stage. Don't do this using a full revert, to keep unrelated
improvements from that commit.
Since we use codespell-log to produce warnings rather than errors, running the
hook at the commit-msg stage requires us to ignore codespell exit status, and
set verbose=true.
Tom de Vries [Sat, 3 Jan 2026 15:01:25 +0000 (16:01 +0100)]
[gdb/testsuite] Fix another timeout in gdb.mi/mi-multi-commands.exp
On aarch64-linux, with a gdb version 16.3 based package, I ran into (edited
for readability):
...
(gdb)
<LOTS-OF-SPACES>-data-evaluate-expression $a
^done,value="\"FIRST COMMAND\""
(gdb) -data-evaluate-expression $b
^done,value="\"TEST COMPLETE\""
(gdb)
PASS: $exp: look for first command output, command length $n
FAIL: $exp: look for second command output, command length $n (timeout)
...
For contrast, a passing example looks like:
...
(gdb)
<LOTS-OF-SPACES>-data-evaluate-expression $a
-data-evaluate-expression $b
^done,value="\"FIRST COMMAND\""
(gdb)
PASS: $exp: look for first command output, command length $n
^done,value="\"TEST COMPLETE\""
(gdb)
PASS: $exp: look for second command output, command length $n
...
The setup is that the test-case issues these two commands at once:
...
-data-evaluate-expression $a
-data-evaluate-expression $b
...
where the length of the first command is artificially increased by prefixing
it with spaces, shown as <LOTS-OF-SPACES> above.
What happens is that gdb, after parsing the first command, executes it, which
generates output and a prompt. Then that prompt intermixes with the echoing
of the second command, and consequently the matching of the prompt fails.
This is very similar to what was fixed in commit 59c9bc5fb6c ("[gdb/testsuite]
Fix timeout in gdb.mi/mi-multi-commands.exp").
Fix this by making the matching of the first prompt optional.
While we're at it, make the test-case more readable using {}, string_to_regexp
and multi_line_input.
Alan Modra [Thu, 1 Jan 2026 21:52:02 +0000 (08:22 +1030)]
Solaris .strtab and .shstrtab flags
These sections have SHF_STRINGS in sh_flags on Solaris. Commit 84865015459b in part implemented this variation by an elf_backend_data
field used to set the flags, but that only works of course if one of
the solaris targets is used. Which in some ways is fair enough. If
you want solaris support then it is reasonable to require the solaris
targets to be compiled in. However if they are not the default, other
ELF targets may be used even when the solaris targets are compiled in,
because many ELF targets allow any ELFOSABI object to match. (Which
is arguably a bug.)
So instead of the current scheme this patch implements the solaris
specific sh_flags in _bfd_elf_final_write_processing. That way either
a solaris target being used, or ELFOSABI_SOLARIS in the object will
get the correct sh_flags.
Alan Modra [Thu, 1 Jan 2026 21:51:31 +0000 (08:21 +1030)]
gas .xstabs missing string results in a segfault
Found by oss-fuzz.
* stabs.c (s_xstab): Check result of demand_copy_C_string.
(s_stab_generic): Remove duplicate warning and ignore_r_o_l
after demand_copy_C_string error.
Alan Modra [Thu, 1 Jan 2026 21:51:16 +0000 (08:21 +1030)]
ld config targ_extra_emuls and targ_extra_libpath
There is no need to duplicate targets in these variables, one or the
other is sufficient. This patch removes such duplication but
otherwise makes no user visible changes. Quite likely some targets
ought to be in targ_extra_emuls rather than targ_extra_libpath.
* configure.tgt: Don't duplicate targ_extra_libpath targets
in targ_extra_emuls, and similarly for targ64 variants.
Alan Modra [Thu, 1 Jan 2026 12:25:19 +0000 (22:55 +1030)]
Update year range in copyright notice of binutils files
Avoid warnings about invalid escapes in etc/update-copyright.py by
using raw strings, add BinutilsFilter to skip psql.rc and add
"Kalray SA." as another copyright holder.
Alice Carlotti [Sat, 27 Dec 2025 18:26:26 +0000 (18:26 +0000)]
aarch64: Remove a space from movaz za operand
The za operands of most movaz instructions were originally printed with
an extra space compared to other za operands. Remove this space, and
reduce code duplication in the process.
Alice Carlotti [Sat, 27 Dec 2025 20:46:25 +0000 (20:46 +0000)]
aarch64: Accept .b/.h/.s in movaz (array to vector)
While the .d form is preferred for disassembly, assemblers should accept
any element size that is used consistently. The sme2_mov class handles
this already for mov instructions, so use that here as well.
Alice Carlotti [Sat, 27 Dec 2025 14:43:40 +0000 (14:43 +0000)]
aarch64: Fix luti2/luti4 decode mask
Neither the opcode mask nor the size determination were checking bit 13,
so some undefined opcodes were being incorrectly disassembled as valid
luti2/luti4 instructions.
Rainer Orth [Mon, 29 Dec 2025 10:16:04 +0000 (11:16 +0100)]
bfd: Re-enable 64-bit support for 32-bit Solaris targets
One of the recent Solaris patches removed want64=true from the 32-bit
Solaris targets. This breaks GCC bootstrap: unlike Linux, GCC on
Solaris is always biarch, both in 32-bit-default and 64-bit-default
configurations, so the 64-bit multilib fails to build.
This patch undoes this incompatible change.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11.
Sivan Shani [Wed, 17 Dec 2025 16:58:52 +0000 (16:58 +0000)]
AArch64: Add FEAT_F16F32MM
This patch includes:
- The feature flag for the FEAT_F16F32MM feature.
- Instruction FMMLA Half-precision matrix multiply-accumulate to single-precision.
Sivan Shani [Wed, 17 Dec 2025 16:36:54 +0000 (16:36 +0000)]
AArch64: Add FEAT_F16F32DOT instructions
This includes the instructions for the F16F32DOT feature:
- FDOT half-precision to single-precision, by element
- FDOT half-precision to single-precision, vector
In addition, new operands:
- OPND_SME_Zmx2_INDEX_22: an operand represents a list of vector registers with an index.
- OPND_SME_Zn7xN_UNTYPED: an operand represents an untyped list of vector registers.
Alan Modra [Fri, 26 Dec 2025 00:26:15 +0000 (10:56 +1030)]
Re: bfd ASSOCIATED_VECS
What I committed in f4e835a40c wasn't wrong but it wasn't elegant.
Unlike looking for a word separated by spaces, it isn't necessary
to prepend and append the separators in the match string.
Alan Modra [Thu, 25 Dec 2025 11:47:10 +0000 (22:17 +1030)]
PR 33726, symbols in excluded sections
This improves "nearby" section choice when memory regions are active,
preferring a section in the same region as the excluded section over
other sections.
The problem lies in existence of "freestanding" code, a code that is
part of a CU but does not have any block associated with it. Consider
following program:
int main(int argc, char **argv) {
return foo(argc);
}
When compiled, the foo function has no block of itself:
Blockvector:
no map
block #000, object at 0x55978957b510, 1 symbols in 0x1129..0x1148
int main(int, char **); block object 0x55978957b380, 0x112d..0x1148 section .text
block #001, object at 0x55978957b470 under 0x55978957b510, 2 symbols in 0x1129..0x1148
typedef int int;
typedef char char;
block #002, object at 0x55978957b380 under 0x55978957b470, 2 symbols in 0x112d..0x1148, function main
int argc; computed at runtime
char **argv; computed at runtime
In this case lookup(0x1129) returns static block and, because of the
change in cc1fc6af4, contains(0x1129) which is wrong.
Such "freestanding" code is perhaps not common but it does exist,
especially in system code. In fact the regressions were at least in part
caused by such "freestanding" code in glibc (libc_sigaction.c).
The whole idea of commit cc1fc6af4 was to handle "holes" in CUs, a case
where one CU spans over multiple disjoint regions, possibly interleaved
with other CUs. Consider somewhat extreme case with two CUs:
This when compiled with a carefully crafted linker script to force code
at certain positions, creates following layout:
0x080000..0x080007 # "freestanding" bar from hole-2.c
0x080008..0x080016 # give_me_zero() from hole-2.c
0x080109..0x080114 # main from hole-1.c
0xf00000..0xf0000b # baz() from hole-2.c
0xf0000b..0xf00011 # "freestanding" foo from hole-2.
0xf0000b..0xf0001c # gice_me_one() from hole-2.
The block vector for hole-1.c looks:
Blockvector:
no map
block #000, object at 0x555a5d85fb90, 1 symbols in 0x80109..0x80114
int main(void); block object 0x555a5d85faa0, 0x80109..0x80114 section .text
block #001, object at 0x555a5d85faf0 under 0x555a5d85fb90, 1 symbols in 0x80109..0x80114
typedef int int;
block #002, object at 0x555a5d85faa0 under 0x555a5d85faf0, 0 symbols in 0x80109..0x80114, function main
block #000, object at 0x555a5d8603b0, 3 symbols in 0x80008..0xf0001d
int give_me_zero(void); block object 0x555a5d85ff50, 0x80008..0x80016 section .text
int give_me_one(void); block object 0x555a5d860110, 0xf00012..0xf0001d section .text
int baz(void); block object 0x555a5d860280, 0xf00000..0xf0000b section .text
block #001, object at 0x555a5d8602d0 under 0x555a5d8603b0, 1 symbols in 0x80008..0xf0001d
typedef int int;
block #002, object at 0x555a5d85ff50 under 0x555a5d8602d0, 0 symbols in 0x80008..0x80016, function give_me_zero
block #003, object at 0x555a5d860280 under 0x555a5d8602d0, 0 symbols in 0xf00000..0xf0000b, function baz
block #004, object at 0x555a5d860110 under 0x555a5d8602d0, 0 symbols in 0xf00012..0xf0001d, function give_me_one
Note that despite the fact "freestanding" bar belongs to hole-2.c, the
corresponding CU's global and static blocks start at 0x80008! Looking
at DWARF for the second program, it looks like that the compiler (GCC 15)
did not record the presence of "freestanding" code:
Thiago suggested to use minsymbols to tell whether or a CU contains
given address. I do not think this would work reliably as minsymbols do
no know to which CU they belong. In slightly more complicated case of
interleaved CUs it does not seem to be possible to tell for sure to which
one a given minsymbol belongs.
Moreover, Tom suggested that the comment in find_compunit_symtab_for_pc_sect
(which led to cc1fc6af4) may be outdated [2].
Indu Bhagat [Wed, 24 Dec 2025 08:59:07 +0000 (00:59 -0800)]
libsframe: refactor out sframe_fre_grow_tbl
Usage of a global int number_of_entries is likely unnecessary. The same
global is used for growing the FDE tbl too, when adding FDEs. At the
moment, however, carve out a new function to grow the FRE table, and
use a macro instead of 'number_of_entries'.
This refactoring helps provide basis for a later patch where we add
SFrame FREs in bulk instead of one at a time to the SFrame encoder
object.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
libsframe/
* sframe.c (SFRAME_FRE_ALLOC_LEN): New definition.
(sframe_grow_fre_tbl): New definition.
(sframe_encoder_add_fre): Use the new function.
Indu Bhagat [Wed, 24 Dec 2025 08:51:43 +0000 (00:51 -0800)]
libsframe: refactor sframe_decoder_add_funcdesc for internal use
sframe_encoder_add_funcdesc () was added for SFRAME_VERSION_1. This has
since been obsoleted by introduction of SFRAME_VERSION_2 and its
corresponding sframe_decoder_add_funcdesc_v2 API.
Refactor the functionality into an internal-only API:
sframe_encoder_add_funcdesc_internal (). Ensure it returns the error
code for the caller to take necessary action or pass to user.
Keep only two args for sframe_encoder_add_funcdesc: function size and
function start addr. This simple barebone API will be used in a
subsequent commit to adjust the link-time behaviour of SFrame sections.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
include/
* sframe-api.h (sframe_encoder_add_funcdesc): Remove args to
create the barebone API.
libsframe/
* sframe.c (sframe_encoder_add_funcdesc): Refactor out into
sframe_encoder_add_funcdesc_internal. Change args.
(sframe_encoder_add_funcdesc_v2): Use the new internal API.
* libsframe.ver: Move sframe_encoder_add_funcdesc to 2.1 node.
Indu Bhagat [Wed, 24 Dec 2025 08:44:37 +0000 (00:44 -0800)]
gas: sframe: refactor out the offsets emission code
Minor refactoring. Carve out the SFrame FRE offsets emission code into
a new output_sframe_row_entry_offsets (). This change helps prepare for
later supporting a new FDE type in SFrame V3.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
gas/
* gen-sframe.c (output_sframe_row_entry_offsets): New
definition.
(output_sframe_row_entry): Use the new definition.
Indu Bhagat [Wed, 24 Dec 2025 08:41:18 +0000 (00:41 -0800)]
include: sframe: add SFRAME_V2_ prefixed macro names for FDE
Such a change for readability only. SFrame V1 is now obsolete, and with
newer versions like V3 or later, its likely better to have macro names
reflect the applicable version.
Add new macro names for FDE information related macros.
Indu Bhagat [Wed, 24 Dec 2025 08:41:02 +0000 (00:41 -0800)]
libsframe: implement an internal-only SFrame FDE representation
Up until now, libsframe has used the same SFrame FDE representation as
the on-disk representation (sframe_func_desc_entry). The choice made by
the author of the library, back when it was first contributed, perhaps
sufficed the needs then. But looking forward, we need to be able to
allow reading and dumping out of not just sections with version
SFRAME_VERSION_2 but also future supported versions.
Note that libsframe did not (and still does not) expose the SFrame FDE
representation in any public APIs; doing so is not recommended.
For the path forward, create an internal-only SFrame FDE representation
(sframe_func_desc_entry_int). libsframe now keeps all in-memory FDEs of
type sframe_func_desc_entry_int. Doing so means instead of memcpy, we
need to resort to member-by-member mapping. This can be seen in
sframe_fde_tbl_init (read time) and the new function
sframe_encoder_write_fde (write time).
Other than that, replace out the previous direct interaction with
on-disk format when:
- flipping SFrame contents before decoding them in sframe_decode.
- flipping SFrame contents before writing them out in sframe_encode.
Indu Bhagat [Tue, 23 Dec 2025 22:59:59 +0000 (14:59 -0800)]
include: gas: bfd: sframe: clean the abstraction
... between specification and implmentation.
Move to definition in the implementation (gas/ld/libsframe) and not the
specification (include/sframe.h). At this time the implementation in
gas and ld generate the sections in the latest SFrame version only.
Indu Bhagat [Tue, 23 Dec 2025 22:59:09 +0000 (14:59 -0800)]
gas: sframe: ignore .cfi_offset for RA selectively
For ABIs not tracking RA (e.g., AMD64), the return address is expected
to be in a specific location (usually a fixed offset from CFA on stack).
Explicit manourvering to a different offset may be non-representable in
SFrame, and should not be simply ignored.
Although such patterns are not usually seen in the wild, it is more
correct to catch them if at all they manifest.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
gas/
* gen-sframe.c (sframe_xlate_do_offset): Do not ignore
.cfi_offset for RA all the time.
gas: Don't skip SFrame FDE if .cfi_register specifies RA w/o tracking
Do not skip SFrame FDE if .cfi_register specifies RA register without
RA tracking being actually used. Without RA tracking the register
contents can always be restored from the stack using the fixed
RA offset from CFA.
Even for ABI/arch without RA tracking, there may be instances where user
may specify '.cfi_register RA, reg'. This needs to be caught, skipping
this from SFrame generation may not be correct. This may be done in
certain hand-written asm sequences where the user needs to manipulate
the return to a certain function.
No testcase is being added ATM because in SFrame V3, a new FDE type can
be used to represent such cases (A new test case will be added then).
Matthieu Longo [Mon, 22 Dec 2025 15:50:02 +0000 (15:50 +0000)]
gas: add as_info() for informational diagnostics
This patch adds as_info(), a shortened version of as_info_where(),
for emitting informational diagnostics from Gas.
This new helper provides the same formatting and source location
handling as as_info_where(), while offering a simpler interface
for the common case. It respects the --no-info flag, and supports
indentation in the same way as its sibling.
Andrew Burgess [Wed, 15 Nov 2023 16:36:09 +0000 (16:36 +0000)]
gdb: allow 'set args' and run commands to contain newlines
When starting GDB it is possible to set an inferior argument that
contains a newline, for example:
shell> gdb --args my.app "abc
> def"
...
(gdb) show args
Argument list to give program being debugged when it is started is "abc'
'def".
However, once GDB is started, the only way to install an argument
containing a newline is to use the Python API.
This commit changes that.
After this commit 'set args' as well as 'run', 'start', and 'starti',
will now accept multi-line inferior arguments, e.g.:
(gdb) set args "abc
> def"
(gdb) show args
Argument list to give program being debugged when it is started is ""abc
def"".
And also:
(gdb) run "abc
> def"
... etc ...
Once GDB has presented the secondary prompt to gather the remaining
inferior arguments then it is possible for the user to quit argument
entry by sending SIGINT (usually, Ctrl-c), or sending EOF (usually,
Ctrl-d). For the 'set args' case this will abort the argument change,
leaving the arguments as they were previously. For the run style
commands, this aborts the run command completely, the inferior is not
changed, and the partially collected arguments are not installed.
On Unix hosts, arguments can be wrapped with either single or double
quotes, while on MS-Windows hosts, arguments can only be wrapped with
double quotes. This gives the expected behaviour when native
debugging, but isn't entirely accurate. If a user is cross debugging
between Unix and MS-Windows then the host machine will determine which
set of quotes is valid, which will then be incorrect for the actual
target machine. This should probably be fixed in the future, but
isn't something I plan to fix immediately. If this patch is accepted,
then I can create a bug to track this issue.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Tested-By: Guinevere Larsen <guinevere@redhat.com>
Matthieu Longo [Mon, 22 Dec 2025 14:25:35 +0000 (14:25 +0000)]
loongarch: add back support for object attributes v1
A previous commit [1] mistakenly removed support for Object Attributes
for LoongArch targets.
This patch adds back the OA feature into Gas for the LoongArch targets
following the new approach which consists in:
- defining TC_OBJ_ATTR to 1 in tc-loongarch.h
- enabling the compilation of obj-elf-attr.c in gas/configure.ac
Tom Tromey [Fri, 5 Dec 2025 21:09:42 +0000 (14:09 -0700)]
Use gdb_bfd_sections in more places
I found a few spots still iterating over sections using "->next", and
thought it would be a little cleaner to use gdb_bfd_sections instead.
In one spot the loop indentation turned out to be wrong as well.
Tom Tromey [Sun, 21 Dec 2025 19:10:36 +0000 (12:10 -0700)]
Remove rust_parser::get_string
Now that struct stoken has been replaced with string_view,
rust_parser::get_string doesn't provide much value. In some places it
can even be replaced with a direct use of the string_view.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Fri, 19 Dec 2025 14:33:30 +0000 (07:33 -0700)]
Don't use stoken in rust-parse.c
I wanted to change rust-parse.c to use string_view and not stoken.
This was simple enough, but it seemed good to also change
parser_state::push_dollar to use string_view; and as it turned out,
this simplified the code a little.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Fri, 19 Dec 2025 14:40:05 +0000 (07:40 -0700)]
Use string_view in user_reg_map_name_to_regnum
This changes user_reg_map_name_to_regnum to use std::string_view.
This pointed out some dead code in that function: the "len < 0" test
in the loop can never be true, because earlier code changes 'len' in
this case.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Mon, 22 Dec 2025 17:55:07 +0000 (10:55 -0700)]
Fix --help output
In commit 9e69a2e127940cc5, which introduced "command" styling, I
accidentally made gdb's --help output mention the "stream" command,
rather than the "help" command.
While doing this I also found a spot where --help output was
incorrectly formatted. This patch fixes this as well.
I'm going to backport this to the gdb-17 branch as well.
Guinevere Larsen [Thu, 23 Oct 2025 19:29:13 +0000 (16:29 -0300)]
gdb/reverse: force direction to forward when stopping record
If a user had set the execution direction to reverse, and then they use
the command "record stop", the execution direction will be cached as
reversed, which will affect some warning messages, and can confuse
users.
This commit fixes this by forcing the execution direction to "forward"
when the command "record stop" is executed.
Hannes Domani [Mon, 22 Dec 2025 11:26:51 +0000 (12:26 +0100)]
Fix crash when breakpoint condition causes inferior exit
When using a breakpoint condition that causes an inferior exit, gdb
crashes with a null pointer access:
(gdb) b main if callexit()
Breakpoint 1 at 0x114b: file callexit.c, line 32.
(gdb) r
Starting program: /home/src/lappy/binutils-gdb.git/gdb/testsuite/gdb.base/callexit
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
[Inferior 1 (process 218586) exited normally]
../../gdb/infcall.c:895:50: runtime error: member call on null pointer of type 'struct thread_fsm'
../../gdb/infcall.c:895:50: runtime error: member access within null pointer of type 'struct thread_fsm'
Fix this by checking the thread_fsm pointer beforehand, now the result
looks like this:
(gdb) b main if callexit()
Breakpoint 1 at 0x114b: file callexit.c, line 32.
(gdb) r
Starting program: /home/src/lappy/binutils-gdb.git/gdb/testsuite/gdb.base/callexit
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
[Inferior 1 (process 220707) exited normally]
❌ Error in testing condition for breakpoint 1:
The program being debugged exited while in a function called from GDB.
Evaluation of the expression containing the function
(callexit) will be abandoned.
❌ No registers.
(gdb)
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16156 Approved-By: Andrew Burgess <aburgess@redhat.com>
Hannes Domani [Mon, 22 Dec 2025 11:06:43 +0000 (12:06 +0100)]
Fix crash if breakpoint commands contain detach or kill
If breakpoint commands contain detach or kill, then gdb tries to access
freed memory:
(gdb) b main
Breakpoint 1 at 0x111d: file main.c, line 21.
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>detach
>end
(gdb) run
Starting program: /home/src/lappy/binutils-gdb.git/gdb/testsuite/gdb.base/main
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
main () at main.c:21
21 return 0;
[Inferior 1 (process 241852) detached]
=================================================================
==241817==ERROR: AddressSanitizer: heap-use-after-free on address 0x7b7a3de0b760 at pc 0x55fcb92613fe bp 0x7ffec2d524f0 sp 0x7ffec2d524e0
READ of size 8 at 0x7b7a3de0b760 thread T0
#0 0x55fcb92613fd in bpstat_do_actions_1 ../../gdb/breakpoint.c:4898
#1 0x55fcb92617da in bpstat_do_actions() ../../gdb/breakpoint.c:5012
#2 0x55fcba3180e7 in inferior_event_handler(inferior_event_type) ../../gdb/inf-loop.c:71
#3 0x55fcba3ba1e1 in fetch_inferior_event() ../../gdb/infrun.c:4769
0x7b7a3de0b760 is located 0 bytes inside of 56-byte region [0x7b7a3de0b760,0x7b7a3de0b798)
freed by thread T0 here:
#0 0x7f1a43522a2d in operator delete(void*, unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:155
#1 0x55fcb925d5cd in bpstat_clear(bpstat**) ../../gdb/breakpoint.c:4646
#2 0x55fcbb69ea6a in clear_thread_inferior_resources ../../gdb/thread.c:185
#3 0x55fcbb69f4cb in set_thread_exited(thread_info*, std::optional<unsigned long>, bool) ../../gdb/thread.c:244
#4 0x55fcba368d64 in operator() ../../gdb/inferior.c:269
#5 0x55fcba375e2b in clear_and_dispose<inferior::clear_thread_list()::<lambda(thread_info*)> > ../../gdb/../gdbsupport/intrusive_list.h:529
#6 0x55fcba368f19 in inferior::clear_thread_list() ../../gdb/inferior.c:265
#7 0x55fcba3694ba in exit_inferior(inferior*) ../../gdb/inferior.c:322
#8 0x55fcba369e35 in detach_inferior(inferior*) ../../gdb/inferior.c:358
#9 0x55fcba319d9f in inf_ptrace_target::detach_success(inferior*) ../../gdb/inf-ptrace.c:214
#10 0x55fcba56a2f6 in linux_nat_target::detach(inferior*, int) ../../gdb/linux-nat.c:1582
#11 0x55fcba62121c in thread_db_target::detach(inferior*, int) ../../gdb/linux-thread-db.c:1381
#12 0x55fcbb5ca49e in target_detach(inferior*, int) ../../gdb/target.c:2557
#13 0x55fcba356ba4 in detach_command(char const*, int) ../../gdb/infcmd.c:2894
#14 0x55fcb9597eea in do_simple_func ../../gdb/cli/cli-decode.c:94
#15 0x55fcb95b10b5 in cmd_func(cmd_list_element*, char const*, int) ../../gdb/cli/cli-decode.c:2831
#16 0x55fcbb6f5282 in execute_command(char const*, int) ../../gdb/top.c:563
#17 0x55fcb95eedb9 in execute_control_command_1 ../../gdb/cli/cli-script.c:526
#18 0x55fcb95f04dd in execute_control_command(command_line*, int) ../../gdb/cli/cli-script.c:702
#19 0x55fcb9261175 in bpstat_do_actions_1 ../../gdb/breakpoint.c:4940
#20 0x55fcb92617da in bpstat_do_actions() ../../gdb/breakpoint.c:5012
#21 0x55fcba3180e7 in inferior_event_handler(inferior_event_type) ../../gdb/inf-loop.c:71
#22 0x55fcba3ba1e1 in fetch_inferior_event() ../../gdb/infrun.c:4769
previously allocated by thread T0 here:
#0 0x7f1a435218cd in operator new(unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:86
#1 0x55fcb927061f in build_bpstat_chain(address_space const*, unsigned long, target_waitstatus const&) ../../gdb/breakpoint.c:5880
#2 0x55fcba3d63b6 in handle_signal_stop ../../gdb/infrun.c:7083
#3 0x55fcba3d01c7 in handle_inferior_event ../../gdb/infrun.c:6574
#4 0x55fcba3b9918 in fetch_inferior_event() ../../gdb/infrun.c:4713
This checks after executing commands of each breakpoint if the bpstat
was deleted already, and stops any further processing immediately.
Now the result looks like this:
(gdb) b main
Breakpoint 1 at 0x111d: file main.c, line 21.
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>detach
>end
(gdb) run
Starting program: /home/src/lappy/binutils-gdb.git/gdb/testsuite/gdb.base/main
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
main () at main.c:21
21 return 0;
[Inferior 1 (process 242940) detached]
(gdb)
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14354 Approved-By: Andrew Burgess <aburgess@redhat.com>
Jan Beulich [Mon, 22 Dec 2025 10:06:59 +0000 (11:06 +0100)]
gas: stub out sframe-opt.c functions when SFrame is not supported
Much like everything in gen-sframe.c, these functions are supposed to
never be reached when SFrame isn't supported by a target. Adding
respective assertions reduces code size for such targets, while at the
same time adding consistency checking for targets which optionally
support the feature.
Jan Beulich [Mon, 22 Dec 2025 10:06:35 +0000 (11:06 +0100)]
gas/x86: reduce / correct target checks for --64 command line option
First, pei-x86-64 is meaningless for gas; it's a linker output target, not
one object files would use. Next, coff-x86-64 is meaningless for TE_PE
(and really coff-x86-64 isn't currently provided by any libbfd
configuration anyway). Then, of the three ones left exactly one is a
possible candidate for a given gas configuration. Checking others as well
would only lead to (possibly cryptic) errors later. And finally, even for
ELF we want to check for the one target which i386_target_format() would
also use. This last aspect then applies to --x32 handling as well (just
that there it's benign right now, as only one target exists starting
"elf32-x86-64".
Alan Modra [Sat, 20 Dec 2025 03:49:50 +0000 (14:19 +1030)]
Add back non-solaris ELF targets to solaris config
This reverses some of the changes made in config.bfd for PR 27666.
Removing targets for that PR was really just a workaround, and since
the underlying bug is now fixed they can be added back.
I chose to add the non-solaris ELF targets to the linker config using
targ_extra_emuls rather than targ_extra_libpath because someone using
the elf32_sparc emulation probably doesn't want to pick up solaris
libraries by accident.
PR 33374
bfd/
* config.bfd: Remove pr27666 comments. Add back non-solaris
ELF targets to selvecs for solaris targets.
ld/
* configure.tgt: Adjust solaris targets to suit config.bfd
change.
Indu Bhagat [Sat, 20 Dec 2025 07:11:45 +0000 (23:11 -0800)]
bfd: include: sframe: fix PR ld/32789
Currently, when SFrame sections are emitted after linking the input
SFrame sections, the SFrame FDEs are sorted on start PC. Doing so for
relocatable links has no effect (SFrame FDEs remain in place), because
the start PC is unrelocated data. For relocatable links, then, the
emitted SFrame FDEs in the output section remain in the same order as
that in the respective input BFD.
The assembler does not guarantee the emission of SFrame FDEs in the same
order as the placement of the associated .text* sections,
(SFRAME_F_FDE_SORTED is not set in the ET_REL objs generated by GAS).
This means setting SFRAME_F_FDE_SORTED by the linker was wrong when:
- doing relocatable link, and
- the input bfds contain multiple .text sections, say .text.hot,
.text.init, .text.unlikely etc.
For relocatable links, skip sorting the SFrame FDEs. Do not set
SFRAME_F_FDE_SORTED for relocatable links.
This is achieved by adding an explicit argument (bool sort_fde_p) to the
sframe_encoder_write API. Move the API from 2.0 to the 2.1 node as this
is an ABI-incompatible change. Skip bumping the "current" in
libsframe/libtool-version ATM, we will do so closer to release.
When writing of SFrame data for PLT entries, indicate sort_fde_p to
false: these sections are like the other SFrame sections for any other
ET_REL binary.
Add a test in ld/testsuite/ld-sframe/sframe.exp, these tests are run for
all ABIs supported for SFrame. In this test, for object file generated
for pr32789-1a.c:
- the emitted SFrame FDEs by GAS are in the order of the .text* in the
input assembly (i.e., .text.init, .text, .text.exit)
- the emitted .text* sections by GAS are placed in the following order
.text, .text.init, .text.exit.
- GAS does not set SFRAME_F_FDE_SORTED, as expected.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
bfd/
PR ld/32789
* elf-sframe.c (_bfd_elf_write_section_sframe): Skip sorting the
SFrame FDEs for relocatable links.
* elf64-s390.c (_bfd_s390_elf_write_sframe_plt): Additional
argument to sframe_encoder_write.
* elfxx-x86.c (_bfd_x86_elf_write_sframe_plt): Likewise.
libsframe/
* libsframe.ver: Move from 2.0 node to 2.1.
* sframe.c (sframe_encoder_write_sframe): Conditionalize based
on argument sort_fde_p.
(sframe_encoder_write): New argument to indicate whether SFrame
FDEs are to be sorted in output.
include/
* sframe-api.h (sframe_encoder_write): New argument.
ld/testsuite/
PR ld/32789
* ld/testsuite/ld-sframe/sframe.exp: New test.
* ld/testsuite/ld-sframe/pr32789-1.rd: New test.
* ld/testsuite/ld-sframe/pr32789-1.sd: New test.
* ld/testsuite/ld-sframe/pr32789-1a.c: New test.
* ld/testsuite/ld-sframe/pr32789-1b.c: New test.
* ld/testsuite/ld-x86-64/sframe-reloc-1.d: Remove
SFRAME_F_FDE_SORTED.
Alan Modra [Sat, 20 Dec 2025 03:47:14 +0000 (14:17 +1030)]
ld targ_extra_emuls and targ_extra_libpath
targ_extra_libpath are for those targets other than the default target
that might have libraries available in the default library search
paths. targ_extra_emuls are for those targets that likely don't.
Sort them so those on the libpath come first. This currently does not
have any effect except for order of compilation of e*.c and the order
printed in ld help messages, but I thought it worth doing anyway.
* configure.ac (all_emuls): Sort targ_extra_libpath before
targ_extra_emuls.
* configure: Regenerate.
Alan Modra [Sat, 20 Dec 2025 03:44:47 +0000 (14:14 +1030)]
more solaris config tidies
This patch is primarily about making ld and bfd config match for
solaris targets. In commit 3677b7296185 I made the bfd config match
the ld config, which resulted in PR 27666. This goes the other way,
changing the ld config to match bfd. The current mismatch results in
failures like:
..ld-new: target elf32-i386 not found
FAIL: Build libgot-1-i386.so
The problem is that even though the elf32-i386 target is compiled in
to bfd, it is excluded from the list of targets supported by bfd.
ld -V says it is there, but can't use it..
Secondarily, remove "want64" from the 32-bit x86 and sparc solaris
targets in config.bfd, and arrange for ld/configure.tgt to match that
by using targ64_extra_emuls. This means that on a 32-bit host you
won't get the 64-bit solaris target support by default. Setting
"want64" forces use of 64-bit bfd_vma on such hosts, which usually
isn't needed for a 32-bit target, and when "want64" is true it is a
little odd to see targ64_selvecs used. Also, some nonsense has crept
in to ld/configure.tgt regarding targ_extra_libpath. Any target
mentioned in targ_extra_libpath does not need to be mentioned in
targ_extra_emuls. So tidy that for solaris.
Finally, matching of solaris targets has been simplified. This does
not change target triple matching, except with --enable-obsolete.
Without --enable-obsolete, you will still need to specify solaris2.10
or solaris2.11 as the operating system part of the target triple, and
this is expected to become permanent after the next binutils release.
PR 27666
bfd/
* config.bfd: Simplify solaris target matching. Remove
"want64" from x86 and 32-bit sparc solaris targets.
ld/
* configure.tgt: Remove non-solaris targets from the x86 and
32-bit sparc solaris targets, and use targ64 variables to add
conditional 64-bit targets. Don't unnecessarily add targets
to targ_extra_emuls that appear in targ_extra_libpatch.
Simplify solaris target matching.
Alan Modra [Sat, 20 Dec 2025 03:42:31 +0000 (14:12 +1030)]
bfd ASSOCIATED_VECS
Tidy code setting ASSOCIATED_VECS, which could be fooled by unusual
configure options such as --enable-targets="srec,all".
* targets.c (_bfd_associated_vector): Remove comma after
ASSOCIATED_VECS.
* configure.ac: Set assocvecs from targ_defvec and
targ_selvecs when handling the target, rather than assuming
those variables are still set for the target when handling
--enable-targets=all. Move code making assocvecs unique
later. Do so in a way that need not run sed afterwards, and
leave a trailing comma.
* configure: Regenerate.
Alan Modra [Sat, 20 Dec 2025 03:35:57 +0000 (14:05 +1030)]
PR 27666, bfd_check_format_matches
bfd_check_format_matches should not change what matches depending on
its "matching" arg. Fix that. This bug in bfd_check_format_matches
is the underlying cause of pr27666.
Lulu Cai [Sat, 13 Dec 2025 07:33:15 +0000 (15:33 +0800)]
LoongArch: Add disassembly support for ud ui5
ud ui5, also known as amswap.w rd,$r1,rj(rd==rj), is displayed as
"ud ui5" by default during disassembly. Alternatively, the original
instruction can be printed using the objdump -M no-aliases.
To implement this support, a format specifier "ru0:5,ru5:5" for ud is
applied exclusively during disassembly. This specifier indicates that
registers should be printed using their corresponding numeric values,
and when the instruction is identified as ud, only a single parameter
is displayed.
binutils/
* testsuite/binutils-all/loongarch64/dis-amswap-ud-noaliases.d:
New test.
* testsuite/binutils-all/loongarch64/dis-amswap-ud.d: New test.
* testsuite/binutils-all/loongarch64/dis-amswap-ud.s: New test.
Alan Modra [Thu, 18 Dec 2025 21:45:14 +0000 (08:15 +1030)]
Re: asan: alpha-vms: mmember access within null pointer
Fix commit c01de193638c error. This in combination with the
vms_lib_bstat error led to an uninitialised stat buf st_size and
intermittent test failures.
Peter Damianov [Fri, 19 Dec 2025 07:52:13 +0000 (08:52 +0100)]
Add windres to TOOL_PROGS
I sent a patch to GCC adding support for passing .rc and .res files to the
driver directly, allowing support for doing things like:
gcc file.c file.rc -o file.exe
However, binutils doesn't install windres into the tooldir, so by default, gcc
will be unable to find windres. This patch adds windres to TOOL_PROGS so this
can work.
Jan Beulich [Fri, 19 Dec 2025 07:51:51 +0000 (08:51 +0100)]
bfd: correct dir separator conversion for Win32
Iterating a wchar_t array holding the conversion of multi-byte (likely
UTF-8) input using array indexes from the corresponding char array isn't
going to work as soon as any characters wider than a single char are
present. Simply walk the wchar_t array all by itself.
While looking at that code I also noticed a wrong argument being passed to
a later MultiByteToWideChar() invocation: This needs to be number of
characters, which isn't sizeof() when the array is of wchar_t elements.
Tom Tromey [Sun, 2 Nov 2025 17:41:21 +0000 (10:41 -0700)]
Don't use "module" name
In C++20, "module" is an "identifier with special meaning". While it
can be used as a variable name, it highlights as a keyword in Emacs,
and I think it's nicer to just avoid it.
gdb: improve line number lookup around inline functions
the following tclint errors were reported:
gdb/testsuite/gdb.dwarf2/dw2-inline-bt.exp:211:26: expression with substitutions should be enclosed by braces [unbraced-expr]
gdb/testsuite/gdb.dwarf2/dw2-inline-bt.exp:212:26: expression with substitutions should be enclosed by braces [unbraced-expr]
Tom Tromey [Wed, 17 Dec 2025 18:08:30 +0000 (11:08 -0700)]
Add Do_Nothing to two more Ada tests
A couple of Ada tests were failing with gnat-llvm, because LLVM is a
bit more aggressive about eliminating unused local variables. This
patch arranges for some variables to be kept alive a little longer,
using the usual Do_Nothing technique.
Tom de Vries [Thu, 18 Dec 2025 09:00:54 +0000 (10:00 +0100)]
binutils-gdb/git: Handle *.ac and *.m4 files in .gitattributes
Since commit 52ca3d3fe61 ("toplevel: unify the GCC and GDB/binutils .editorconfig
files"), .editorconfig has settings for .ac and .m4 files:
...
[*.{ac,m4}]
indent_style = tab
indent_size = 2
trim_trailing_whitespace = true
...
There are no setting for those files in .gitattributes, so the whitespace
attribute defaults to trailing-space (shorthand for blank-at-eol,
blank-at-eof) and space-before-tab.
Since according to .editorconfig the indentation style is tab, add
indent-with-non-tab as well.
Since aclocal.m4 is generated, unset the whitespace attribute. Likewise for
configure.
Simon Marchi [Wed, 17 Dec 2025 04:31:39 +0000 (23:31 -0500)]
gdb: replace msym_bunch with deque
This patch replaces the msym_bunch implementation with an std::deque.
I initially tried to replace it with a vector. However, that doesn't
work, because minimal_symbol references need to stay valid across calls
to minimal_symbol_reader::record_full in at least one spot.
elf_symtab_read calls minimal_symbol_reader::record_full (through
function record_minimal_symbol) to record a minimal symbol for a PLT
entry and then uses a previously added minimal symbol to set the size of
the PLT minimal symbol. If we used a vector, a re-allocation could
happen which would invalidate the reference to the previous minimal
symbol (luckily this was caught by ASan).
An std::deque implementation typically uses a sequence of fixed-sized
arrays, much like our current msym_bunch implementation. So adding an
item at the end will not invalidate existing references. But unlike our
msym_bunch, we don't have to worry about memory management.
I was a bit puzzled about this code in
minimal_symbol_reader::record_full:
/* If we already read minimal symbols for this objfile, then don't
ever allocate a new one. */
if (!m_objfile->per_bfd->minsyms_read)
{
m_msym_bunch_index++;
m_objfile->per_bfd->n_minsyms++;
}
From what I understand, this "feature" gets used when you have
ECOFF debug info in an ELF executable. We first parse the ELF minimal
symbols in elf_symfile_read, then go into elfmdebug_build_psymtabs.
elfmdebug_build_psymtabs has the capability to generate minimal symbols
(useful when you use ECOFF debug info in an ECOFF executable I guess),
but in this case we already have the ELF ones, so we don't want to
record the ECOFF minimal symbols. Hence this mechanism to suppress new
minimal symbols.
The consequence of this patch, I believe, is that
minimal_symbol_reader::record_full will unnecessarily allocate minimal
symbols in this case. These minimal symbols won't be installed, because
of the check in minimal_symbol_reader::install. The minimal symbols
will be freed when the minimal_symbol_reader gets destroyed. That means
a higher temporary memory usage when reading an ECOFF-in-ELF file, but
no change in behavior. See discussion at [1].
Andrew Burgess [Fri, 26 Jul 2024 15:32:33 +0000 (16:32 +0100)]
gdb: improve line number lookup around inline functions
This commit aims to fix an issue where GDB would report the wrong line
for frames other than #0 if a previous frame had just left an inline
function.
Consider this example which is compiled at -Og:
volatile int global = 0;
static inline int bar (void) { asm (""); return 1; }
static void foo (int count)
{ global += count; }
int main (void)
{
foo (bar ());
return 0;
}
Used in this GDB session:
(gdb) break foo
Breakpoint 1 at 0x401106: file test.c, line 6.
(gdb) run
Starting program: /tmp/inline-bt/test.x
Breakpoint 1, foo (count=count@entry=1) at test.c:6
6 { global += count; }
(gdb) frame 1
#1 0x0000000000401121 in main () at test.c:3
3 static inline int bar (void) { asm (""); return 1; }
Notice that GDB incorrectly reports frame #1 as being at line 3 when
it should really be reporting this line:
foo (bar ());
The cause of this problem is in find_pc_sect_line (symtab.c). This
function is passed a PC for which GDB must find the symtab_and_line
information. The function can be called in two modes based on the
NOTCURRENT argument.
When NOTCURRENT is false then we are looking for information about the
current PC, i.e. the PC at which the inferior is currently stopped
at.
When NOTCURRENT is true we are looking for information about a PC that
it not the current PC, but is instead the PC for a previous frame.
The interesting thing in this case is that the PC passed in will be
the address after the address we actually want to lookup information
for, this is because as we unwind the program counter from frame #0
what we get is the return address in frame #1. The return address is
often (or sometimes) on the line after the calling line, and so in
find_pc_sect_line, when NOTCURRENT is true, we subtract 1 from PC and
then proceed as normal looking for information about this new PC
value.
Now lets look at the x86-64 disassembly for 'main' from the above
example. The location marker (=>) represents the return address in
'main' after calling 'foo':
(gdb) run
Starting program: /tmp/inline-bt/test.x
Breakpoint 1, foo (count=count@entry=1) at test.c:6
6 { global += count; }
#0 foo (count=count@entry=1) at test.c:6
#1 0x000000000040111f in main () at test.c:3
(gdb) up
#1 0x000000000040111f in main () at test.c:3
3 static inline int bar (void) { asm (""); return 1; }
(gdb) disassemble
Dump of assembler code for function main:
0x0000000000401115 <+0>: mov $0x1,%edi
0x000000000040111a <+5>: call 0x401106 <foo>
=> 0x000000000040111f <+10>: mov $0x0,%eax
0x0000000000401124 <+15>: ret
End of assembler dump.
And the corresponding line table:
(gdb) maintenance info line-table
objfile: /tmp/inline-bt/test.x ((struct objfile *) 0x59405a0)
compunit_symtab: test.c ((struct compunit_symtab *) 0x53ad320)
symtab: /tmp/inline-bt/test.c ((struct symtab *) 0x53ad3a0)
linetable: ((struct linetable *) 0x53adc90):
INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN
0 6 0x0000000000401106 0x0000000000401106 Y
1 6 0x0000000000401106 0x0000000000401106 Y
2 6 0x0000000000401106 0x0000000000401106
3 6 0x0000000000401114 0x0000000000401114
4 9 0x0000000000401115 0x0000000000401115 Y
5 10 0x0000000000401115 0x0000000000401115 Y
6 3 0x0000000000401115 0x0000000000401115 Y
7 3 0x0000000000401115 0x0000000000401115 Y
8 3 0x0000000000401115 0x0000000000401115 Y
9 10 0x0000000000401115 0x0000000000401115
10 11 0x000000000040111f 0x000000000040111f Y
11 12 0x000000000040111f 0x000000000040111f
12 END 0x0000000000401125 0x0000000000401125 Y
When looking for the line information of frame #1 we start with the
return address 0x40111f, however, as this is not the current program
counter value we subtract one and look for line information for
0x40111e.
We will find the entry at index 9, this is the last entry with an
address less than the address we're looking for, the next entry has an
address greater than the one we're looking for. The entry at index 9
is for line 10 which is the correct line, but GDB reports line 3, so
what's going on?
Having found a matching entry GDB checks to see if the entry is marked
as is-stmt (is statement). In our case index 9 (line 10) is not a
statement, and so GDB looks backwards for entries at the same address,
if any of these are marked is-stmt then GDB will use the last of these
instead. In our case the previous entry at index 8 is marked is-stmt,
and so GDB uses that. The entry at index 8 is for line 3, and that is
why GDB reports the wrong line. So why perform the backward is-stmt
check?
When NOTCURRENT is false (not our case) the backward scan makes
sense. If the inferior has just stopped at some new location, and we
want to report that location to the user, then it is better (I think)
to select an is-stmt entry. In this way we will report a line number
for a line which the inferior is just about to start executing, and
non of the side effects of that line have yet taken place. The line
GDB prints will correspond with the reported line, and if the user
queries the inferior state, the inferior should (assuming the compiler
emitted correct is-stmt markers) correspond to the line in question
having not yet been started.
However, in our case NOTCURRENT is true. We're looking back to
previous frames that are currently in-progress. If upon return to the
previous frame we are about to execute the next line then (it seems to
me) that this indicates we must be performing the very last action
from the previous line. As such, looking back through the line table
in order to report a line that has not yet started is the wrong thing
to do. We really want to report the very last line table entry for
the previous address as this is (I think) most likely to represent the
previous line that is just about to complete.
Further, in the NOTCURRENT case, we should care less about reporting
an is-stmt line. When a user looks back to a previous frame I don't
think they expect the line being reported to have not yet started. In
fact I think the expectation is the reverse ... after all, the
previous line must have executed enough to call the current frame.
So my proposal is that the backward scan of the line table looking for
an is-stmt entry should not be performed when NOTCURRENT is true. In
the case above this means we will report the entry at index 9, which
is for line 10, which is correct.
For testing this commit I have:
1. Extended the existing gdb.opt/inline-bt.exp test. I've extended
the source code to include a test similar to the example above. I
have also extended the script so that the test is compiled at a
variety of optimisation levels (O0, Og, O1, O2).
2. Added a new DWARF assembler test which hard codes a line table
similar to the example given above. My hope is that even if test
case (1) changes (due to compiler changes) this test will continue to
test the specific case I'm interested in.
I have tested the gdb.opt/inline-bt.exp test with gcc versions 8.4.0,
9.3.1, 10.5.0, 11.5.0, 12.2.0, and 14.2.0, in each case the test will
fail (with the expected error) without this patch applied, and will
pass with this patch applied.
I was inspired to write this patch while reviewing these patches:
though this patch only covers one of the issues addressed by these
patches, and the approach taken is quite different. Still, those
patches are worth reading for the history of this fix.
Tom de Vries [Wed, 17 Dec 2025 14:04:21 +0000 (15:04 +0100)]
bfd/ELF: Handle prstatus of 156 bytes in elf32_arm_nabi_grok_prstatus
For a corefile generated on openSUSE Leap 15.2 armv7l with linux version
5.3.18, we get:
...
$ gdb -q --core core
...
Core was generated by `/usr/bin/rs_scope -d'.
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
...
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 bug causes the FDPIC-specific unsigned long fields pr_exec_fdpic_loadmap
and pr_interp_fdpic_loadmap to be added to struct elf_prstatus in case the
FDPIC ABI is not used.
Work around this bug in elf32_arm_nabi_grok_prstatus, by ignoring the extra
fields, which gets us instead:
...
Core was generated by `/usr/bin/rs_scope -d'.
Program terminated with signal SIGSEGV, Segmentation fault.
[Current thread is 1 (LWP 30047)]
(gdb)
...
Tested gdb, gas, binutils and ld on x86_64-linux and arm-linux with
--enable-targets=all.
projects / thirdparty / binutils-gdb.git / log
