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.
Andrew Burgess [Thu, 23 Oct 2025 15:34:20 +0000 (16:34 +0100)]
gdbsupport: remove undefined behaviour from (forward_)scope_exit
Our implementation of scope_exit and forward_scope_exit make use of
the Curiously Recurring Template Pattern (CRTP) to provide the
"release" functionality, this is done in the scope_exit_base class in
scope-exit.h.
The interesting (for this commit) parts of scope_exit_base look like
this:
~scope_exit_base ()
{
if (!m_released)
{
auto *self = static_cast<CRTP *> (this);
self->on_exit ();
}
}
... snip ...
};
By the time ~scope_exit_base is called the destructor for the derived
class (called CRTP here) has already been run, which means any data
members in the derived class will have also have had their destructors
run. As a result of this I believe that casting 'this' to the derived
type, and then calling the on_exit method is undefined behaviour, as
'this' can no longer be considered a valid instance of CRTP (the CRTP
part has been destructed).
In reality, the memory for the derived type is not reclaimed until
after ~scope_exit_base has finished, so as long as the data members of
the derived type are Plain Old Data (POD), then the current code
should be just fine; any data members of the derived class will remain
in place, and untouched, until ~scope_exit_base has completed.
But still, I don't think we should rely on undefined behaviour.
I actually ran into this when, in another series, I tried to reuse
scope_exit_base with a class where a data member was not POD, and in
this case GDB would crash because my new on_exit function was making
use of the non-POD data member after it had been destructed, and
resources released.
I propose that we move away from the CRTP, and instead flip the class
hierarchy. Instead of derived classes like scope_exit inheriting from
scope_exit_base, scope_exit_base should inherit from scope_exit.
What this means, is that when ~scope_exit_base is called, ~scope_exit
will not yet have been run, and the data members of scope_exit will
still be valid.
To allow the existing names to be used, the plan is that the existing
scope_exit and forward_scope_exit classes are renamed to
scope_exit_policy and forward_scope_exit_policy. These policy classes
will then be injected via a template argument as the base class for
scope_exit_base. Finally, we can:
template<typename EF>
using scope_exit = scope_exit_base<scope_exit_policy<EF>>;
which defines the scope_exit type. This type is a drop in replacement
with all of GDB's existing code, but avoids the undefined behaviour.
We can do something similar with forward_scope_exit.
There should be no user visible changes after this commit.
Starting in C23, strchr and strrchr will return const char *, if fed a
const char *. This means that several files in the BFD directory will
fail to build as they are assigning the return of those functions to a
char *.
Fix this by const-ifying several variables. The only place where that
wasn't just that was in targets.c, where a variable was being used in
subsequent strrchr invocations to change the underlying string, so a new
variable had to be introduced.
No user-visible change should happen after this commit.
Guinevere Larsen [Thu, 30 Oct 2025 20:43:55 +0000 (17:43 -0300)]
gdb/record_full: add ptid entry for history.
For record full to work on multi-threaded inferiors, we must know to
which thread any given recorded instruction belongs to. This commit adds
this as a new entry for each instruction when an inferior is
multi-threaded. This way, when replaying the instruction, the subsystem
is able to change inferior thread as needed, and avoid SIGILLs when
changing stuff
Ideally, we would only add the PTID entry when we actually need to
switch threads, but that is left as a future improvement.
WIP: replaying doesn't automatically change threads yet, but there was
an attempt
Magnus Wållberg [Mon, 8 Dec 2025 09:33:40 +0000 (20:03 +1030)]
PR 33676 ld segfaults when using binary input inside NOLOAD
The code at ldlang.c:2840-2841 checks if the output BFD is ELF format,
then unconditionally uses elf_section_type() on the input section
without verifying the input section is also ELF format.
This was introduced in commit d87be451e (PR ld/32787) which added
special handling for NOLOAD note sections.
PR 33676
PR 32787
* ldlang.c (lang_add_section): Check section owner's BFD
flavour before using elf_section_type.
Alan Modra [Mon, 8 Dec 2025 05:30:16 +0000 (16:00 +1030)]
PR 33698 and PR 33700
It is possible for dump_relocations to return on an error from
slurp_rela_relocs or slurp_rel_relocs without writing to
"all_relocations". In that case an uninitialised r_symbol is passed
to free at the end of process_got_section_contents.
Tom de Vries [Mon, 8 Dec 2025 08:30:25 +0000 (09:30 +0100)]
[gdb/build] Re-add *.[ch] in gdb.pot
In commit 4a40fe05bf0 ("[gdb/build] Handle gdbsupport and gdbserver in
gdb.pot"), in order to handle '*.cc' files I did:
...
- -name '*.[hc]' -print
+ -name '*.[hc]' -o -name '*.cc' -print
...
but failed to understand that this no longer printed the '*.[hc]' names.
Fix this by adding a '-print' for '*.[hc]'.
Tested by doing:
...
$ cd build/gdb
$ make po/gdb.pot
...
$ grep -c symtab.c po/gdb.pot
102
...
H.J. Lu [Sat, 6 Dec 2025 02:17:39 +0000 (10:17 +0800)]
elf: Add SHT_SUNW_ctf and SHT_SUNW_symnsort
On Solaris 11.4, there is SHT_SUNW_symnsort and no SHT_SUNW_symtabnsort.
SHT_SUNW_symnsort is defined to 0x6fffffec, which is the same as
SHT_SUNW_symtabnsort. There is also SHT_SUNW_ctf. Add SHT_SUNW_ctf and
rename SHT_SUNW_symtabnsort to SHT_SUNW_symnsort. Move SHT_SUNW_phname
after SHT_SUNW_symnsort.
binutils/
* readelf.c (get_solaris_section_type): Add SHT_SUNW_ctf and
SHT_SUNW_symnsort. Move SHT_SUNW_phname after SHT_SUNW_symnsort.
Remove SHT_SUNW_symtabnsort.
include/
* elf/common.h (SHT_SUNW_ctf): New.
(SHT_SUNW_symtabnsort): Renamed to ...
(SHT_SUNW_symnsort): This.
(SHT_SUNW_phname): Moved after SHT_SUNW_symnsort.
Tom Tromey [Fri, 5 Dec 2025 18:43:08 +0000 (11:43 -0700)]
Unconditionally pass is_a_field_of_this in c-exp.y
In a review to a different patch of mine, Simon asked for this change.
The idea here is that there's no need to pass null as the "field of
this" parameter, as lookup_language_this checks the language anyway.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Sun, 7 Dec 2025 09:59:54 +0000 (10:59 +0100)]
[gdb/contrib] Check clean files in check-whitespace-pre-commit.sh
The pre-commit check check-whitespace checks diffs.
Consequently, we detect something like this:
...
$ echo >> gdb/testsuite/lib/gdb.exp
$ git commit -a -m trailing-empty-line
...
check-whitespace.........................................................Failed
- hook id: check-whitespace
- duration: 0.01s
- exit code: 2
gdb/testsuite/lib/gdb.exp:11717: new blank line at EOF.
...
But say we work around the failing check using --no-verify, then we no longer
detect it after the commit has succeeded:
...
$ git commit -a -m trailing-empty-line --no-verify
[detached HEAD e6302105522] trailing-empty-line
1 file changed, 1 insertion(+)
$ pre-commit run --all-files check-whitespace
check-whitespace.........................................................Passed
- hook id: check-whitespace
- duration: 0.3s
...
Fix this in check-whitespace-pre-commit.sh by distinguishing between clean and
other files. Doing so is easier to do in a more advanced scripting language,
so rewrite into python.
Since a recent commit, gdb/testsuite is clean, so I'm using that as
simple classifier for now.
For the other files we do what we did before, and check just the staging area:
...
$ git --no-pager diff --staged --check "${other[@]}"
...
But for clean files, we check the entire file, including staged changes:
...
$ empty=$(git hash-object -t tree /dev/null)
$ git diff-index --cached --check $empty "${clean[@]}"
...
Consequently, we do see:
...
$ git commit -a -m trailing-empty-line --no-verify
[detached HEAD e6302105522] trailing-empty-line
1 file changed, 1 insertion(+)
$ pre-commit run --all-files check-whitespace
check-whitespace.........................................................Failed
- hook id: check-whitespace
- duration: 0.64s
- exit code: 2
gdb/testsuite/lib/gdb.exp:11717: new blank line at EOF.
...
elf: Renumber local dynamic symbols only if needed
caused regressions for hppa64-linux which adds local dynamic symbols,
__text_seg and __data_seg in elf64_hppa_late_size_sections. Set
has_local_dynsyms to true when adding __text_seg and __data_seg.
* elf64-hppa.c (elf64_hppa_late_size_sections): Set
has_local_dynsyms to true when adding __text_seg and __data_seg.
Andrew Burgess [Mon, 17 Nov 2025 14:08:57 +0000 (14:08 +0000)]
gdb: display a symbol more often in multi-file list output
I noticed that when a command line 'list foo.c:10' displays multiple
files, the symbol would always be shown as "???", e.g.:
file: "/tmp/foo.c", line number: 10, symbol: "???"
this is because, when the symtab_and_line is created for the
'foo.c:10', the pc and symbol are never filled in.
In this commit, I propose that, when we decide that the above header
line needs to be printed, we should attempt to lookup a symbol for the
relevant line, and if one is found, we can use that.
The symbol lookup is done by first calling find_pc_for_line, and then
using find_symbol_for_pc to find a suitable symbol.
On some configurations (SLES with glibc-devel installed), the compiler
links /usr/lib64/crit1.o (which contains some debug information) into
the final binary. As a result, the binary contains "some" debug
information, which makes the above pattern fail. The testcase is still
valid as we only really need the GPU code object (embedded in the main
binary) to not contain debug information, so this patch proposes to
relax this first step by using "gdb_load" instead.
Tested on x86_64-linux + AMDGPU gfx1031.
Change-Id: Id903f62e170af69c001b39f4681602a54e2fdaf1 Approved-By: Tom Tromey <tom@tromey.com>
gdb, linespec: avoid multiple locations with same PC
broke GDB's ability to list multiple source files using a 'list'
command. In GDB 16 and earlier something like 'list foo.c:10' could
print multiple results if there were multiple 'foo.c' files compiled
into the executable.
The above commit added a filter to add_sal_to_sals (linespec.c) such
that multiple sals in the same program space, but with the same pc
value, could not be added, only the first sal would actually be
recorded. The problem with this is that add_sal_to_sals is used from
decode_digits_list_mode (also linespec.c) where the pc value is forced
to zero. This force to zero makes sense I think as there might not be
any compiled code for the requested line (this is for 'list' after
all), so there might not be a valid pc to use.
I'm not a fan of using '0' as a special pc value, there are embedded
targets where 0 is a valid pc value, but given we're already using 0
here, I propose to just roll with it.
So, my proposal is that, if the pc is 0, add_sal_to_sals should always
add the sal. This fixes the decode_digits_list_mode, but should keep
the fix that c7a45b98a614 introduced.
In --help option, adds znver6 to the list of CPUs under -march.
Please find the ISA descriptions for AVX512_BMM instructions below.
AVX512 Bit Manipulation Instructions
====================================
The AVX512BMM instructions include Bit Matrix Multiply and Bit Reversal
operations.
CPUID
-----
Support is indicated by the new CPUID 8000_0021, EAX bit 23, labeled AVX512_BMM.
DESCRIPTION
-----------
256 BIT VERSIONS
----------------
16x16 non-transposed fused BMM-accumulate (BMAC) with OR/XOR reduction.
A ymm register holds a 16x16 bit matrix. The third source matrix for
accumulation is in ymm1.
512 BIT VERSIONS
----------------
2 parallel 16x16 non-transposed fused BMM-accumulate (BMAC) with OR/XOR
reduction.
Each 256-bit chunk of a zmm register holds a 16x16 bit matrix. The third source
matrices for accumulation are in zmm1.
DESCRIPTION
-----------
Bit reversal within a byte boundary. Only applied to input bytes where the
corresponding mask bit is set; otherwise, bytes are left untouched or zeroed out
if zero masking is indicated.
gas/ChangeLog:
* NEWS: Add znver6 ARCH.
* config/tc-i386.c: Add znver6 ARCH, avx512_bmm SUBARCH.
* doc/c-i386.texi: Likewise.
* testsuite/gas/i386/i386.exp: Add znver6 test cases.
* testsuite/gas/i386/x86-64.exp: Add znver6 test cases.
* testsuite/gas/i386/arch-16-znver6.d: New test.
* testsuite/gas/i386/arch-16.d: New test.
* testsuite/gas/i386/arch-16.s: New test.
* testsuite/gas/i386/avx512_bmm.d: New test.
* testsuite/gas/i386/avx512_bmm.s: New test.
* testsuite/gas/i386/avx512_bmm_vl-inval.l: New test.
* testsuite/gas/i386/avx512_bmm_vl-inval.s: New test.
* testsuite/gas/i386/avx512_bmm_vl.d: New test.
* testsuite/gas/i386/avx512_bmm_vl.s: New test.
* testsuite/gas/i386/x86-64-arch-6-znver6.d: New test.
* testsuite/gas/i386/x86-64-arch-6.d: New test.
* testsuite/gas/i386/x86-64-arch-6.s: New test.
* testsuite/gas/i386/x86-64-avx512_bmm-bad.d: New test.
* testsuite/gas/i386/x86-64-avx512_bmm-bad.s: New test.
* testsuite/gas/i386/x86-64-avx512_bmm.d: New test.
* testsuite/gas/i386/x86-64-avx512_bmm.s: New test.
* testsuite/gas/i386/x86-64-avx512_bmm_vl-inval.l: New test.
* testsuite/gas/i386/x86-64-avx512_bmm_vl-inval.s: New test.
* testsuite/gas/i386/x86-64-avx512_bmm_vl.d: New test.
* testsuite/gas/i386/x86-64-avx512_bmm_vl.s: New test.
Jan Beulich [Fri, 5 Dec 2025 09:12:34 +0000 (10:12 +0100)]
x86: sub-divide APX_F - NCI-NDD-NF and testing
To reflect spec version 007's introduction of the three-way APX-NCI-NDD-NF
also introduce a respective ISA specifier, without that actually having a
counterpart in opcodes.
Add a testcase to cover all four new ISA specifiers.
Jan Beulich [Fri, 5 Dec 2025 09:12:12 +0000 (10:12 +0100)]
x86: sub-divide APX_F - NF
While spec version 007 introduced the three-way APX-NCI-NDD-NF, let's
split the three aspects (NCI, NDD, and NF) in gas. For NF we only need to
guard the {nf} pseudo-prefix.
Jan Beulich [Fri, 5 Dec 2025 09:12:00 +0000 (10:12 +0100)]
x86: sub-divide APX_F - NDD
While spec version 007 introduced the three-way APX-NCI-NDD-NF, let's
split the three aspects (NCI, NDD, and NF) in gas. Note that NDD also
applies to a number of EVEX-encoded insns with EVEX.ndd clear.
Some extra logic is needed in cpu_flags_match() to avoid the need to
add APX_NDD to CPU_FLAGS_COMMON.
Tom de Vries [Fri, 5 Dec 2025 07:24:06 +0000 (08:24 +0100)]
[gdb/testsuite] Fix gdb.base/long_long.exp on arm
On armv7hl-suse-linux-gnu, I run into:
...
(gdb) p/f val.oct
$26 = -5.9822653797615723e-120
(gdb) FAIL: gdb.base/long_long.exp: p/f val.oct
...
There's some complicated logic here in the test-case:
...
if { $sizeof_double == 8 || $sizeof_long_double == 8 } {
# ARM FPA floating point numbers are not strictly little endian or big
# endian, but a hybrid. They are in little endian format with the two
# words swapped in big endian format.
# EABI targets default to natural-endian VFP format.
if { ([istarget "arm*-*-*"]) \
&& !([istarget "*-*-*eabi*"] || \
[istarget "*-*-mingw32ce*"] || \
[istarget "*-*-openbsd*"]) } then {
# assume the long long represents a floating point double in ARM format
gdb_test "p/f val.oct" "2.1386676354387559e\\+265"
} else {
# assume the long long represents a floating point double in little
# endian format
gdb_test "p/f val.oct" "-5.9822653797615723e-120"
}
} else {
gdb_test "p/f val.oct" "-2.42716126e-15"
}
...
which makes the test-case expect the ARM FPA variant.
I think trying to pin down the exact circumstances under which we have ARM FPA
is unnecessary, so I could live with:
...
set re_val_oct_f [string_to_regexp "-5.9822653797615723e-120"]
if { [istarget "arm*-*-*"] } {
set re_val_oct_f_arm_fpa [string_to_regexp "2.1386676354387559e+265"]
re_val_oct_f "$re_val_oct_f|$re_val_oct_f_arm_fpa"
}
....
But instead, I propose to just drop the arm-specific part.
I doubt whether an ARM VPA setup is still part of any test matrix. And if it
is, then I expect other tests to fail as well for the same reason. The ARM
FPA logic is used only once in the test-case, but -5.9822653797615723e-120 is
used more frequently.
Indeed, I wonder the same about setups where -2.42716126e-15 is expected.
On such a setup, won't this fail as well:
...
gdb_test "x/2gf g" "3.5127005640885037e-303.*-5.9822653797615723e-120"
...
?
Unfortunately I'm not sure what setup to use to trigger the -2.42716126e-15
case.
Fix this as good as possible by choosing once between -5.9822653797615723e-120
and -2.42716126e-15, assigning it to re_val_oct_f, and using it everywhere
where those constants are used.
gdb: handle unlimited screen width case in print_gdb_hints
was merged that deleted some of the code I'd spotted. All that's left
is a 'return' that can be removed, there's nothing after the 'if'
block, the function just returns.
There should be no user visible changes after this commit.
Tom Tromey [Thu, 4 Dec 2025 14:36:59 +0000 (07:36 -0700)]
Fix 'ptype' of a certain Ada modular type
If an Ada modular type is the same size as gdb's own ULONGEST, ptype
will show "mod 0". This happens because ada_modulus does:
return (ULONGEST) high.const_val () + 1;
This patch cleans this up, replacing ada_modulus with a function to
return the upper bound (if available), and then fixing the various
callers. The type-printing caller still does the "+1", but now this
is done with a gdb_mpz.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33690 Approved-By: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Tue, 2 Dec 2025 21:09:26 +0000 (16:09 -0500)]
gdb: remove find_target_at
... to make the current_inferior reference bubble up one level. Since
find_target_at would become a trivial wrapper around
inferior::target_at, remove it. I think it's clearer anyway to see
explicitly that the "subject" of the method call is the inferior.
Change-Id: I73ec44d37e7afea6e85b1689af65e32ae8e5a695 Approved-By: Tom Tromey <tom@tromey.com>
Alice Carlotti [Tue, 4 Nov 2025 12:22:52 +0000 (12:22 +0000)]
aarch64: Enable `-M notes' by default
We already print other instruction comments, such as condition code
aliases, by default. The `-M no-notes' option has been available in
Binutils for over 7 years, so if anyone does need the notes to be
disabled then they can do so explicitly.
projects / thirdparty / binutils-gdb.git / log
