the target is set to "plugin" if BFD supports plugin when the target
isn't specified nor default. Update strip to check the input target,
instead of the target_defaulted field in input BFD.
PR binutils/33230
* objcopy.c (copy_object): Add a bool argument, target_defaulted,
to indicate if the input target isn't specified nor default.
Check it instead of ibfd->target_defaulted.
(copy_archive): Add a bool argument, target_defaulted, and pass
it to copy_object.
(copy_file): Set target_defaulted to true if the input target
isn't specified and pass it to copy_archive and copy_object.
* testsuite/binutils-all/x86-64/pr33230.obj.bz2: New file.
* testsuite/binutils-all/x86-64/x86-64.exp: Run PR binutils/33230
tests.
Alan Modra [Tue, 29 Jul 2025 22:48:19 +0000 (08:18 +0930)]
PR 33229 nds32 gas segfaults on gcc output
Commit 1ac26e9f7ac2 replaced ISSPACE with is_whitespace, but the
former returns true on EOL while the latter does not. Sprinkle
is_end_of_stmt tests to fix this bug.
The same segfault can be triggered by a ".relax_hint" with no
following instructions. Fix that too.
* config/tc-nds32.c (nds32_lookup_pseudo_opcode): Use
is_end_of_stmt along with is_whitespace.
(nds32_relax_relocs, nds32_relax_hint, nds32_flag),
(ict_model: Likewise.
(nds32_elf_append_relax_relocs): Return on no opcode.
* testsuite/gas/nds32/nds32.exp: Find .d files automatically.
* testsuite/gas/nds32/pr33229.d,
* testsuite/gas/nds32/pr33229.s: New test.
Alan Modra [Tue, 29 Jul 2025 01:16:04 +0000 (10:46 +0930)]
ppc _bfd_clear_contents
ppc32 isn't susceptible to the PR33223 segfault, but could hit a
_bfd_clear_contents segfault with a carefully crafted invalid object.
* elf32-ppc.c (ARRAY_SIZE): Define.
(ppc_elf_howto_init): Use ARRAY_SIZE.
(ppc_elf_reloc_name_lookup): Likewise.
(ppc_elf_info_to_howto): Likewise, and consolidate error
handling.
(ppc_elf_check_relocs): Guard against segfaults caused by a NULL
howto passed to _bfd_clear_contents. Use ARRAY_SIZE.
ld: testsuite: Enable ld-elfweak tests on Solaris/x86
The ld-elfweak tests are currently only enabled on Solaris/SPARC for no
apparent reason. Enabling them on Solaris in general lets them all PASS
on both amd64-pc-solaris2.11 and i386-pc-solaris2.11.
ld: testsuite: Fix "PR ld/28138 (build only)" on Solaris
The
FAIL: PR ld/28138 (build only)
test FAILs on Solaris:
ld/tmpdir/ld/collect-ld: plugin framework: out of file descriptors. Try using fewer objects/archives
ld/tmpdir/ld/collect-ld: cannot find -lgcc: Too many open files
[...]
I found that the test PASSes when using ulimit -n 21 instead of the
current 20. Looking with strace/truss, on Linux/i686 the following
files are opened:
The test uses .symver, resulting in versioned symbols which the Solaris
ld.so.1 doesn't support and never will. Running it with LD_DEBUG=all
shows
26493: 1: symbol=foo; lookup in file=tmpdir/pr19553c [ ELF ]
26493: 1: symbol=foo; lookup in file=tmpdir/libpr19553c.so [ ELF ]
26493: 1: symbol=foo; skipping entry in file=tmpdir/libpr19553c.so, index[7], version=FOO, due to GNU version hidden bit
26493: 1: symbol=foo; continuing lookup in file=tmpdir/libpr19553c.so [ ELF ]
26493: 1: symbol=foo; lookup in file=tmpdir/libpr19553b.so [ ELF ]
26493: 1: binding file=tmpdir/pr19553c to file=tmpdir/libpr19553b.so: symbol 'foo'
Tom Tromey [Mon, 28 Jul 2025 13:17:09 +0000 (07:17 -0600)]
Avoid timeouts with gnat-llvm in gdb.ada/operator_call.exp
While working on gnat-llvm, gdb.ada/operator_call.exp has many
timeouts. This happens because gnat-llvm's DWARF output is still
incomplete, and so gdb emits an unexpected error in this test.
This patch improves the test by having it recognize this output and
issue a failure rather than a timeout. This greatly speeds up
testing.
Nick Alcock [Wed, 23 Jul 2025 13:20:26 +0000 (14:20 +0100)]
libctf: link: rejig lazy opening to not need weak symbols
The ctf_link_add_ctf API function has a 'lazy opening' feature whereby,
if you pass in the file but not a CTF archive, the archive is opened
as late as possible during links. This is valuable mostly in
cu-mapped links (a feature not accessible via GNU ld), where it
ensures that, rather than eventually needing memory for the original
link inputs, the smushed-together cu-mapped intermediate outputs,
*and* the final output, we only need enough memory for the smushed-
together outputs, the final output, and one input, since the inputs
can be closed immediately after they are smushed together.
(In GNU ld, the feature is useless because it loads all sections into
memory anyway.)
The lazy-opening feature uses libctf's ctf_open function, which uses
BFD: so it is not available in libctf-nobfd -- except that I thought I
had a cunning trick, and used a weak symbol so that if you linked
libctf-nobfd into your program and then also linked in bfd, the feature
stayed enabled.
This is silly -- if your program is licensed such that you can link in
BFD, you can just link in libctf.so and not bother with libctf-nobfd.so
in the first place. Worse, the weak symbol usage broke MacOS builds,
since MacOS's system compiler uses a different means of introducing weak
symbols. We could test for and use it, but this is the only place in
libctf to use weak symbols at all, and the feature of lazy-opening with
libctf-nobfd is so marginal we might as well drop it: it's almost
certain there are zero users, certainly fewer users than users of MacOS
with the system compiler.
While we're at it, simplify things by deleting the never-implemented
feature (not exposed in the API) to allow linking together raw buffers
of CTF data. If we need it we can bring it back, but all it's doing
right now is complicating the code to no end at all.
libctf/
PR libctf/33194
* ctf-link.c (ctf_open): Delete weak pragma.
(ctf_link_add): Fuse with...
(ctf_link_add_ctf): ... this function. Drop BUF, N args
and corresponding unimplemented feature warnings. Only check
NOBFD to see whether lazy loading is available, not PIC as
well.
(ctf_link_lazy_open): Likewise.
Matthieu Longo [Mon, 14 Jul 2025 14:18:02 +0000 (15:18 +0100)]
gas: add missing header guard in tc-<arch>.h files
This patch adds missing header guards in some of the tc-<arch>.h,
and merely comments on the corresponding #endif for others. The
patch does not aim at being exhaustive, it only touched the files
relevant for [1].
With the changes of an added flag SFRAME_F_FDE_FUNC_START_PCREL, s390x
support and new section type SHT_GNU_SFRAME, indicate that this document
specifies the errata 1 of SFrame version 2. This will help distinguish
the document / specification better from previous releases.
libsframe/doc/
* sframe-spec.texi: Mention errata 1 of SFrame version 2.
Tom de Vries [Fri, 25 Jul 2025 17:07:59 +0000 (19:07 +0200)]
[gdb/tui] Fix shell command terminal settings
In bash I have the following terminal settings:
...
$ stty
speed 38400 baud; line = 0;
-brkint -imaxbel iutf8
...
and then in gdb using the shell command likewise:
...
(gdb) shell stty
speed 38400 baud; line = 0;
-brkint -imaxbel iutf8
(gdb)
...
and likewise using a shell session:
...
(gdb) shell
$ stty
speed 38400 baud; line = 0;
-brkint -imaxbel iutf8
$
...
But in TUI, we get different settings (removed runaway indentation for
readability):
...
(gdb) shell sttyspeed 38400 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel iutf8
-onlcr
-icanon -echo
(gdb)
...
and consequently the shell is not really usable. This is PR tui/18215.
The easiest way to fix this is to just temporarily leave TUI while in the shell,
leaving the output of the commands in CLI mode, but that's a bit confusing.
Fix this (as suggested in the PR) by restoring the initial terminal settings
while in the shell command, such that also in TUI we have:
...
(gdb) shell sttyspeed 38400 baud; line = 0;
-brkint -imaxbel iutf8
(gdb)
...
Tested on x86_64-linux.
Reported-By: Doug Evans <dje@google.com> Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18215
gdb: use the location_completer for the list command
The "location_completer" function has been available for a long time,
but it was seemingly never used as the completer for the list function.
A quick check through git history shows that a similar completer was
available for the "edit" command but wasn't added to "list" with no
reasoning for it.
I think "list" should use the location_completer, as it is more aware of
the locspec grammar.
Simon Marchi [Tue, 8 Jul 2025 19:52:37 +0000 (15:52 -0400)]
gdb/dwarf: apply DW_AT_bit_offset when DW_AT_data_member_location is constant block
Since commit 420d030e88 ("Handle field with dynamic bit offset"), I see:
$ make check TESTS="gdb.trace/unavailable-dwarf-piece.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d x
FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d y
FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d z
The first FAIL is:
p/d x
$4 = {a = 0, b = <unavailable>, c = <unavailable>, d = <unavailable>, e = <unavailable>, f = <unavailable>, g = <unavailable>, h = <unavailable>, i = <unavailable>, j = 0}
(gdb) FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d x
When we should see:
p/d x
$4 = {a = 0, b = <unavailable>, c = 0, d = 0, e = 0, f = 0, g = 0, h = 0, i = 0, j = 0}
(gdb) PASS: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d x
The particularity of field "b" (and the following ones, not shown here)
is that they have:
- a DW_AT_data_member_location of expression form, but that GDB reduces
to a constant
- a DW_AT_bit_offset
What I think happens is that the code path taken in this particular
scenario never ends up using the DW_AT_bit_offset value. Fix it by
calling apply_bit_offset_to_field, like what is done when
data_member_location_attr is using a constant form.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33136
Change-Id: I18e838e6c56a548495d3af332aeff3051188eaa9 Approved-By: Tom Tromey <tom@tromey.com>
Fix PR gas/33175 sframe: --gsframe=no does not disable when
.cfi_sections directive with .sframe
--gsframe=no should also disable generation of SFrame section when
explicit CFI directive:
.cfi_sections .sframe
is specified in the input. This means we need to track whether SFrame
generation was explicitly disabled by the user. Introduce a new enum to
facilitate disambiguation between GEN_SFRAME_DEFAULT_NONE and
GEN_SFRAME_DISABLED.
While fixing the bug by adding the enum, keep the upcoming requirement
in mind: we will also need to disambiguate between
--enable-default-sframe and user-specified --gsframe/--gsframe=yes. The
intent is to not display SFrame related warnings or errors like:
as_bad (_(".sframe not supported for target"));
for unsupported targets if --enable-default-sframe is in effect.
This implies we need to have a four state enum (
GEN_SFRAME_DEFAULT_NONE, GEN_SFRAME_CONFIG_ENABLED,
GEN_SFRAME_DISABLED, GEN_SFRAME_ENABLED)
gas/
PR gas/33175
* dw2gencfi.c (cfi_finish): Check state of flag_gen_sframe to
determine whether any SFrame section is generated.
* as.h (enum gen_sframe_option): New definition.
* as.c (parse_args): Keep track of whether the flag is
explicitly enabled or disabled
gas/testsuite/
PR gas/33175
* gas/cfi-sframe/cfi-sframe-common-1.d: Remove redundant
--gsframe.
* gas/cfi-sframe/cfi-sframe.exp: Add new test.
* gas/cfi-sframe/cfi-sframe-common-1c.d: New test. No SFrame
section if explicit --gsframe=no.
* gas/cfi-sframe/cfi-sframe-common-1c.s: New test.
readelf: objdump: sframe: fix dumping with section name
Fix PR binutils/33186 - No SFrame dump if section name is not .sframe
When the section name is not ".sframe", ensure that readelf and objdump
are able to dump a section of type SHT_GNU_SFRAME and not fail if the
user specifies the new section name.
For objdump, in dump_dwarf_section (), use the match string of ".sframe"
to find the corresponding debug_displays[] item for SFrame section.
Doing this ensures that any call to dump_dwarf_section () with the
section pointing to the SFrame section (with name possibly different
from ".sframe") will successfully dump the SFrame section.
If the SFrame section is named anything but ".sframe", and user does not
specify the name of the SFrame section either, the documented behaviour
is that the default section name is assumed to be ".sframe". So the
following (albeit counter intuitive) is expected at this time:
For objdump, set dump_sframe_section_name to ".sframe" if user specifies
no section name. In the error checking done in dump_sframe_section, add
the case when user specifies a valid section name but one that does not
contain SFrame section data. For sections generated with Binutils >=
2.45, this can be checked with section type of SHT_GNU_SFRAME.
Previously these sections were SHT_PROGBITS with name ".sframe".
Similar changes in readelf.
Add a test each for objdump and readelf to dump a renamed section. Use
gas_sframe_check to limit the execution of these tests only when a gas
supporting SFrame format is present.
binutils/
PR binutils/33186
* objdump.c (dump_dwarf_section): Set match to ".sframe" which
corresponds to the name in the debug_displays[] entry for
SFrame section.
(dump_sframe_section): Check if the user specified section name
contains SFrame data.
(main): Set default section name to ".sframe".
* readelf.c (display_debug_section): Adjust checks to find the
debug_diplays[] item for the input arg SFrame section.
Use id instead of i, as it is more readable.
binutils/testsuite/
PR binutils/33186
* binutils-all/x86-64/objdump-sframe-01.d: New test.
* binutils-all/x86-64/readelf-sframe-01.d: New test.
* binutils-all/x86-64/sframe-func.s: New test.
ld: Force SHELL=/bin/bash in ld for Solaris [PR32580]
As described in PR ld/32580, when using SHELL=/bin/sh or /bin/ksh on
Solaris, the generated linker scripts get corrupted. So far, the only
workaround is to enforce /bin/bash instead.
This is a major nuisance for developers and users alike, so this patch
automates this by overriding SHELL in ld/configure.ac.
Tested on amd64-pc-solaris2.11 in three configurations:
* CONFIG_SHELL unset
* CONFIG_SHELL=/bin/ksh
* CONFIG_SHELL='/bin/bash --norc'
In the first two cases, SHELL was set to /bin/bash as desired, while in
the third it was left unchanged.
added "-R .gnu.lto_.*" to strip to remove all GCC LTO sections. When
"-R .gnu.lto_.*" is used, the plugin target is ignored so that all LTO
sections are stripped as the regular sections. It works for the slim
GCC LTO IR since the GCC LTO IR is stored in the regular sections. When
the plugin target is ignored, the GCC LTO IR can be recognized as the
normal object files. But it doesn't work for the slim LLVM IR which
is stored in a standalone file.
1. Add bfd_check_format_matches_lto and bfd_check_format_lto to take an
argument, lto_sections_removed, to indicate if all LTO sections should
be removed.
2. Update strip to always enable the plugin target so that the plugin
target is enabled when checking for bfd_archive.
3. Update strip to ignore the plugin target for bfd_object when all LTO
sections should be removed. If the object is unknown, copy it as an
unknown file without any messages.
4. Treat the "-R .llvm.lto" strip option as removing all LTO sections.
bfd/
PR binutils/33198
* format.c (bfd_check_format_lto): New function.
(bfd_check_format): Call bfd_check_format_matches_lto.
(bfd_check_format_matches): Renamed to ...
(bfd_check_format_matches_lto): This. Add an argument,
lto_sections_removed, to indicate if all LTO sections should be
removed and don't match the plugin target if lto_sections_removed
is true.
(bfd_check_format_matches): Call bfd_check_format_matches_lto.
* bfd-in2.h: Regenerated.
binutils/
PR binutils/33198
* objcopy.c (copy_archive): Call bfd_check_format_lto, instead
of bfd_check_format, and pass lto_sections_removed. Remove the
non-fatal message on unknown element since it will be copied as
an unknown file.
(copy_file): Don't check lto_sections_removed when enabling LTO
plugin in strip.
(copy_file): Ignore the plugin target first if all LTO sections
should be removed. Try with the plugin target next if ignoring
the plugin target failed to match the format.
(strip_main): Also set lto_sections_removed for -R .llvm.lto.
* testsuite/binutils-all/x86-64/pr33198.c: New file.
* testsuite/binutils-all/x86-64/x86-64.exp (run_pr33198_test):
New.
Run binutils/33198 tests.
* testsuite/lib/binutils-common.exp (llvm_plug_opt): New.
(CLANG_FOR_TARGET): New. Set to "clang" for native build if
"clang -v" reports "clang version".
Tom de Vries [Thu, 24 Jul 2025 10:06:40 +0000 (12:06 +0200)]
[gdb/testsuite] Add Term::get_string_with_attrs in tuiterm
While reading a gdb.log for test-case gdb.tui/main-2.exp, I noticed that this
line was somewhat hard to read:
...
screen line 6: '<fg:cyan><intensity:bold>|<fg:default><intensity:normal>B+> 21 <reverse:1> return 0;<reverse:0> <fg:cyan><intensity:bold>|<fg:default><intensity:normal>'
...
because of the border attributes.
Then I realized that the test-case is only interested in the text between the
borders, so I added a proc Term::get_string_with_attrs that allows me to drop
the borders, getting us instead:
...
screen line 6: 'B+> 21 <reverse:1> return 0;<reverse:0> '
...
Tom de Vries [Thu, 24 Jul 2025 09:48:29 +0000 (11:48 +0200)]
[gdb/testsuite] Use TERM=ansiw in tuiterm for bsd
TERM=ansi is different on freebsd and linux. Consequently, many TUI
test-cases (gdb.tui/*.exp and gdb.python/tui*.exp) fail on freebsd.
One of the problems is that send_gdb "<cmd>\r\n" is needed instead of
send_gdb "<cmd>\n".
This is because gdb_send "layout regs\n" translates to
"layout regs<KEY_DOWN>", which evidently missing the carriage return part.
While we can work around this, there are other problems. There is no color
support, and the cursor keys fail to scroll the source window.
So I went looking for an alternative to TERM=ansi on freebsd, and came across
TERM=ansiw. Using this didn't work out of the box, but with the fixes in
this series it now does.
I also briefly looked at TERM=ansis, which is interesting because it's
available on both linux and freebsd, but ansiw is a better choice for now.
I've filed PR33179 to document what I learned, with the aim to eventually
follow up and address two test-case failures with TERM=ansis on linux.
Tom de Vries [Thu, 24 Jul 2025 07:18:57 +0000 (09:18 +0200)]
[gdb/testsuite] Log on return in Term::_log_cur
Proc Term::_log_cur logs the cursor update of code in its body argument:
...
proc _ctl_0x08 {} {
_log_cur "Backspace" {
variable _cur_col
if {$_cur_col > 0} {
incr _cur_col -1
}
}
}
...
giving us for instance:
...
+++ Backspace, cursor: (2, 0) -> (2, 0)
...
But if we rewrite the code to use a return:
...
if { $_cur_col == 0 } {
return
}
incr _cur_col -1
...
and the return is triggered, the log message disappears.
Fix this by wrapping the "uplevel $body" in a catch:
...
- uplevel $body
+ set code [catch {uplevel $body} result]
...
Pietro Monteiro [Wed, 23 Jul 2025 23:49:50 +0000 (19:49 -0400)]
gold: configury: fix obsolete macros
Running `autoreconf -vf -Wall' in the gold directory shows errors about the use
of obsolete macros. This patch fix the issues with macros used directly by
configure.ac. However, it doesn't fix all warnings. There are autoconf warnings
about macros from files in config and one automake warning about a target being
shadowed. It cuts a lot of the noise down and makes an upgrade to autoconf
2.71+ easier.
Tom de Vries [Wed, 23 Jul 2025 19:11:41 +0000 (21:11 +0200)]
[gdb/testsuite] Handle auto_left_margin in tuiterm
The terminal capability bw (aka as auto_left_margin) controls whether a
backspace at the start of a line wraps to the last column of the previous
line.
For tuiterm, we use TERM=ansi, and on linux at least that capability is off.
Consequently the current implementation of Term::_ctl_0x08 doesn't wrap.
Add this capability in Term::_ctl_0x08, and add a unit test.
Simon Marchi [Wed, 23 Jul 2025 18:41:42 +0000 (14:41 -0400)]
gdbserver: use reference in range for loop
The armhf buildbot fails to build GDB, with:
../../binutils-gdb/gdbserver/server.cc: In function ‘void handle_general_set(char*)’:
../../binutils-gdb/gdbserver/server.cc:1021:23: error: loop variable ‘<structured bindings>’ creates a copy from type ‘const std::pair<thread_info*, enum_flags<gdb_thread_option> >’ [-Werror=range-loop-construct]
1021 | for (const auto [thread, options] : set_options)
| ^~~~~~~~~~~~~~~~~
../../binutils-gdb/gdbserver/server.cc:1021:23: note: use reference type to prevent copying
1021 | for (const auto [thread, options] : set_options)
| ^~~~~~~~~~~~~~~~~
| &
I did not use a reference on purpose, because the pair is very small. I
don't see the problem when building on amd64, I presume it is because
the pair is considered too big to copy on a 32-bit architecture, but not
on a 64-bit architecture.
Simon Marchi [Wed, 9 Jul 2025 13:17:50 +0000 (09:17 -0400)]
gdb, gdbserver: use structured bindings in a few places
I wanted to change one of these, so I searched for more similar
instances, while at it. I think this looks a bit tidier, over unpacking
the pairs by hand.
Change-Id: Ife4b678f7a6aed01803434197c564d2ab93532a7 Approved-By: Tom Tromey <tom@tromey.com>
Alan Modra [Wed, 23 Jul 2025 12:22:31 +0000 (21:52 +0930)]
PR 33197 [AVR] Incorrect syntax in generated ldscript
Rearrange scripttempl/avr.sc to avoid oddities of shells expanding
${RELOCATING+stuff} in here documents where "stuff" contains quoted
strings. Also I think it is better to avoid multi-line "stuff" as it
can be tricky to spot the ending brace.
Nick Alcock [Thu, 17 Jul 2025 16:45:02 +0000 (17:45 +0100)]
libctf: don't run tests requiring deduplicating linker unless one is in use
Before now, we were relying on gcc -B to repoint GCC at our freshly-built
linker, and assuming we could use this to run tests that do linker dedup.
This is, alas, not reliable (building --with-ld=/an/absolute/path bypasses
-B searches for the linker), and we would like the libctf tests in
particular to not fail if the compiler uses a linker that cannot deduplicate
(simply skipping such tests).
Add a new testsuite function that tries to link one of the lookup tests'
testcases (which is known to produce conflicting types, i.e. a dict with
per-translation-unit children) and then does an objdump and greps it for
signs of the per-translation-unit children. If there are none, the linker
probably just concatenated the sections: i.e., it is not a linker that
can deduplicate CTF.
libctf: exclude always-emitted Solaris symbols from the symtypetab
If we're skipping _BEGIN_ and _END_ we should certainly skip all the other
ABI-required always-emitted symbols given in ld/emultempl/solaris2*em as
well. (This fixes a couple of diagnostics tests, but that's just because
the tests are quite sensitive to CTF section sizes, and introducing any
symtypetab entries for those tests perturbs those.)
Some of these are usually STT_NOTYPE, but not always: if programs already
emitted the symbol they might end up with any type, in particular
STT_OBJECT, and appear in the symtypetabs.
[nca: added commit log, added more symbols]
libctf/
PR libctf/33162
* ctf-serialize.c (ctf_symtab_skippable): Skip
more always-emitted Solaris symbols.
Nick Alcock [Wed, 16 Jul 2025 13:43:25 +0000 (14:43 +0100)]
libctf: get libctf-nobfd.ver from the right place with Solaris ld
We generate de-commented version scripts for Solaris ld (whose
-z gnu-version-script linker option does not support comments),
but after we switched to generating libctf-nobfd.ver itself, we
failed to adjust this code to pick it up from the new location.
Writable mmaps and read are inconsistent with each other on Solaris 11.4,
which breaks archive writing. Simply assert that Solaris 2.11 doesn't have
mmap, falling back to read(): the archive format is being bumped shortly, to
one with completely different writeout code, so this workaround need not
stay for long.
[nca: added commit log]
libctf/
PR libctf/29292
* configure.ac: Turn off mmap on Solaris 2.11.
* configure: Regenerated.
SFrame generation code assumes that since DW_CFA_restore means
restoration of the state of the register to the one at the beginning of
the function, there must be a state to restore to (hence the gas_assert
(cie_fre)).
This assumption needs adjustment. DW_CFA_restore may be present in the
very beginning of a (e.g., cold) function, with no initialized state for
SFrame functions to restore to.
gas/
PR gas/33170
* gas/gen-sframe.c (sframe_xlate_do_restore): Use current FRE if
CIE FRE is not yet setup.
gas/testsuite/
PR gas/33170
* gas/cfi-sframe/cfi-sframe.exp: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-pr33170.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-pr33170.s: New test.
Tom de Vries [Tue, 22 Jul 2025 20:26:05 +0000 (22:26 +0200)]
[gdb/cli] Clear line buffer on ^C
Gdb has the ability to gather input over several lines [1], for instance this:
...
(gdb) print 1
$1 = 1
(gdb)
...
can also be typed as:
...
(gdb) print\
1
$2 = 1
(gdb)
...
Furthermore, if we type a command but change our mind, we can abort using ^C
and start over using a fresh gdb prompt [2]:
...
(gdb) print 1❌️ Quit
(gdb) echo 1\n
1
(gdb)
...
Now say we type a multi-line command but abort it, we get:
...
(gdb) print\
1❌️ Quit
(gdb) echo 1\n
❌️ Undefined command: "printecho". Try "help".
(gdb)
...
Using "set trace-commands on", we can see what happened:
...
+printecho 1\n
..
Gdb has prepended the first line of the cancelled multi-line command to the
following command.
Fix this by clearing current_ui->line_buffer on catching a gdb_exception in
start_event_loop.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR cli/33063
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33063
gdb: Remove redundant parameter for filename completion
As I was working on an unrelated patch, I noticed that all calls to
make_source_files_completion_list had both parameters of the function
call being the same pointer. I think we can remove that redundancy and
make that call with just one parameter.
ld: Rename a file on Windows fails if target already exists
To rename a file on Windows, the target name cannot exist. Removing file
prior to renaming ensures this is handled.
To remove a file on Windows, the file cannot be open. Closing the bfd
handle ensures this is handled.
Moved call to free on isympp / osympp to after bfd is closed to align
with comment earlier in the cmdline_add_object_only_section function.
Running the standalone test `gdb.reverse` with the target board configuration `unix/-fPIE/-pie` leads to the following failure:
'''
FAIL: gdb.reverse/i386-avx-reverse.exp: verify ymm15 before vbroadcastsd
'''
This happens because the test expects values stored in `dyn_buf0`, but instead (in the test source) the address of the buffer itself
got broadcast to xmm15 (and thus to ymm15).
This happened because the pointer to the start of `dyn_buf0` wasn't dereferenced (see 'vpbroadcast_test' in 'i386-avx-reverse.c'):
'''
asm volatile ("vbroadcastss %0, %%xmm15": : "m" (dyn_buf0));
^
'''
and this consequently lead to the test failing for the next instruction (`vbroadcastsd`), which depended on the correct value being broadcast to the register.
Also, updated the corresponding expected output (gdb.reverse/i386-avx-reverse.exp) to match.
This happens when pie and the input sections, which refers to the global
symbol by got, are all discarded. Since referenced sections are all discarded,
we won't go into relocate_section for those sections, the got entry also won't
be initialized. Therefore, we will get assert fail when adding the RELATIVE
reloc in the finish_dynamic_symbol.
After seeing other target codes, there are two root causes as follows,
1. risc-v may call bfd_elf_link_record_dynamic_symbol in the allocate_dynrelocs
for not only undefweak symbols.
2. risc-v is missing the code to add RELATIVE to R_RISCV_GOT entries in the
relocate_section if a symbol is not dynamic and is not undefined weak under
pic and pie.
If we call bfd_elf_link_record_dynamic_symbol, then the global symbol will be
forced to dynamic, so the h->dynindx will forced to be a number rather than -1,
even it should be -1. Once h->dynindx != -1 and pic/pie, it will go into
finish_dynamic_symbol and insert RELATIVE/64 relocs for the got entry; For the
above case there are two issues,
1. The global symbol _start is forced to be dynamic in the allocate_dynrelocs.
when pie and all the referenced section are discarded, it won't go into
relocate_section to initialize the got entry, so it will cause assert fail
when adding RELATIVE reloc in the finish_dynamic_symbol. The assert fail
represents another problem - if we don't initialize the got entry in the
relocate_section under pie, which means we don't need to go into the
finish_dynamic_symbol and don't need a RELATIVE reloc for the got entry,
it should be NONE reloc.
2. Without linking any discarded section, it originally forces every RELATIVE
relocs added for every got by the finish_dynamic_symbol. Even The final
result looks correct under pie (genearte a RELATIVE reloc for got entry),
not sure if it may cause other problems for some special cases, excpet the
above one.
Therefore, this patch try to fix the above assert fail, and also clarify the
behavior of the allocate_dynrelocs which should only call bfd_elf_link_record_dynamic_symbol
for undefweak symbols, and add the missing code to generate RELATIVE reloc to
R_RISCV_GOT entries in the relocate_section if a symbol is not dynamic and is
not undefined weak under pic and pie.
Passed the gcc/binutils regressions of riscv-gnu-toolchain at least.
Richard Earnshaw [Mon, 21 Jul 2025 15:40:12 +0000 (16:40 +0100)]
aarch64: Use an enum to refer to indices in the opcode table
The indices into the auto-generated tables for opcodes are relatively
unstable. Adding a new opcode can permute the code significantly.
But most of this churn is down to changes in the index values. To
minimize this use enumerated constants. While the index values
change, the enumeration names will need to do so far less often, so
most of the changes in the generated code become localized to the
addition (occasionally removal) of opcodes. This change also makes
the state-change comments unnecessary. The enumeration names contain
the same information (and more), so these are simply deleted.
The enumeration values are placed in a new header file, aarch64-tbl-2.h,
so aarch64-gen gains a new option to build this header and the Makefile
rules are adjusted accordingly.
Richard Earnshaw [Mon, 14 Jul 2025 16:30:01 +0000 (17:30 +0100)]
aarch64: use an enumeration for operand indices.
The generated aarch64 operand tables use index values into an array. But if
the table of operands is modified by inserting a new operand into the middle
of the table, *all* the index values can change, leading to a lot of
churn in the generated output.
include/opcode/aarch64.h already provides an enumeration for the operands,
so make use of that instead of printing out the raw index values.
Richard Earnshaw [Tue, 15 Jul 2025 16:32:20 +0000 (17:32 +0100)]
aarch64: Fix operand name MOPS_WB_Rd -> MOPS_WB_Rn
This field was misnamed in aarch64_opcode_table. It previously didn't
matter too much as the name field only appeared in dumps. But it
doesn't match the enum in include/opcode/aarch64.h and we will shortly
start to rely on that.
These method declarations are unused, remove them. I guess that when
writing a previous patch, changed some free functions to be methods,
then changed my mind, and forgot to remove the declarations.
gprofng ignores functions that are compiled as weak symbols. This
heavily affects C++ class methods that are always compiled by g++
and clang++ as weak symbols. In this case 'gprofng display text'
just displays <static>@ADDRESS(<FILENAME>) instead of proper method
name.
The bug has been introduced in the commit 470a0288a818.
Tom de Vries [Sat, 19 Jul 2025 15:37:01 +0000 (17:37 +0200)]
[gdb/cli] Document \001 and \002 usage for set prompt
PR cli/28887 reports the following problem when using a custom prompt.
First, we set up the custom prompt (with ^ marking the position of the
blinking cursor on the line above):
...
$ gdb -q -ex "set prompt \033[31mgdb$ \033[0m"
gdb$
^
...
Then we type some string, and enter it into the command history:
...
gdb$ some long command
❌️ Undefined command: "some". Try "help".
gdb$
^
...
We use C-p to fetch the previous command:
...
gdb$ some long command
^
...
Sofar, so good.
Finally, we use C-a which should move the cursor to just after the prompt, but
instead we get:
...
gdb$ some long command
^
...
This is fixed by using \001 and \002:
...
(gdb) set prompt \001\033[31m\002gdb$ \001\033[0m\002
...
aka as RL_PROMPT_START_IGNORE and RL_PROMPT_END_IGNORE [1].
Add an example to the documentation showing the use of these markers.
The added example is the equivalent of the "\[\e[0;34m\](gdb)\[\e[0m\]"
example documented at gdb.prompt.substitute_string that can be used with
"set extended-prompt".
While working on this, I noticed that "show prompt" doesn't show back the
original string, using '\e' instead of '\033':
...
gdb$ show prompt
Gdb's prompt is "\001\e[31m\002gdb$ \001\e[0m\002".
...
and that the shown string can't be used as an argument to "set prompt":
...
gdb$ set prompt \001\e[31m\002gdb$ \001\e[0m\002
e[31mgdb$ e[0m
...
I've filed this as PR cli/33184.
Approved-By: Eli Zaretskii <eliz@gnu.org>
[1] https://tiswww.case.edu/php/chet/readline/readline.html
I noticed that the test names in test-case
gdb.base/backtrace-through-cu-nodebug.exp are a bit inconsistent:
...
PASS: $exp: no-cfi: maint frame-unwinder disable ARCH
PASS: $exp: verify no-filters unwind fail without CFI
PASS: $exp: maint flush register-cache
PASS: $exp: verify unwind fail without CFI
PASS: $exp: cfi: maint frame-unwinder disable ARCH
PASS: $exp: Verify unwinding works based only on CFI information
...
There's both a no-cfi prefix, and "without CFI".
Fix this by using proc_with_prefix, getting us a consistent prefix:
...
PASS: $exp: no-cfi: maint frame-unwinder disable ARCH
PASS: $exp: no-cfi: verify no-filters unwind fail
PASS: $exp: no-cfi: maint flush register-cache
PASS: $exp: no-cfi: verify unwind fail
PASS: $exp: cfi: maint frame-unwinder disable ARCH
PASS: $exp: cfi: Verify unwinding works
...
While we're at it, use multi_line to make a regexp more readable.
Tom de Vries [Sat, 19 Jul 2025 15:08:44 +0000 (17:08 +0200)]
[gdb/testsuite] Fix gdb.base/backtrace-through-cu-nodebug.exp without python support
With a gdb build without python support, and test-case
gdb.base/backtrace-through-cu-nodebug.exp I run into:
...
(gdb) bt^M
Required frame unwinder may have been disabled, \
see 'maint info frame-unwinders'^M
(gdb) FAIL: $exp: verify unwind fail without CFI
...
With a gdb build with python support we have instead:
...
(gdb) bt^M
Python Exception <class 'gdb.error'>: \
Required frame unwinder may have been disabled, \
see 'maint info frame-unwinders'^M
(gdb) PASS: $exp: verify unwind fail without CFI
...
but if I change the "bt" into "bt -no-filters" I get the same FAIL and
corresponding output.
So there are two scenarios here.
In the first:
- the bt command is called
- frame #0 is printed
- trying to get the next frame fails and an error is thrown, aborting the
backtrace
- the error is caught and printed
In the second:
- the bt command is called
- the frame filter is applied
- doing so triggers the same error, which is caught and printed by
gdbpy_apply_frame_filter, returning EXT_LANG_BT_NO_FILTERS
- frame #0 is printed
- getting the next frame fails, and the backtrace stops
It seems worthwhile to exercise both scenarios if possible, so add a
"bt -no-filters" test.
Fix the FAIL by updating the regexp to allow both scenarios.
Tom de Vries [Sat, 19 Jul 2025 15:08:44 +0000 (17:08 +0200)]
[gdb/testsuite] Fix gdb.multi/pending-bp.exp without python support
With a gdb build without python support and test-case
gdb.multi/pending-bp.exp, I run into:
...
(gdb) python bp=[b for b in gdb.breakpoints() if b.number == 5][0]^M
Python scripting is not supported in this copy of GDB.^M
(gdb) FAIL: $exp: py_test_toggle_thread: find Python gdb.Breakpoint object
...
Fix this by requiring python support for part of the test-case.
Tom de Vries [Sat, 19 Jul 2025 15:08:44 +0000 (17:08 +0200)]
[gdb/testsuite] Fix gdb.base/break-dbg.exp without xml support
With a gdb build without xml support and test-case gdb.base/break-dbg.exp, I
run into:
...
(gdb) catch syscall^M
warning: Can not parse XML syscalls information; \
XML support was disabled at compile time.^M
Catchpoint 11 (any syscall)^M
(gdb) FAIL: $exp: catch syscall
...
Alan Modra [Thu, 17 Jul 2025 23:56:10 +0000 (09:26 +0930)]
RELOC_AGAINST_DISCARDED_SECTION zero size reloc sections
For some reason the initial implementation (commit 0672748ac053) of
this macro didn't allow discarding of all relocs in a section, perhaps
because doing so would require a testsuite change. This patch allows
zero size relocation sections to result, and adjusts the testsuite.
i386, x86_64, ppc and ppc64 code that avoids a memmove is also changed
to allow zero size reloc sections, and arc fixed to actually adjust
the reloc section header.
Tom de Vries [Fri, 18 Jul 2025 17:51:46 +0000 (19:51 +0200)]
[gdb/testsuite] Fix gdb.arch/amd64-disp-step-self-call.exp on freebsd
On x86_64-freebsd, with test-case gdb.arch/amd64-disp-step-self-call.exp, I
run into:
...
(gdb) continue
Continuing.
Program received signal SIGBUS, Bus error.
Object-specific hardware error.
0x000000080051492c in alarm () from /lib/libc.so.7
(gdb) FAIL: $exp: continue to breakpoint: test_call
...
The behaviour is not specific to gdb, it can be reproduced by running the
test-case executable:
...
$ ./outputs/gdb.arch/amd64-disp-step-self-call/amd64-disp-step-self-call
Bus error (core dumped)
$
...
The bus error happens when executing this instruction in alarm:
... 0000000000093910 <alarm>:
...
9392c: 0f 29 45 d0 movaps %xmm0, -0x30(%rbp)
...
because $rbp is not 16-byte aligned.
This can be fixed by adding the missing frame setup instructions at the start
of main in amd64-disp-step-self-call.S:
...
main:
+ pushq %rbp
+ movq %rsp, %rbp
...
Instead, fix this by moving main from the assembly file to the c file, which
has the same effect.
Also remove the done label, which looks like a copy-past left-over. Instead,
add an unreachable function and use it where appropriate.
Do the same for i386 case (which makes the source files identical for the
amd64 and i386 case, but I decided to leave it like that).
Andrew Burgess [Wed, 16 Jul 2025 14:30:48 +0000 (15:30 +0100)]
gdb/testsuite: mark the start of each gdb.in.* log file
Emit a line in the gdb.log file each time a new gdb.in.NUM command log
is started. The gdb.log line includes the full filename for the new
gdb.in.NUM file.
This change will make it trivial to go from a FAIL in the gdb.log file
to the gdb.in.NUM file that (should) reproduce the failure. When I
encounter a failing test one of my first steps is usually to identify
the gdb.in.NUM file and try re-running it to see if that reproduces
the failure. Some tests create many very similar gdb.in.NUM files, so
finding the exact one can sometimes be difficult. With this patch
that task is now trivial.
There should be no change in what is tested after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Alan Modra [Thu, 17 Jul 2025 23:54:30 +0000 (09:24 +0930)]
visium: use RELOC_AGAINST_DISCARDED_SECTION
The initial visium support added in commit d924db559be9 didn't make
use of RELOC_AGAINST_DISCARDED_SECTION, and so lacked code to remove
relocations in debug sections.
Tom de Vries [Thu, 17 Jul 2025 20:06:38 +0000 (22:06 +0200)]
[gdb/testsuite] Use pagination_prompt var more often
In some test-cases, matching the pagination prompt is split up to address a
matching race but that's no longer necessary, thanks to commit c3f814a1433
("Fix paginate-*.exp races").
Tom de Vries [Thu, 17 Jul 2025 20:06:38 +0000 (22:06 +0200)]
[gdb/testsuite] Require minimum width in gdb.base/style.exp
In test-case gdb.base/style.exp, we have proc test_pagination_prompt_styling,
which:
- determines a "desired width" by parsing the output of "info files",
- sets width to the "desired width", and
- runs "info files" again.
The "desired width" on my system is 88, but if I override it to 65, I run
into:
...
(gdb) info files^M
Symbols from "^[[32;49;22;27m/data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.base/style/style^[[m".^M
--Type <RET> for more, q to quit, c to continue without paging--^M
^MFAIL: gdb.base/style.exp: check pagination prompt styling (timeout)
...
with make target check, and with check-read1 into:
...
(gdb) info files^M
Symbols from "^[[32;49;22;27m/data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.base/style/style^[[m".^M
--Type <RET> for more, q to quit, c to continue without paging--^M
^M^[[A^M
Native process:^M
Using the running image of child process 6179.^M
--Type <RET> for more, q to quit, c to continue without paging--ERROR: Window too small.
UNRESOLVED: gdb.base/style.exp: check pagination prompt styling
...
This is caused by the following.
The size of the pagination prompt is 64:
...
1 2 3 4 5 6 1234567890123456789012345678901234567890123456789012345678901234
--Type <RET> for more, q to quit, c to continue without paging--
...
and because we have TERM=ansi and width == 65, readline wraps at 64:
...
(gdb) maint info screen
Number of characters gdb thinks are in a line is 65.
Number of characters readline reports are in a line is 64.
...
In other words, readline wraps when printing the pagination prompt.
This causes some unusual output, and the test is not prepared to handle this.
Fix this by requiring that desired_width is at least
<length of pagination prompt> + 2.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR testsuite/33167
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33167
Tom de Vries [Thu, 17 Jul 2025 20:06:38 +0000 (22:06 +0200)]
[gdb/testsuite] Fix regexp in gdb.base/style.exp
In test-case gdb.base/style.exp, we have proc test_pagination_prompt_styling,
which:
- determines a "desired width" by parsing the output of "info files",
- sets width to the "desired width", and
- runs "info files" again.
The "desired width" on my system is 88, but if I override it to 66, I run into:
...
FAIL: gdb.base/style.exp: check pagination prompt styling
...
due to the test classifying this line as a bad line:
...
$hex - $hex is .init_array in --Type <RET> for more, ...
...
This is due to a bug in this regexp:
...
# For lines that don't match this pattern, we cannot comment on
# where the style reset should occur, so lets just claim the line
# is fine.
if { ![regexp "\\s+$::hex - $::hex is \[^\r\n\]+ in " $str] } {
return true
}
...
which is supposed to determine whether the line needs to contain a style
reset.
For aforementioned line, the regexp matches, so the test concludes that the
line should have a style reset, and because it hasn't, it classifies it as a
bad line.
Fix this by making the regexp more strict:
...
if { ![regexp "\\s+$::hex - $::hex is \[^\r\n\]+ in \033" $str] } {
...
projects / thirdparty / binutils-gdb.git / log
