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.
Alan Modra [Tue, 16 Dec 2025 21:30:24 +0000 (08:00 +1030)]
PR 33721 load/store of misaligned address
This fixes PR33721 by a common technique of declaring a packed struct
to access unaligned integer fields. (See eg. linux kernel
include/vdso/unaligned.h) I've tidied the PR29856 fix for a similar
bug too (not that there was anything wrong with that fix).
PR 33721
PR 29856
* sframe.c (flip_fre_start_address): Use a packed struct to
access 2-byte and 4-byte unaligned fields. Make addr a void*.
(sframe_decode_fre_start_address): Similarly, and remove
unnecessary casts. Always set *fre_start_addr.
Alan Modra [Tue, 16 Dec 2025 21:22:06 +0000 (07:52 +1030)]
more solaris tidies
Don't overspecify the obsolete solaris targets: match solaris* rather
than solaris2.[0-9]*. Move the sparc-*-solaris2.[0-6]* match later,
and make it sparc*-*-solaris* so that it catches sparcv9 and sparc64.
This change is necessary for internal binutils consistency so that
selecting --target=sparc-sun-solaris2 gets an error that the target is
obsolete, and furthermore that the same target with --enable-obsolete
does not result in runtime errors.
bfd/
* config.bfd: Don't overspecify obsolete solaris targets.
ld/
* configure.tgt: Don't overspecify obsolete solaris targets.
* po/BLD-POTFILES.in: Regenerate.
Tom de Vries [Tue, 16 Dec 2025 20:10:11 +0000 (21:10 +0100)]
[gdb/testsuite] Fix gdb.cp/typeid.exp with m32 PIE
On x86_64-linux, if I run test-case gdb.cp/typeid.exp with target boards:
- unix/-m64
- unix/-m32
- unix/-fPIE/-pie/-m64
- unix/-fPIE/-pie/-m32
for only target board unix/-fPIE/-pie/-m32 I get:
...
(gdb) print &typeid(i)^M
could not find typeinfo symbol for 'int'^M
(gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(i)
print &typeid(i) == &typeid(typeof(i))^M
could not find typeinfo symbol for 'int'^M
(gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(i) == &typeid(typeof(i))
print &typeid(cp)^M
could not find typeinfo symbol for 'char*'^M
(gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(cp)
print &typeid(cp) == &typeid(typeof(cp))^M
could not find typeinfo symbol for 'char*'^M
(gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(cp) == &typeid(typeof(cp))
print &typeid(ccp)^M
could not find typeinfo symbol for 'char const*'^M
(gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(ccp)
print &typeid(ccp) == &typeid(typeof(ccp))^M
could not find typeinfo symbol for 'char const*'^M
(gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(ccp) == &typeid(typeof(ccp))
...
This is yet another configuration for which these tests don't work.
We're already allowing this for clang and istarget "powerpc*-*-*".
I don't think there is value in trying to detect yet another configuration.
Instead, just allow it in general.
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Indu Bhagat [Tue, 16 Dec 2025 19:54:07 +0000 (11:54 -0800)]
gas: sframe: fix memory leak of remember_fre
While at it, use the same pattern for cleaning up memory in
sframe_xlate_ctx_cleanup.
gas/
* gen-sframe.c (sframe_xlate_ctx_cleanup): Use the same pattern
for free'ing memory consistently.
(sframe_xlate_ctx_finalize): Free up remember_fre.
Andrew Burgess [Sat, 15 Nov 2025 14:55:19 +0000 (14:55 +0000)]
gdb: shortcut 'list LINENO'
While working on a test for a weird interaction between the DWARF
parser, debuginfod, and the 'list' command, I noticed that performing
'list LINENO' can incur a significant amount of work trying to figure
out which symtab the source should be listed from. This seems a
little weird as a plain 'list' just uses the default symtab with no
searching through all of the symtabs.
The symtab lookup is all hidden behind the decode_line_1 call, which
is made from list_command (cli/cli-cmds.c).
The thing is, in list_command we already have code which (basically)
checks if the argument to 'list' is a line number, here's the code:
And we already have code within list_command which depends on the
default symtab, look at how 'list .', 'list +', and 'list -' are
handled.
I think that 'list LINENO' is such a common use case that is makes
sense to optimise this case in order to avoid the need to perform
symtab lookup. I think this can be achieved without any significant
changes to the list_command function; we'll just move the existing
line number check (see above code) a little earlier in the function
and change it to a strtol call so that the actual line number is
recorded. Then there's a little error checking, before finally we can
skip straight to listing the source code using the default symtab.
For anything other than 'list LINENO' we will handle the command just
as we've always done.
I think there's actually scope for list_command to handle more cases
internally, without calling out to decode_line_1, but I thought I'd
see how happy people were with this smaller change first before I
tried anything larger.
There should be no user visible changes after this commit, other than
'list LINENO' might be a little faster.
Andrew Burgess [Sat, 15 Nov 2025 14:17:01 +0000 (14:17 +0000)]
gdb: minor code cleanups in list_command
There should be no functional change after this commit, this is mostly
just a code cleanup in the list_command function.
I have inlined local variables into the function body, changing 'int'
to 'bool' where appropriate, and updating 'if' conditions to avoid
treating non-bools as a bool.
I also make more use of list_around_line towards the end of the
list_command function, which avoids some code duplication, but
shouldn't be a functional change.
Tom de Vries [Tue, 16 Dec 2025 15:20:22 +0000 (16:20 +0100)]
[gdb] Fix "the the"
Replace "the the" with "the".
Result of running:
...
$ find gdb* -type f | egrep -v ChangeLog | xargs sed -i 's/the the /the /'
$ find gdb* -type f | egrep -v ChangeLog | xargs sed -i 's/the the$/the/'
...
The only change I have doubts about, is this comment in queue_comp_unit in
gdb/dwarf2/read.c:
...
... . If the CU gets enqueued by this function but its DIEs
- are not yet loaded, the the caller must load the CU's DIEs to ensure the
+ are not yet loaded, the caller must load the CU's DIEs to ensure the
invariant is respected.
...
where I think "the the" -> "then the" also make sense. But for now, I'm going
with "the the" -> "the".
Tested by building gdb on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This commit introduces 'class scoped_gdb_ttystate', a RAII class which
backs up and restores the current terminal state. Unfortunately, the
implementation tries to backup and restore the state even when GDB is
not attached to a terminal.
If GDB is not attached to a terminal then serial_get_tty_state
will (on a Unix like system) return a NULL pointer. Calling
serial_set_tty_state with a NULL state object will trigger the crash
seen above.
Elsewhere in GDB, calling serial_set_tty_state is guarded by calling
gdb_has_a_terminal(). I propose that we only try to backup the
terminal state if GDB is actually connected to a terminal. The call
to serial_set_tty_state will only be made if the backed up tty state
is not NULL.
With this change in place the crash is resolved. There's a new test
to cover this case.
While I'm here I added a gdb_assert in ser-unix.c which would have
triggered in this case before we saw the crash. And I've extended the
comment in serial.h to document that serial_get_tty_state can return
NULL.
Andrew Burgess [Sat, 13 Dec 2025 08:36:01 +0000 (08:36 +0000)]
gdb: rename scoped_gdb_tty_state, and make it non-copyable
The scoped_gdb_tty_state class seems misnamed. For save/restore type
classes the pattern in GDB is usually scoped_restore_<whatever>, so
lets rename this to scoped_restore_tty_state. I dropped the 'gdb' part
of the name as the underlying functions being called are
serial_get_tty_state and serial_set_tty_state, so the new name
matches (I think) what's actually being called.
I've also made the class non-copyable like other scoped_restore_
classes.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
I incorrectly used @value{on} and @value{off} to reference the on/off
settings of a new flag. This caused the following warnings when
building the docs:
gdb.texinfo:51356: warning: undefined flag: off
gdb.texinfo:51357: warning: undefined flag: on
Looking through the docs there seems to be a split, in some cases we
use @code and in others we use @samp. I'm not sure @code is correct,
so I've switched to use @samp. The warnings are gone after this
patch.
Alan Modra [Tue, 16 Dec 2025 08:43:15 +0000 (19:13 +1030)]
Re: LoongArch: Add linker relaxation support for R_LARCH_CALL30
clang catches this error and another like it on line 6320.
elfnn-loongarch.c:6357:35: error: overlapping comparisons always evaluate to true [-Werror,-Wtautological-overlap-compare]
6357 | && (r_type != R_LARCH_CALL36 || r_type != R_LARCH_CALL30))
| ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
* elfnn-loongarch.c (loongarch_elf_relax_section): Correct tests
for R_LARCH_CALL36 and_LARCH_CALL30.
Simon Marchi [Mon, 15 Dec 2025 21:27:18 +0000 (16:27 -0500)]
gdb/testsuite: fix tcllint errors in gdb.base/startup-hints.exp
Fix:
gdb/testsuite/gdb.base/startup-hints.exp:61:44: expression with substitutions should be enclosed by braces [unbraced-expr]
gdb/testsuite/gdb.base/startup-hints.exp:64:28: expression with substitutions should be enclosed by braces [unbraced-expr]
LD/testsuite: Expand archive verification to group feature
Expand archive verification to cover the group feature. Linker error
messages for unsatisfied symbol references vary between targets a bit,
in particular `arc-*-*' produce duplicate messages and `alpha*-*-osf*'
and `alpha*-*-linux*ecoff*' add a "final link failed" message. Factor
this in with the error pattern list to match. Usual XFAIL annotations
apply.
CRIS/LD/testsuite: Add tests for emulation switching
Add tests matching generic ones from ld-archive/archive.exp for explicit
link emulation switching, verifying that correct output is produced from
a link including an archive the format of which is not the default one.
This covers generic BFD code using `cris-aout' and `cris-elf' targets as
ones that permit switching between dissimilar emulations from assembly
through the link.
Only tests for link emulation explicitly specified are included at this
stage, as bugs in BFD currently prevent links from successful completion
that use the default emulation while involving archives in a non-default
format. Additional tests will be included with a subsequent change that
addresses said bugs.
LD/testsuite: Expand archive verification to `--whole-archive' feature
Expand archive verification to cover the `--whole-archive' feature,
adding link map and verbose output matching to verify the correct
archive members are added and the unwanted ones omitted.
Adjust the linker flags accordingly for XCOFF targets, by switching from
the `-bexpall' option to `-unix' (`-bexpfull' would do too, but has some
test coverage already, unlike `-unix', which is a superset of the former
option), so that additional symbols pulled with `--whole-archive' aren't
discarded by linker garbage collection.
This test expansion has revealed the lack of thin archive support in AR
for Alpha/VMS and XCOFF targets, despite apparent presence of relevant
code in the respective BFD backends. With `ar rcT' invocation a regular
archive is silently produced instead.
Rather than making the relevant tests overly permissive, XFAIL them for
the affected targets, referring PR binutils/33600.
VMS/BFD: Fix a sign extension issue with archive symbol lookup
Symbol binary search code for VMS archive files uses plain `char' data
type to cast a difference between characters to data of the `int' type.
Consequently the difference is consider unsigned in the range between 0
and 255 on hosts where plain `char' data type is unsigned, resulting in
symbol lookup failures, such as with the test expansion included with
this change causing regressions as follows:
FAIL: Regular archive link
FAIL: Thin archive link
FAIL: Regular archive plus regular link
FAIL: Regular archive plus thin link
FAIL: Thin archive plus regular link
FAIL: Thin archive plus thin link
owing to link failures such as:
.../ld/ld-new: tmpdir/abc.o:($DATA$+0x0): undefined reference to `aa'
.../ld/ld-new: tmpdir/ab.a(b.obj):($DATA$+0x10): undefined reference to `aa'
.../ld/ld-new: tmpdir/abc.o:($DATA$+0x0): undefined reference to `aa'
.../ld/ld-new: tmpdir/ab.a(b.obj):($DATA$+0x10): undefined reference to `aa'
with the `alpha-dec-vms' target on the `powerpc64le-linux-gnu' host.
Use explicit `signed char' data type for the cast then, removing the
failures.
LD/testsuite: Fix archive verification for Alpha/VMS
As from commit a2298f23f2e2 ("PR 33385 vms archives") the handling of
Alpha/VMS archives has been recently unbroken, after 7 years, revealing
issues with archive tests added with commit 435223a9ae70 ("LD/testsuite:
Add tests for archive handling"), the change of the failure mode of
which went unnoticed.
In particular there is no NM support for executables and archives always
have an index by the nature of the format; cf. `_bfd_vms_lib_archive_p':
"The map is always present."
Address these peculiarities by excluding NM tests for the executables
produced and by omitting mapless archive rejection tests just as with
XCOFF targets, removing all the test failures:
alpha-dec-vms -FAIL: Regular archive link
alpha-dec-vms -FAIL: Thin archive link
alpha-dec-vms -FAIL: Regular archive plus regular link
alpha-dec-vms -FAIL: Regular archive plus thin link
alpha-dec-vms -FAIL: Thin archive plus regular link
alpha-dec-vms -FAIL: Thin archive plus thin link
alpha-dec-vms -FAIL: Regular archive w/o index link
alpha-dec-vms -FAIL: Thin archive w/o index link
Factor out code to filter out unwanted tests to a procedure for a better
structure of the code.
PR binutils/33485: LD/testsuite: Also XFAIL `ns32k-*-*' targets
NS32k targets also use the a.out archive format, which suffers from PR
binutils/33485 where symbol indexes in a.out thin archives are missing
symbols for subsequent members. This affects `ns32k-pc532-lites*',
`ns32k-pc532-mach*', and `ns32k-pc532-ux*' targets in particular; other
NS32k targets appear defunct. Add suitable XFAIL annotation, removing
failures such as:
ns32k-pc532-lites -FAIL: Thin archive link
ns32k-pc532-lites -FAIL: Regular archive plus thin link
ns32k-pc532-lites -FAIL: Thin archive plus regular link
ns32k-pc532-lites -FAIL: Thin archive plus thin link
Tom de Vries [Mon, 15 Dec 2025 16:19:26 +0000 (17:19 +0100)]
[pre-commit] Move codespell-log to post-commit
The current pre-commit hook codespell-log works with script
gdb/contrib/codespell-log.sh.
During the commit-msg phase of a commit, the following happens:
- git calls pre-commit
- pre-commit calls gdb/contrib/codespell-log.sh,
- gdb/contrib/codespell-log.sh calls pre-commit, and
- precommit calls codespell.
This purpose of this indirection is to:
- ignore the exit status of codespell (to make sure that the commit is not
aborted), and
- control the version of codespell.
However, if the check fails, the output is a bit messy due to the indirection:
...
$ touch gdb/bla.c
$ git add gdb/bla.c
$ git commit -m "Usuable"
...
codespell-log............................................................Passed
- hook id: codespell-log
- duration: 0.43s
And if the check passes, the output is still verbose due to the verbose=true
setting.
I found a simpler way to implement this.
Given that we don't want to abort the commit, the post-commit stage is a more
natural place for this check. Moving it there solves two problems:
- we no longer need to ignore the exit status of codespell
- we no longer need the verbose=true setting
The only issue is that we need to generate the file containing the commit
message ourselves, something that is provided by git in the commit-msg stage.
So we still need a wrapper script.
However, it seems that specifying a shell script as entry point of a codespell
hook is fine, so we no longer need to call pre-commit from codespell-log.sh.
Having simplified codespell-log.sh, we can downgrade it to a /bin/sh script,
instead of requiring bash.
Andrew Burgess [Fri, 5 Dec 2025 11:33:29 +0000 (11:33 +0000)]
gdb: new setting to disable progress bars
Two commits ago, in the commit titled:
gdb: make get_chars_per_line return an unsigned value
A bodge was added in cli-out.c so that progress bars (as seen when
debuginfod downloads a file) would be disabled when the output
terminal had unlimited width.
The hack was added because this previous commit fixed a bug such that
progress bars could now be displayed in very wide, or even on
unlimited width output terminals. By fixing this bug, progress bars
were now being displayed when running the testsuite, as the testsuite
sets the output terminal to unlimited width.
To avoid breaking the tests, this previous commit added a bodge such
that on unlimited width output terminals, progress bars would always
be disabled. This got the tests passing again, but isn't an ideal
solution.
This commit cleans things up. We now have a new setting:
set progress-bars enabled on|off
show progress-bars enabled
This setting allows progress bars to be turned off. The tests are
then updated to explicitly turn off progress bars. The bodge from the
earlier commit is then removed.
Now, progress bars should display correctly on any width of output
terminal over 50 characters, the minimum required. And the debuginfod
tests should all pass as they turn off progress bars.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
I noticed, that when I start GDB with a file on the command line, I
was seeing some stray '..'. Like this:
$ gdb -nw -nh /tmp/hello.x
GNU gdb (GDB) 18.0.50.20251202-git
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Find the GDB manual online at: ┃
┃ http://www.gnu.org/software/gdb/documentation/. ┃
┃ For help, type "help". ┃
┃ Type "apropos <word>" to search for commands related to <word> ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
..
Reading symbols from /tmp/hello.x...
Notice the '..' after the boxed hint text, that's what I'm complaining
about. Also, notice that the last line within the box is missing its
period.
Before the above commit the last line would appear like this when no
file was loaded:
Type "apropos <word>" to search for commands related to <word>.
And like this when a file was being loaded:
Type "apropos <word>" to search for commands related to <word>...
The extra '..' are added to show that a file is being loaded, and that
this might take some time. But we have the 'Reading symbols from ...'
text to indicate this now, so I think the extra '..' are redundant.
Lets just drop them. This will leave just a single period at the end
of the sentence.
The above commit unfortunately, didn't include any tests, so I thought
I'd write some to cover this fix.... and that uncovered a bug where
the box around the startup hints could be corrupted:
$ gdb -eiex 'set width 50' -nw -nh
GNU gdb (GDB) 18.0.50.20251202-git
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Find the GDB manual online at: ┃
┃ http://www.gnu.org/software/gdb/documentation/. ┃
┃ For help, type "help". ┃
┃ Type "apropos <word>" to ┃
┃ search for commands related to <word> ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
(gdb)
This was caused by a mistake on the line where we choose whether to
box or not. The line is currently:
if (width - 3 <= docs_url.length ())
There are two problems here, the '3' should be '4'. The box adds 4
characters '| ' and ' |'. But also, the WIDTH can be very small, less
than 4 even, which means that the subtraction can underflow, wrapping
around and giving a very large value. I plan to rewrite the line to:
if (width < docs_url.length () + 1 + 4)
The '+ 1' accounts for the period at the end of the URL line (which
was previously handled by the '<=', and the '+ 4' accounts for the box
borders. By making it a '+ 4' on the URL, rather than '- 4' from the
width, we avoid underflow. This is fine so long as the URL to our
documentation doesn't approach UINT_MAX in length. Which I hope it
never does.
I've added a couple of asserts to print_gdb_hints to reflect things
that must be true. The first is that get_chars_per_line never returns
0. And later on, I assert that 'width > 4' in a place where we are
about to do 'width - 4'. If the assert triggers then underflow would
have occurred.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Thu, 4 Dec 2025 15:19:37 +0000 (15:19 +0000)]
gdb: make get_chars_per_line return an unsigned value
I noticed that get_chars_per_line currently returns an 'int', but the
value it is returning, from utils.c, is an 'unsigned int'. In some
cases this can cause weird behaviour as an unlimited width terminal
will have UINT_MAX characters per line, which will appear as negative
when returned from get_chars_per_line.
This has been the case since get_chars_per_line was added in commit:
Lets make get_chars_per_line return an unsigned value, and update all
the uses of this function to hold the result in an unsigned variable.
I ran into this issue when looking at print_gdb_hints (from top.c)
where a very large get_chars_per_line() value would appear negative,
and so the startup hints would be printed without a box when really
they should have been boxed. Someone else noticed this problem while
I was building this patch, and pushed commit:
gdb: handle unlimited screen width case in print_gdb_hints
This commit works around the signed / unsigned confusion entirely
within print_gdb_hints by adding a case to 'int' in one place. The
change I present here reverts parts of 06e470d8fc0a in favour of
fixing the type of WIDTH within print_gdb_hints.
It is worth nothing that there are other bugs in print_gdb_hints
relating to how WIDTH is handled, but these are fixed in the next
commit.
By updating the return type of get_chars_per_line, I ran into some
issues in cli-out.c relating to how progress bars are handled. The
existing code includes code like:
The early return here triggers when progress bars should not be
printed. Notice that when the terminal width is unlimited,
CHARS_PER_LINE will appear negative, and so the early return will
trigger.
It turns out that our testsuite depends on this; the debuginfod tests
don't expect to see a progress bar, and they don't because within the
tests we set the width to unlimited.
By "fixing" the type of CHARS_PER_LINE to 'unsigned int', an unlimited
width terminal no longer triggers the early return, and GDB starts
trying to print a progress bar in our debuginfod tests, which cause
the tests to fail.
I think the real fix is to add a new flag to allow progress bars to be
disabled, the tests can then use this. I will add just such a flag at
the end of this series.
For now though, I propose adding a bodge. If CHARS_PER_LINE is
UINT_MAX, then we should act as if progress bars are disabled. The
above code now becomes:
This change is in cli_ui_out::clear_progress_notify. There is a
similar change in cli_ui_out::do_progress_notify. With these two
changes, the debuginfod tests are working again. This bodge will be
removed by the last patch in this series.
There's no tests with this commit yet as print_gdb_hints has other
bugs which will be fixed in the next commit. At this point I'll add
some tests.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Some Debug Adapter Protocol clients like Helix set the optional
"arguments" field of the ConfigurationDone request to null, which is a
bit odd but seems to be allowed by the protocol specification. Before
this patch, Python exceptions would be raised on such requests. This
patch makes it so these requests are treated as if the "arguments"
field was absent.
Tom Tromey [Fri, 12 Dec 2025 18:45:42 +0000 (11:45 -0700)]
Use skip_spaces in more places
I looked through gdb for instance of:
while (*p == ' ' || *p == '\t')
p++;
... and replaced these with a call to skip_spaces.
In some cases this might slightly change the semantics, as now other
whitespace (like \r or \f) will be considered. However I don't think
this matters.
Regression tested on x86-64 Fedora 41.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This patch adds support for new BTI <target> "r" (instruction: bti r),
which is an alias to "bti" (with no target), for both "bti" and "bti r"
the preferred disassembly is "bti r". This "bti r" instruction is by
default available from Armv8-A architecture.
The HINT_OPD_F_NOPRINT macro has become redundant with these changes
and has been removed.
Jan Beulich [Mon, 15 Dec 2025 10:29:33 +0000 (11:29 +0100)]
bfd/ELF: fold BFD_RELOC_<arch>_RELATIVE
There's no need to have a separate reloc per arch; just like for other
more or less generic ones a single one will (mostly) do. Arm64, C-Sky,
and KVX - sadly - are exceptions.
Jan Beulich [Mon, 15 Dec 2025 10:29:19 +0000 (11:29 +0100)]
bfd/ELF: fold BFD_RELOC_<arch>_J{,U}MP_SLOT
There's no need to have a separate reloc per arch; just like for other
more or less generic ones a single one will (mostly) do. Arm64, C-Sky,
and KVX - sadly - are exceptions.
Jan Beulich [Mon, 15 Dec 2025 10:28:50 +0000 (11:28 +0100)]
bfd/ELF: fold BFD_RELOC_<arch>_GLOB_DAT
There's no need to have a separate reloc per arch; just like for other
more or less generic ones a single one will (mostly) do. Arm64, C-Sky,
and KVX - sadly - are exceptions.
Jan Beulich [Mon, 15 Dec 2025 10:28:14 +0000 (11:28 +0100)]
bfd/ELF: fold BFD_RELOC_<arch>_COPY
There's no need to have a separate reloc per arch; just like for other
more or less generic ones a single one will (mostly) do. Arm64, C-Sky,
and KVX - sadly - are exceptions.
Jan Beulich [Mon, 15 Dec 2025 10:27:56 +0000 (11:27 +0100)]
bfd/ELF: fold BFD_RELOC_<arch>_IRELATIVE
There's no need to have a separate reloc per arch; just like for other
more or less generic ones a single one will (mostly) do. Arm64, C-Sky, and
KVX - sadly - are exceptions.
Fix binutils build on hppa64-hpux with gcc-16 (v3)
With recent gcc versions, implicit function declarations are errors.
We need to ensure that ffs() and strtoull() are declared and correctly
checked for by configure.
strtoull() is not declared on hpux but it's provided by libiberty.
An unnecessary include of strings.h in elf32-xtensa.c is removed.
Approved-By: Jan Beulich <jbeulich@suse.com>
2025-12-14 John David Anglin <danglin@gcc.gnu.org>
bfd/ChangeLog:
* configure.ac: Check for strtoull declaration.
* elf32-xtensa.c: Remove strings.h include.
* configure: Regenerate.
* config.in: Regenerate.
* sysdep.h: Include strings.h and declare strtoull()
if a declaration for it isn't found by configure.
ld/ChangeLog:
* configure.ac: Check for strtoull declaration.
* configure: Regenerate.
* config.in: Regenerate.
* sysdep.h: Declare strtoull() if a declaration for it
isn't found by configure.
Alan Modra [Fri, 12 Dec 2025 23:00:46 +0000 (09:30 +1030)]
Re: ld: testsuite: Add sframe test for PR 33401
If user CXXFLAGS include -fno-inline the test fails with
FAIL: PR ld/33401 (Step 1: Create relocatable object and check R_*_NONE)
This should not be a FAIL. If the compiler does not generate R_*_NONE
(a good thing!) then it should be UNTESTED, which means the readelf
check can't be done by run_cc_link_tests. I haven't made that change
in this patch, just worked around a user -fno-inline.
When linking for a relocable output file (-r), one or more R_*_NONE
relocations may be generated for .sframe section. Two new tcl
procedures are added to sframe.exp file. 'check-dump' is checking if
an input bin file has the same relocation as specified in the second
input argument. 'check_pr33401' is the main checking function for
PR33401 which calls twice the ld tool to produce an relocable output
file.
ld:
PR33401
* testsuite/ld-sframe/StateClient.cpp: New file.
* testsuite/ld-sframe/StatePlaying.cpp: Likewise.
* testsuite/ld-sframe/pr33401.rd: Likewise.
* testsuite/ld-sframe/sframe.exp (check_pr33401): New procedure.
Indu Bhagat [Fri, 12 Dec 2025 15:02:32 +0000 (17:02 +0200)]
bfd: ld: sframe: skip R_*_NONE relocations from input bfds
Fix PR ld/33401 - SFrame assertion when linking gav-0.9.1
As the issue demonstrates, R_*_NONE relocations are not necessarily
at the end of .sframe section (previously thought so with PR ld/33127).
Skip over R_*_NONE relocs when they are strewn intermittently inside the
.rela.sframe section.
bfd/
PR ld/33401
* elf-sframe.c (sframe_decoder_init_func_bfdinfo): Skip over
R_*_NONE relocations.
Jan Beulich [Fri, 12 Dec 2025 14:00:41 +0000 (15:00 +0100)]
gas/gen-sframe: avoid gcc extension using __VA_ARGS__
We shouldn't be using extensions when we don't have a suitable fallback in
place. Introducing a format-argument-less counterpart macro would feel a
little odd here. Instead make the sole use site have a (fake) argument
(the non-translatable part of the string).
LIU Hao [Fri, 12 Dec 2025 14:00:15 +0000 (15:00 +0100)]
ld/pe-dll: Don't auto-export symbols from .tls section
The .tls section of an image contains template data that will be duplicated
for each new thread to be created. Accessing thread-local data involves an
image-specific global variable, _tls_used, for calculation. Therefore, it is
impossible to export thread-local variables from a DLL.
The only symbol that exists in the .tls input section is _tls_start, but it's
a CRT symbol and is never auto-exported. It's only necessary to check for
user symbols, which are always generated in the subsection .tls$ by default,
or in subsections like .tls$$<symbol> when -fdata-sections is specified.
Reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881 Signed-off-by: LIU Hao <lh_mouse@126.com>
bfd: Add minimal support to handle note that describes xsave layout
This note section is already supported by Linux kernel.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/kernel/fpu/xstate.c?id=ba386777a30b38dabcc7fb8a89ec2869a09915f7
Co-Authored-By: Jini Susan George <jinisusan.george@amd.com>
Tom de Vries [Fri, 12 Dec 2025 08:35:23 +0000 (09:35 +0100)]
[gdb/testsuite] Fix timeout in gdb.base/async-shell.exp
For test-case gdb.base/async-shell.exp, I usually get:
...
(gdb) run &^M
Starting program: async-shell ^M
(gdb) PASS: $exp: run &
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
shell echo foo^M
foo^M
(gdb) PASS: $exp: shell echo foo
...
And with taskset -c 11, I get instead:
...
(gdb) run &^M
Starting program: async-shell ^M
(gdb) PASS: $exp: run &
shell echo foo^M
foo^M
(gdb) PASS: $exp: shell echo foo
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
...
With a gdb 16.3 based package I ran into:
...
(gdb) run &
Starting program: async-shell
(gdb) PASS: $exp: run &
shell echo foo
foo
(gdb) [Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
FAIL: $exp: shell echo foo (timeout)
...
I have tried to reproduce this using various timing tricks, but haven't
managed. Nevertheless, I believe this can reproduced with trunk, so fix this
using -no-prompt-anchor.
Jan Beulich [Fri, 12 Dec 2025 07:06:41 +0000 (08:06 +0100)]
RISC-V: avoid ld crashes due to bogus use by testcases
Specifying a little-endian emulation isn't very helpful when the target is
big-endian (and hence gas defaults to that). Surely the linker better
wouldn't crash when invoked like this, but making sure of this isn't the
purpose of any of these tests (afaict). Make assembly output match linker
options.
With this the ld testsuite completes successfully for me. binutils and gas
testsuites still have issues.
Jan Beulich [Fri, 12 Dec 2025 07:04:41 +0000 (08:04 +0100)]
gas/macro: drop ISSEP()
I've been irritated by it more than once: It very obviously doesn't cover
all separators, hence resulting in inconsistent behavior. Nor do both use
sites look to really want the same set of separators. In macro_expand() we
really can pull the get_token() call ahead. If we don't find the expected
'=' we can simply continue parsing from the original position.
The use in get_any_string() is dead code afaict, inherited from gasp. The
sole leftover thereof is handled in the scrubber (see H_TICK_HEX,
LEX_IS_H, and alike there). With that dropped, ISBASE() also can be.
Jan Beulich [Fri, 12 Dec 2025 07:02:33 +0000 (08:02 +0100)]
ld/ELF: correct tidying of sec64k object files
These consume quite a bit of space (especially noticeable during batch
testing), but are rather mechanical to (re)create. In 2.28, when the
object file names used were changed (from dump<N>.o to names derived from
source file names), the tidying code wasn't updated (and hence lost its
effect).
Jan Beulich [Fri, 12 Dec 2025 07:02:12 +0000 (08:02 +0100)]
ld/ELF: leave note sections alone for relocatable linking
Commit 023e60ced0c8 ("ld: Move note sections after .rodata section") had a
rather undesirable effect for relocatable links (which typically wouldn't
use a custom linker script): .note.GNU-stack, which isn't even a proper
notes sections (it's SHT_PROGBITS instead, which likely will want
correcting independently), would be moved immediately past .text and
.rodata (and alike), ahead of any custom notes sections. A later final
link, possibly simply combining all .note and .note.* sections, would then
find .note.GNU-stack first, resulting in the output section to also become
SHT_PROGBITS. This way consumers looking for SHT_NOTE wouldn't find the
data they're after.
The goal of mentioning some known .note.* in the linker scripts is to
avoid orphan section diagnostics. That's not typically of interest for
relocatable links, though (people caring about this will want to have
custom scripts anyway, much like they may need to if they had any custom
.note.* sections). Therefore suppress that part of the linker script for
relocatable links.
Jan Beulich [Fri, 12 Dec 2025 07:01:53 +0000 (08:01 +0100)]
ld/Linux: determine program name in a more reliable manner
What argv[0] holds can be pretty arbitrary. As long as it's used for just
diagnostics, that may be pretty okay to go from, but ld also uses it to
find linker scripts. For that we want to be sure we start from the real
executable name. Which on Linux we can determine from the /proc/self/exe
symbolic link target (provided of course procfs is mounted).
Tom de Vries [Thu, 11 Dec 2025 21:38:30 +0000 (22:38 +0100)]
[pre-commit] Add pre-commit setup check
I wrote a patch and accidentally introduced a typo in the commit message.
This didn't get detected because codespell-log didn't run.
I installed pre-commit on that setup a while back, before codespell-log was
around and consequently only the .git/hooks/pre-commit script was installed.
This is a bit hard to notice given that all other hooks do run.
Add a pre-commit check that checks for this situation:
...
$ rm .git/hooks/commit-msg
$ git commit --amend
...
pre-commit-setup........................................................Failed
- hook id: pre-commit-setup
- exit code: 1
missing hook: .git/hooks/commit-msg (please run pre-commit install)
...
$
...
This is a bit niche, but worthwhile if you're using a dozen build and test
installations.
Tom de Vries [Thu, 11 Dec 2025 21:31:49 +0000 (22:31 +0100)]
[gdb/testsuite] Add tclint-plugin.py
Tclint v0.6.2 adds the possibility to specify a dynamic plugin using:
...
$ tclint --commands tclint-plugin.py
...
Update the pre-commit tclint version to v0.6.2, and add a plugin
gdb/testsuite/tclint-plugin.py.
The new plugin informs tclint about procs like proc_with_prefix which have a
script-type parameter, making tclint check the body of proc foo:
...
proc_with_prefix foo {} {
...
}
...
Declaring proc_with_prefix a builtin command makes tclint issue a
redefined-builtin for the definition of proc_with_prefix. Fix this by adding
"tclint-disable redefined-builtin" at the start of each file containing such
procs.
The plugin is not complete. Most entries were found by grepping for something
like "proc.*body".
The hope is that eventually we get to a situation where we can drop the
plugin and instead annotate like this [1]:
...
# tclint-args: name: any, arguments: any, body: script
proc proc_with_prefix { name arguments body } {
...
}
...
One fix in the testsuite, in test-case gdb.python/py-missing-objfile.exp.
Jan Vrany [Thu, 11 Dec 2025 16:21:51 +0000 (16:21 +0000)]
gdb/testsuite: use with_timeout_factor in huge.exp testcases
I occasionally run GDB testsuite on sluggish targets that need higher
timeout. The usual remedy I use is to set timeout to higher value in
site.exp.
This does not help with gdb.fortran/huge.exp, gdb.base/huge.exp and
gdb.ada/huge.exp, which set the timeout to fixed value of 30,
regardless of whether the timeout has been increased or not, causing
them to fail on some of my machines.
This commit fixes the problem by using with_timeout_factor.
Tom Tromey [Wed, 10 Dec 2025 14:23:37 +0000 (07:23 -0700)]
Fix "unset local-environment" when clearenv not available
Tom de Vries pointed out that clearenv isn't available on all hosts.
Since this seems like a niche command at best, it seemed fine to
disable this command on such platforms.
Rainer Orth [Thu, 11 Dec 2025 13:43:16 +0000 (14:43 +0100)]
Cleanup bfd target vectors and ld emulations on Solaris
This patch is a major cleanup of the Solaris configurations of both bfd and ld.
The Solaris cases in both bfd/config.bfd and ld/configure.tgt have seen a
major cleanup, making the support for various Solaris versions explicit,
correcting several inconsistencies, and making it easier to remove support
for some versions in the future.
* All 32-bit-only configurations (Solaris < 7 on SPARC, Solaris < 10 on
x86) only include the 32-bit target vectors and linker emulations.
* For 32-bit-default targets on 64-bit systems (Solaris >= 7 on SPARC,
Solaris >= 10 on x86), the 32-bit target vectors and linker emulations
are the default while supporting the 64-bit ones.
* For 64-bit-default targets on 64-bit systems, it's the other way round.
They default to 64-bit target vectors etc. while also supporting the
32-bit ones.
* Added a warning to all Solaris cases in config.bfd not to include the
non-*_sol2 vectors to avoid the ambiguity reported in PR binutils/27666.
* On x86, the iamcu target vectors and linker emulations have been
removed: Solaris never supported the Intel MCU.
* On x86, the PE and PEI target vectors have been removed: they were only
supported in binutils proper. Their only use would be on EFI files
e.g. in GRUB, which doesn't justify their inclusion.
* With iamcu support gone, a few gas tests had to be disabled as on
VxWorks.
* The 32-bit Solaris/x86 ld configuration currently includes the
elf_i386_ldso emulation, which was never a emulation in its own right but
just an implementation detail of the elf_i386_sol2 emulation. Instead,
the settings that are not already provided by sourced .sh files are moved
into elf_i386_sol2.sh. Many settings became superfluous by just sourcing
elf_i386.sh as is already done in elf_x86_64_sol2.sh, massively
simplifying the emulation.
* Solaris-specific settings in generic emulparams scripts have been moved
to the *_sol2.sh files.
* NATIVE_LIB_DIRS in ld/configure.tgt now uses the default setting:
/usr/ccs/lib contains just a bunch of symlinks into /usr/lib at least
since Solaris 8.
* ld/emulparams/solaris2.sh now sets ELF_INTERPRETER_NAME to
/usr/lib/amd64/ld.so.1, matching both the native linker and
elf_i386_sol2.sh.
* The SEARCH_DIR statements in linker scripts on 64-bit targets contained
both the native (64-bit) and non-default (32-bit) directies. The latter
are completely pointless and are omitted using a new
LIBPATH_SKIP_NONNATIVE setting.
Tested on {amd64,i386}-pc-solaris2.11 and {sparcv9,sparc}-sun-solaris2.11,
and {x86_64,i686}-pc-linux-gnu as well as with gcc trunk bootstraps on the
Solaris targets. On those, I've compared the gas/ld and gas/gld 2.45.50
testresults with 2.45 ones.
projects / thirdparty / binutils-gdb.git / log
