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.
H.J. Lu [Thu, 11 Dec 2025 00:33:05 +0000 (08:33 +0800)]
lto: Compile LTO 15 test with -fno-fat-lto-objects
When -ffat-lto-objects is used to compile binutils, LTO 15 test fails on
32-bit targets the same way as -fno-lto, where the builtin function is
used to divide unsigned 64-bit integers. Compile LTO 15 test with
-fno-fat-lto-objects so that it passes on both 32-bit and 64-bit targets.
PR ld/33709
* testsuite/ld-plugin/lto.exp (lto_link_tests): Compile lto-15a.c
and lto-15b.c with -fno-fat-lto-objects.
Define a symbol .Lpcadd_hi* at R_LARCH_*_PCADD_HI20
if the instruction expand from macro.
Change the symbol of R_LARCH_PCADD_LO12 to .Lpcadd_hi*
if the instruction expand from macro.
mengqinggang [Wed, 8 Oct 2025 05:25:06 +0000 (13:25 +0800)]
LoongArch: LA32 macros support
Change pcalau12i to pcaddu12i for LA32 macros.
Add call/tail and call30/tail30 macros, call/tail can expand to
call36/tail36 or call30/tail30 by mabi option.
LoongArch: Add processing for LA32/LA32R relocations
R_LARCH_CALL30:
pcaddu12i $ra, %call30(func)
jirl $ra, $ra, 0
Similar with R_LARCH_CALL36, pcaddu12i and jirl must be adjacent.
R_LARCH_PCADD_HI20, R_LARCH_PCADD_LO12:
.Lpcadd_hi0:
pcaddu12i $t0, %pcadd_hi20(sym)
addi.w $t0, $t0, %pcadd_lo12(.Lpcadd_hi0)
Similar with RISCV PCREL_HI20, PCREL_LO12, R_LARCH_PCADD_LO12 reference to the
symbol at R_LARCH_PCADD_HI20.
LA32 and LA32R do not have pcaddu18i.
LA32R does not have pcalau12i.
Add R_LARCH_CALL30 for pcaddu12i + jirl used in LA32 and LA32R.
Add R_LARCH_*_PCADD_HI20 for pcaddu12i used in LA32R.
Add R_LARCH_*_PCADD_LO12 for addi.w/ld.w used in LA32R.
GDB: Guile: Remove procedures ineffectual since Guile 2.2
The manual mentions since GDB 10 that the functions for getting and setting
the size of memory port buffers are deprecated, and don't work when using
Guile 2.2 or later. Since now GDB only supports Guile 2.2 and newer,
perform the promised removal.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Tue, 9 Dec 2025 23:25:20 +0000 (00:25 +0100)]
[gdb] Fix whitespace in NEWS
Fix this:
...
$ empty=$(git hash-object -t tree /dev/null)
$ git diff-index --check $empty gdb/NEWS
gdb/NEWS:1874: space before tab in indent.
+ [--basename | --dirname]
...
and add the file to the clean list in
gdb/contrib/check-whitespace-pre-commit.py.
[ I'm not sure if NEWS has an official style.
There are no settings for NEWS in .gitattributes, so the whitespace attribute
defaults to trailing-space (shorthand for blank-at-eol, blank-at-eof) and
space-before-tab.
We could require either spaces only (tab-in-indent) in gdb/.gitattributes:
...
NEWS whitespace=space-before-tab,tab-in-indent,trailing-space
...
or tab style (indent-with-non-tab):
...
NEWS whitespace=space-before-tab,indent-with-non-tab,trailing-space
...
For tab-in-indent, we get:
...
$ git diff-index --check $empty gdb/NEWS | wc -l
228
...
and for indent-with-non-tab instead:
...
$ git diff-index --check $empty gdb/NEWS | wc -l
40
...
so the more common style seems to be tab style.
H.J. Lu [Mon, 8 Dec 2025 23:33:28 +0000 (07:33 +0800)]
x86: Add _bfd_elf_x86_copy_special_section_fields
When Linux/x86 objcopy is used on Solaris binary, it sets EI_OSABI to
ELFOSABI_SOLARIS, but it doesn't set the sh_info and sh_link fields of
Solaris specific sections.
Add _bfd_elf_x86_copy_special_section_fields to return false for Solaris
binary to properly set the sh_info and sh_link fields of Solaris specific
sections.
Tom Tromey [Fri, 14 Nov 2025 21:43:27 +0000 (14:43 -0700)]
Partly rewrite dwarf2_get_symbol_read_needs
This patch partly rewries dwarf2_get_symbol_read_needs. The goal is
to simplify it and perhaps make it a little more efficient.
With this patch, if an operation simply continues to the next
operation in the expression, then no manipulation of ops_to_visit is
needed. This avoids excess pushes and pops.
Also, visited_ops is changed to be a std::vector<bool> rather than a
map.
Tom Tromey [Wed, 11 Dec 2024 18:33:12 +0000 (11:33 -0700)]
Implement local-environment commands
A user noted that "set environment" does not affect things like
"shell" or "pipe". This makes some sense, because the environment is
per-inferior, and also in the general case it may be affecting a
remote machine -- i.e., the settings may not be locally appropriate.
This patch adds a new set of "local-environment" commands (set, show,
and unset) that affect gdb's own environment.
Approved-By: Andrew Burgess <aburgess@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
Tom Tromey [Wed, 11 Dec 2024 18:25:08 +0000 (11:25 -0700)]
Allow NULL to be passed to environment-related functions
This changse the various environment-related helper functions to
accept a NULL environment pointer. This special case means that the
function should affect gdb's global environment.
Approved-By: Andrew Burgess <aburgess@redhat.com> Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
Andrew pointed out that a new test I proposed failed with read1.
This test was essentially a copy of gdb.base/environ.exp.
I couldn't reproduce the read1 problem, but this patch rewrites the
one test there that seems like it could possibly fail in this mode.
Now it uses line-by-line mode and checks for a certain environment
variable appearing in the output.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Thu, 4 Dec 2025 17:25:13 +0000 (12:25 -0500)]
gdb: more guile 2.0 support removal
Commit f14bbacae00d ("gdb/guile: remove support for Guile < 2.2")
removed some code supporting Guile 2.0. This patch removes more bits
related to Guile 2.0, and adds a NEWS entry.
* Remove Guile 2.0 mention from the doc.
* Remove HAVE_GUILE_MANUAL_FINALIZATION, assume it is always true.
* Remove guile-2.0 from the versions automatically tried by configure.
* Remove check for scm_new_smob (HAVE_SCM_NEW_SMOB), assume it is
always true.
* Remove hack to fill ac_cv_guild_program_name when the .pc file
wouldn't specify it.
Tested by rebuilding against guile-3.0 and guile-2.2.
A couple of targets use virtually the same code for error reporting in
relocation processing. Merge the copies, removing small discrepancies
such as a fallback call to `abort' for NDS32 targets as per PR 17512,
and factor out for backends to use.
gdbsupport: remove undefined behaviour from (forward_)scope_exit
A build failure was reported[1] when using clang++. The failure looks
like this:
CXX aarch64-fbsd-tdep.o
In file included from /tmp/src/binutils-gdb/gdb/aarch64-fbsd-tdep.c:22:
In file included from /tmp/src/binutils-gdb/gdb/gdbarch.h:28:
In file included from /tmp/src/binutils-gdb/gdb/infrun.h:21:
In file included from /tmp/src/binutils-gdb/gdb/gdbthread.h:35:
/tmp/src/binutils-gdb/gdb/../gdbsupport/forward-scope-exit.h:112:20: error: too many template arguments
for class template 'forward_scope_exit_policy'
112 | = scope_exit_base<forward_scope_exit_policy<Function,
| ^
113 | function, Res, Args...>>;
| ~~~~~~~~
/tmp/src/binutils-gdb/gdb/../gdbsupport/forward-scope-exit.h:82:8: note: template is declared here
81 | template<typename Function, Function *function, typename Signature>
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
82 | struct forward_scope_exit_policy;
| ^
The problem is that the forward_scope_exit_policy class expects 3
template arguments, but in forward-scope-exit.h we say:
template<typename Function, Function *function,
typename Res, typename... Args>
using forward_scope_exit
= scope_exit_base<forward_scope_exit_policy<Function,
function, Res, Args...>>;
Which passes 4 template arguments. Fix this by changing the above
'using' like too:
template<typename Function, Function *function, typename Signature>
using forward_scope_exit
= scope_exit_base<forward_scope_exit_policy<Function, function,
Signature>>;
Alan Modra [Tue, 9 Dec 2025 07:25:12 +0000 (17:55 +1030)]
gold testsuite volatile fixes
Avoid these mainline gcc complaints (C23 WG14 n2743).
copy_test_relro.cc:42:5: error: ‘++’ expression of ‘volatile’-qualified type is deprecated [-Werror=volatile]
icf_test_pr21066.cc:50:55: error: ‘volatile’-qualified parameter is deprecated [-Werror=volatile]
Lulu Cai [Fri, 28 Nov 2025 07:54:58 +0000 (15:54 +0800)]
LoongArch: Add support for the ud macro instruction
In the "ud ui5" macro, the value of ui5 must be in the range 0–31. It
expands to "amswap.w $rd, $r1, $rj", where ui5 specifies the register
number for $rd in the amswap.w instruction, and $rd == $rj.
The test case have been adjusted to no longer report errors for illegal
operands of the amswap.w instruction.
gas/
* config/tc-loongarch.c (check_this_insn_before_appending): No
longer check amswap.w.
* testsuite/gas/loongarch/illegal-operand.l: Update.
* testsuite/gas/loongarch/illegal-operand.s: Update.
* testsuite/gas/loongarch/macro_ud.d: New test.
* testsuite/gas/loongarch/macro_ud.s: New test.
Tom de Vries [Mon, 8 Dec 2025 15:38:28 +0000 (16:38 +0100)]
[gdb/testsuite] Fix FAIL in gdb.multi/remote-with-running-inferior.exp
Occasionally, with test-case gdb.multi/remote-with-running-inferior.exp I run
into:
...
(gdb) continue^M
Continuing.^M
^M
Thread 1.1 "remote-with-run" hit Breakpoint 1.1, main () at \
remote-with-running-inferior.c:31^M
31 for (int i = 0; i < 30; ++i)^M
(gdb) PASS: $exp: target_non_stop=auto: non_stop=off: \
continue to breakpoint: continue to breakpoint in breakpt
bt 1^M
(gdb) FAIL: $exp: target_non_stop=auto: non_stop=off: \
check inferior 1 is in breakpt
...
The problem is a race between:
- inferior 1 reaching main, and
- gdb setting a breakpoint on main.
If the breakpoint on main is set before inferior 1 reaches main, the
breakpoint triggers for inferior 1, which the test-case doesn't expect.
Fix this by setting the breakpoint on main only for inferior 2.
projects / thirdparty / binutils-gdb.git / log
