Andrew Burgess [Mon, 15 Dec 2025 16:27:37 +0000 (16:27 +0000)]
gdb: fix line wrapping in new boxed hints when styling is enabled
I noticed that the startup hint text, the stuff that's placed into a
box, is not line wrapping correctly. For example:
$ gdb -nw -nh -eiex 'set width 60'
... snip ...
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ 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)
Notice the final two lines within the box, there's no need to wrap
after the word 'search', plenty more would fit on that line. And
indeed, if we switch off styling:
+----------------------------------------------------------+
| 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)
That's mostly fixed it, except I still think there's a stray white
space character before '<word>' on the final line.
The fact that the output is wrapped differently with styling on and
off tells me that this is not an intentional choice.
The problems are, I think all in box_one_message (from top.c). There
are a number of issues.
1. Each time around the loop we count all escape characters in
MESSAGE, not just the escape characters up to the point where we
might wrap the message. This has the potential to over count the
escape characters.
2. When splitting MESSAGE we search for a space character. This
search starts based on the terminal width, but neglects to take
into account any escape characters prior to the split point.
3. If we split a line after an alternative style has been activated,
but before the style has been reset, then the border of the box on
that line is going to be rendered in the alternative style.
4. When computing what content needs to be moved onto the second
line, we don't move past the space character (as found in point
2).
Now it just so happens that issues (1) and (3) can be ignored for now.
The surrounding box is only added (and line wrapping performed) if the
terminal is at least wide enough to fit the documentation URL (plus
box borders). This means a minimum width of 51 characters. On all
the other lines, any styled output is always to the left of the line,
occurring before character 51. This means that counting all escape
characters is the same as counting just the escape characters that
will appear before the line break. And we will never need to line
break part way through some styled text.
Obviously we _could_ fix this code properly, but it's not simple, and
it would all be completely theoretical. So in this commit I plan to
add an assert that all escape sequences occur within the first 51
characters, then if the above text ever changes we will immediately
know that box_one_message will need to be rewritten.
Fixing issue (2) is pretty easy, this line:
line = message.substr (0, message.rfind (" ", width));
just needs to be updated to take N_ESCAPE_CHARS into account. We
currently look for a space after WIDTH characters in MESSAGE, but
MESSAGE also contains escape sequences, so we really need to search in
for a space starting from 'WIDTH + N_ESCAPE_CHARS'.
And fixing (4) is also easy, this line:
message = message.substr (line.length ());
finds the remainder of MESSAGE based on LINE. But LINE was all
content up to (but not including) the space character we found. What
we actually need to do is:
message = message.substr (line.length () + 1);
To add the assert that I discussed above, I've moved the escape
characters counting code out of the line printing loop. We now count
the escape characters just once, and assert that these all fit within
the WIDTH, this means they will all appear before any line break.
While making these changes I've also made use of std::move to avoid
copying a string in one place.
Finally, the gdb.base/startup-hints.exp test has been expanded to
cover both styled and non-styled output, as well as a greater range of
terminal widths.
gdb: crash if thread unexpectedly disappears from thread list
It is worth pointing out that the use after free issue existed before
this commit, this commit just introduced a test that exposed the issue
when GDB is run with the address sanitizer.
It has taken a while to get this fix ready for upstream as this fix
depended on the recently committed patch:
gdbsupport: remove undefined behaviour from (forward_)scope_exit
The problem is that the first commit above introduces a test which
causes the remote target to disconnect while processing an inferior
stop event, specifically, within normal_stop (infrun.c), GDB calls
update_thread_list, and it is during this call that the inferior
disconnects.
When the remote target disconnects, GDB immediately unpushes the
remote target. See remote_unpush_target and its uses in remote.c.
If this is the last use of the remote target, then unpushing it will
cause the target to be deleted.
This is a problem, because in normal_stop, we have an RAII variable
maybe_finish_thread_state, which is an optional
scoped_finish_thread_state, and in some cases, this will hold a
pointer to the process_startum_target which needs to be finished.
So the order of events is:
1. Call to normal_stop.
2. Create maybe_finish_thread_state with a pointer to the current
remote_target object.
3. Call update_thread_list.
4. Remote disconnects, GDB unpushes and deletes the current
remote_target object. GDB throws an exception.
5. The exception propagates back to normal_stop.
6. The destructor for maybe_finish_thread_state runs, and tries to
make use of its cached pointer to the (now deleted) remote_target
object. Badness ensues.
This bug isn't restricted to normal_stop. If a remote target
disconnects anywhere where there is a scoped_finish_thread_state in
the call stack then this issue could arise.
I think what we need to do is to ensure that the remote_target is not
actually deleted until after the scoped_finish_thread_state has been
cleaned up.
And so, to achieve this, I propose changing scoped_finish_thread_state
to hold a target_ops_ref rather than a pointer to the target_ops
object. Holding the reference will prevent the object from being
deleted.
The new scoped_finish_thread_state is defined within its own file, and
is a drop in replacement for the existing class.
On my local machine the gdb.replay/missing-thread.exp test passes
cleanly after this commit (with address sanitizers), but when I test
on some other machines with a more recent Fedora install, I'm still
seeing test failures (both before and after this patch), though not
relating to the address sanitizer (at least, I don't see an error from
the sanitizer). I don't think these other issues are directly related
to the problem being addressed in this commit, and so I'm proposing
this patch for inclusion anyway. I'll continue to look at the test
and see if I can fix the other failures too. Or maybe I'll end up
having to back out the test.
Approved-By: Simon Marchi <simon.marchi@efficios.com> Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Add TOC calculation for XCOFF binary in AIX and remove legacy line number information.
Co-authored-by: Simon Marchi <simon.marchi@polymtl.ca>
Closes https://sourceware.org/bugzilla/show_bug.cgi?id=33606
This is a patch to bring back certain XCOFF reading sections back to the GDB code which was removed during the STABS removal.
This patch also removes the legacy line table calculation for STABS since we no longer will support it.
The issue we removed code that will get us the TOC offset in AIX.
This will now cause regressions.
For example,Consider a code where we create a simple library x as below.
int g_in_lib = 777;
int lib_func() {
return g_in_lib + 1;
}
int lib_func();
Then we use this library X in main().
int main() {
printf ("lib_func() = %d \n", lib_func());
return 0;
}
If we as of today compile master branch in AIX and try to call lib_func() from GDB we get,
GNU gdb (GDB) 18.0.50.20251112-git
Breakpoint 1, main () at //gdb_tests/main.c:5
5 printf ("lib_func() = %d \n", lib_func());
DWARF will not have any information about TOC to maintain uniformity with other operating system.
TOC (Table Of Contents) is a part of XCOFF/AIX ABI and is required for:
1: Loading shared libraries as we need TOC that contain pointers to access global variables and functions entry points.
2: Function calls like the above call where AIX expects register r2 = pointer to TOC which gives fast access to global data plus an ofset
3: Large code model = TOC solves the fact that PPC64 can't embed large 64 bit addresses.
So we need to get GDB to fetch this even though we only read DWARF debug sections in the XCOFF binary. (AIX uses GCC-13 now which produces only DWARF now.).
In the above case since the toc_offset is not there now we cannot access lib_func() causing the regression.
The patch right now brings back the code required to fetch the same. Once this patch is applied we get,
GNU gdb (GDB) 18.0.50.20251204-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 "powerpc64-ibm-aix7.2.0.0".
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 //gdb_tests/main...
(gdb) b main
Breakpoint 1 at 0x10000530: file //gdb_tests/main.c, line 5.
(gdb) r
Starting program: /gdb_tests/main
Breakpoint 1, main () at //gdb_tests/main.c:5
5 printf ("lib_func() = %d \n", lib_func());
(gdb) call lib_func()
$1 = 778
(gdb) q
A debugging session is active.
Also some clean ups of code and additions, they are:
1: Replaced old APIs like bfd_map_over_sections with gdb_bfd_sections() and range-based loops.
2: Used helpers like obstack_strndup instead of manual allocation like changing p = (char *) obstack_alloc (&objfile->objfile_obstack, and strncpy (p, symbol->n_name, E_SYMNMLEN);
to *name = obstack_strndup(&objfile->objfile_obstack, symbol->n_name, E_SYMNMLEN);
3: Removed unused macros as unnecessary global variables as you mentioned
4: Replaced perror_with_name with error() and bfd_errmsg. See: error(_("reading symbol table: %s"), bfd_errmsg(bfd_get_error()));
5: Also used bfd_get_section_alloc_size().
6: Eliminated the xcoff_find_targ_sec_arg struct used in GDB 17 or earlier because it is no longer necessary for context handling.
7: Eliminated the find_targ_sec () used in GDB 17 or earlier since we find the bfd_sect in xcoff_secnum_to_sections().
Tom de Vries [Tue, 6 Jan 2026 21:44:31 +0000 (22:44 +0100)]
[gdb] Fix heap-buffer-overflow in args_complete_p
PR gdb/33754 reports a heap-buffer-overflow args_complete_p, while checking
the while condition:
...
while (*input != '\0')
{
input = skip_spaces (input);
...
++input;
}
...
The problem can be reproduced by calling args_complete_p (" "). The following
happens:
- at function entry, input == " "
- the while loop is entered
- after skip_spaces, input == ""
- after the ++input at the end of the loop body, input points past the
terminating '\0'
- while checking the while condition, *input does an out-of-bound access.
Add a unit test exercising this minimal example, fix this by checking
input after skip_spaces, and add an assert to detect the heap-buffer-overflow
without Address Sanitizer.
Another heap-buffer-overflow can be found by calling args_complete_p ("\"\\").
In this case, the following happens:
- at function entry, input == "\"\\"
- the while loop is entered
- dquote is set to true and input == "\\"
- the while loop is entered a second time
- the condition *input == '\\' && strchr ("\"\\", *(input + 1)) != nullptr
evaluates to true (which is not trivial to understand, because the char
found in the string "\"\\" is '\0'), leading to two increments of input,
again making input point past the terminating '\0'.
Fix this by checking for *(input + 1) == '\0', and likewise add a unit test.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33754
Tom de Vries [Tue, 6 Jan 2026 21:44:31 +0000 (22:44 +0100)]
[gdb] Fix confusing string in command_line_append_input_line
While writing a unit test for PR33754, I ran into an std::string s where
where strlen (s.data ()) != s.size ().
I tracked this down to command_line_append_input_line, where we do:
...
/* Copy whole line including terminating null, and we're
done. */
cmd_line_buffer.append (rl, len + 1);
...
As example, consider string s:
...
std::string s = "";
s.append ("", 1);
...
Initially, the string is empty, and we have:
- strlen (s.data ()) == 0
- s.size () == 0
After appending '\0', we have:
- strlen (s.data ()) == 0
- s.size () == 1
While I suppose this is legal, I think it's better to avoid this type of
string, since it tends to cause confusion and off-by-one errors.
And AFAIU, in this case the '\0' is not necessary, it's a remnant of using C
strings.
Fix this by simply appending rl.
Approved-By: Tom Tromey <tom@tromey.com>
Tested on x86_64-linux.
I noticed that some places first check if a DIE has a
DW_AT_containing_type attribute, like so:
if (dwarf2_attr (type_die, DW_AT_containing_type, type_cu) == NULL)
return NULL;
and then call function die_containing_type, which does the same check,
erroring out if the attribute does not exist. The second check is
redundant in these cases. There is only one call site that does not do
a check before, for which the error might be relevant.
Remove the error call from die_containing_type, making it return nullptr
if the DIE does not have a DW_AT_containing_type attribute, and remove
the redundant checks in all but that one call site.
For that one call site, error out if the return value of
die_containing_type is nullptr. I changed the error message to be a
little more precise.
There is no expected behavior change, apart from the content of that
error message.
Change-Id: I99e89bd89d4fffef73f00e7ecc9d6ba11c0bd085 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Wed, 17 Dec 2025 15:54:59 +0000 (10:54 -0500)]
gdb: remove make_function_type
We now have make_function_type and lookup_function_type exposed by
gdbtypes.h, which do essentially the same thing. Remove
make_function_type, inlining its code inside create_function_type.
Change all other callers of make_function_type to use
lookup_function_type instead.
Change-Id: Id7c25f02059efe5c0f15e8ab8a35ac1fa97d9d6a Approved-By: Tom Tromey <tom@tromey.com>
paths, we create an allocator based on the return type, pass it down,
and create a type using that, which then gets passed to
make_function_type. Instead, we can let make_function_type allocate the
type based on the return type.
Change-Id: I3f38e2f4744ab664bd91b006b00501332df617b5 Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Mon, 8 Dec 2025 14:50:48 +0000 (07:50 -0700)]
Small cleanup to interpreter initialization
interp::inited is currently public, because interp_set does the task
of making sure the interpreter is only initialized a single time.
However, the interpreter can do this job itself, and this member can
be private.
Simon Marchi [Mon, 5 Jan 2026 20:38:18 +0000 (15:38 -0500)]
gdb: remove context_stack::static_link
I don't think it's needed to record this information in the
context_stack structure. The only user is the DWARF reader, where it
can very well be a local variable.
Change-Id: I6e33affbf03f11c0d0ab60067f169137fde1c994 Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 2 Jan 2026 18:34:36 +0000 (11:34 -0700)]
Simplify linespec.c:collect_info
I noticed that linespec has a subclass of collect_info that would be
easily replaced by a boolean. This patch cleans up this area by
removing the subclass, adding a constructor to collect_info, and
removing an unnecessary structure type used by it.
Tom de Vries [Tue, 6 Jan 2026 14:42:55 +0000 (15:42 +0100)]
[gdb/testsuite] Fix gdb.base/watchpoint-adjacent.exp with m32
PR testsuite/33727 reports the following failure with test-case
gdb.base/watchpoint-adjacent.exp and i686-linux (or, x86_64-linux and target
board unix/-m32):
...
(gdb) continue^M
Continuing.^M
watchpoint-adjacent-type_ll: watchpoint-adjacent.c:63: main: \
Assertion `(((uintptr_t) &obj.a) & 0x7) == 0' failed.^M
^M
Program received signal SIGABRT, Aborted.^M
0xb7fc5579 in __kernel_vsyscall ()^M
(gdb) FAIL: $exp: var_type=type_ll: test= a {a b} : rwatch_first=true: \
continue to breakpoint: prepare for read test
...
The problem is that the test-case expects 8-byte aligned data as an effect of
using long long, but long long has an alignment of 4 bytes [1].
Fix this by using __attribute__((aligned(8))).
After fixing this, we find one remaining failure. This has been filed as
PR breakpoints/33762.
Tested on x86_64-linux with target boards unix/-m64 and unix/-m32.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33727
Andrew Burgess [Thu, 27 Nov 2025 17:42:19 +0000 (17:42 +0000)]
gdb/dwarf: move subfile and symtab creation into dwarf2_cu method
There are two places in the dwarf2/ code where we create subfiles and
symtabs for the entries in a dwarf2_cu's line_header. The code in
each location is basically the same.
Move this code into a new dwarf2_cu member function.
In dwarf2/read.c the existing code had an additional task; this is
left in dwarf2/read.c in its own loop immediately after the call to
the new member function.
There should be no user visible changes after this commit.
Andrew Burgess [Wed, 24 Dec 2025 20:36:54 +0000 (20:36 +0000)]
gdb/dwarf: remove the line_header argument from dwarf2_start_subfile
As with the previous two commits, this commit removes the line_header
argument from dwarf2_start_subfile. This function already takes a
dwarf2_cu argument, and the line_header passed in is always the line
header pointed to by the dwarf2_cu argument, so lets just access the
line header through the dwarf2_cu.
As dwarf2_start_subfile relies on the dwarf2_cu always being non-NULL,
I've converted the dwarf2_cu argument from a pointer to a reference.
The alternative was adding an assert within dwarf2_start_subfile that
the pointer was not NULL.
There should be no user visible changes after this commit.
Andrew Burgess [Wed, 24 Dec 2025 20:24:53 +0000 (20:24 +0000)]
gdb/dwarf: remove m_line_header from lnp_state_machine class
Following on from the previous commit, this commit remove
m_line_header from the lnp_state_machine class. The lnp_state_machine
class already holds m_cu, a dwarf2_cu, and the m_line_header was
always just m_cu->line_header, so instead of holding both of these
separately, lets just hold m_cu, and access the line header through
that.
There should be no user visible changes after this commit.
I propose that we simplify the dwarf_decode_lines signature by
removing the line_header parameter. The same is true for
dwarf_decode_lines_1, which is only called from dwarf_decode_lines.
I'm proposing this change because I was looking through the DWARF
code, trying to understand how symtabs are created, and this extra
complexity just makes things harder to understand: what is the
relationship between the line_header (LH) and dwarf2_cu (CU)
parameters? When would we ever want to process a line_header other
than the one attached to CU? (answer: never, and we don't). This
simplification makes things easier to understand (IMHO).
There should be no user visible changes after this commit.
Indu Bhagat [Sat, 20 Dec 2025 04:29:34 +0000 (20:29 -0800)]
gas: dw2gencfi: reset reloc to TC_PARSE_CONS_RETURN_NONE for [su]leb128
Some consumers, like SFrame generation logic in GAS, may want to check
reloc value (without qualifying by e->type) as a part of their
admissibility criteria. Setting reloc to TC_PARSE_CONS_RETURN_NONE for
these CFI escape expr nodes for [su]leb128 keeps the admissibility
checks simple and generic.
Tom de Vries [Mon, 5 Jan 2026 20:56:55 +0000 (21:56 +0100)]
[gdb/testsuite] Fix gdb.python/py-corefile.py with m32
With target board unix/-m32 and test-case gdb.python/py-corefile.exp I run
into:
...
FAIL: $exp: test mapped files data: diff input and output one
...
due to differences like 0x0000000008048000 vs 0x08048000.
Fix this in gdb.python/py-corefile.py by detecting and handling the
ptr_size == 4 case.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR testsuite/33728
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33728
Simon Marchi [Mon, 5 Jan 2026 19:58:09 +0000 (14:58 -0500)]
gdb: remove mdebugread & al
After working on the "gdb: replace msym_bunch with deque" patch, I dug
into the history of the mdebug format, and have come to the conclusion
that it is time to remove that code.
ECOFF and mdebug were apparently relevant up to the mid 90s, after which
they were replaced with ELF and DWARF.
It was apparently possible to have mdebug-in-ELF, which is why elfread.c
calls into mdebugread.c, as well as stabs-in-mdebug(-in-ELF), which is
why mdebugread.c used to call into stabsread.c (following the stabs
removal, mdebugread.c now just errors out when encountering stabs).
Here are some pointers to understand the history of this:
- David Anderson's note about mdebug, which says "SGI moved on to
DWARF2 as its debugging format (as have nearly all modern compilers)"
[1] (modern likely meaning anything in the 2000s).
- Peter Rowell's (from Third Eye Software) post that explains the
history of what became mdebug [2][3].
- The ECOFF spec [4].
- A post on gcc-patches indicating that mdebug for Alpha was obsolete
in 2001 [5].
Simon Marchi [Fri, 19 Dec 2025 18:43:44 +0000 (13:43 -0500)]
gdb/buildsym: replace struct pending with std::vector
Replace `struct pending`, a home-made linked list of chunks of symbols,
with `std::vector<symbol *>`. This removes manual memory management and
simplifies the code.
The change starts by switching m_local_symbols, m_file_symbols and
m_global_symbols in buildsym_compunit to be vectors, and propagates from
there.
~buildsym_compunit no longer needs to manually free the lists (it did
not free m_local_symbols, was it on purpose?).
add_symbol_to_list just appends the symbol to the vector. Obviously,
this sometimes causes a vector reallocation, but it is amortized O(1)
and I did not find that it causes a performance degradation (more
details later). We could try to reserve some space in the vectors up
front if we had an estimate of how many entries we'll have, but I am not
sure we really can have a good idea up front.
collate_pending_symbols_by_language iterates the vector backwards to
keep the existing behavior. I am not sure if this is actually needed.
buildsym_compunit::push_context std::moves m_local_symbols, to avoid
copying the contents of the vector. I don't think
buildsym_compunit::pop_context needs to change, everything should be
efficient thanks to NRVO. Users of buildsym_compunit::pop_context use
std::move to move context_stack::locals back to m_local_symbols.
There is a non-trivial change in coff_read_enum_type, which I can't
test easily.
I did the following test to see if this change would have a performance
impact:
- I added a scoped_time_it in maintenance_expand_symtabs, to measure
just that step
- I use a build of blender compiled with "-O2 -g"
- I run:
$ ./gdb -q -nx --data-directory=data-directory -iex 'maint set dwarf sync on' -iex "maint set per-command time on" -ex "file /data1/smarchi/blender/build-RelWithDebInfo-gcc/bin/blender" -ex "maint expand windowmanager" -batch
- I record the time taken by maintenance_expand_symtabs
Before looks like:
Time for "maintenance_expand_symtabs": wall 34.311, user 32.335, sys 1.829, user+sys 34.164, 99.6 % CPU
Time for "maintenance_expand_symtabs": wall 34.208, user 32.265, sys 1.800, user+sys 34.065, 99.6 % CPU
Time for "maintenance_expand_symtabs": wall 34.420, user 32.378, sys 1.894, user+sys 34.272, 99.6 % CPU
After looks like:
Time for "maintenance_expand_symtabs": wall 34.316, user 32.342, sys 1.838, user+sys 34.180, 99.6 % CPU
Time for "maintenance_expand_symtabs": wall 34.318, user 32.347, sys 1.831, user+sys 34.178, 99.6 % CPU
Time for "maintenance_expand_symtabs": wall 34.357, user 32.272, sys 1.943, user+sys 34.215, 99.6 % CPU
I also measured the execution of the whole command (with "maint set
per-command time off" this time). Before looks like:
Tom Tromey [Mon, 5 Jan 2026 15:13:29 +0000 (08:13 -0700)]
Update copyright dates to include 2026
This updates the copyright headers to include 2026. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Tom Tromey [Thu, 11 Dec 2025 19:31:40 +0000 (12:31 -0700)]
Fix Ada 'Modulus attribute
The internal AdaCore test suite pointed out that my earlier patch to
displaying modular types broke the 'Modulus attribute -- it was
off-by-one.
While fixing this, though, I realized that the earlier 'ptype' problem
also affected this attribute. So, this patch implements a similar fix
in the parser.
This adds some operator+ overloads to gdb_mpz for convenience. That
class still doesn't have the full complement of operators -- they are
added as needed.
This patch adds support for PLB invalidate operation (PLBI) instruction
and the corresponding system registers as operand (<plbi_op>).
Syntax: PLBI <plbi_op>{, <Xt>}
This instruction is an alias to "SYS #<op1>, C10, <Cm>, #<op2>{, <Xt>}"
and PLBI being the preferred disassembly.
The following list of system registers are supported in this patch for the
PLBI instructions enabled by "+poe2" flag and also the "nxs" variants of
these system registers are enabled by "+poe2+xs" flag.
This patch adds support for FEAT_TEV feature enabled by "+tev"
flag along with support for following instructions.
* TENTER
* TEXIT
TENTER instruction uses the existing AARCH64_OPND_NOT_BALANCED_17 operand
to handle the not_balanced (NB) argument , where as a new operand
AARCH64_OPND_NOT_BALANCED_10 is added to support the NB (not_balanced)
argument in TEXIT instruction.
This patch adds support for POE2 system registers which are available
by default, however if guarding restrictions are enabled
using -menable-sysreg-checking than "+poe2" option need to specified
to the -march.
Co-authored-by: Matthew Malcomson <matthew.malcomson@arm.com>
A new operand AARCH64_OPND_NOT_BALANCED_17 is added to the code in this
patch to support the new optional argument "NB" (not_balanced) which
is a 1-bit field in the encoding for all the above mentioned
instructions.
Co-authored-by: Matthew Malcomson <matthew.malcomson@arm.com>
Tom Tromey [Tue, 16 Dec 2025 15:43:43 +0000 (08:43 -0700)]
Fix DAP 'disconnect' implementation
gdb's implementation of the DAP 'disconnect' request was incorrect in
a few ways.
First, the 'terminateDebuggee' field is optional, and has a special
meaning when not supplied: it should do whatever the default is.
Second, if the inferior was attached, it should detach rather than
terminate by default.
Finally, if the inferior was not started at all, it seems reasonable
for this request to simply succeed silently -- currently it returns
"success: false" with the reason being that the inferior isn't
running.
Alan Modra [Sat, 3 Jan 2026 03:26:01 +0000 (13:56 +1030)]
Set ELF_OSABI for x86 and sparc
The idea of this patch is to match the solaris target over other
targets if e_ident contains ELFOSABI_SOLARIS. The solaris target will
continue to recognise ELFOSABI_NONE objects.
This has the side effect of disabling gnu features that require
ELFOSABI_GNU, such as ifuncs. I think that is correct, so I've made
the required testsuite changes to fix the resulting regressions:
FAIL: nm --ifunc-chars (assembly)
FAIL: mbind sections without SHF_ALLOC
The patch also sets ELF_OSABI for the gnu x86 and sparc targets,
for the same reason as the solaris targets. This doesn't mean object
files will automatically be marked ELFOSABI_GNU/LINUX. As before that
will only happen when certain GNU extensions are present.
bfd/
* elf32-i386.c: Define ELF_OSABI for solaris and gnu targets.
* elf32-sparc.c: Likewise.
* elf64-sparc.c: Likewise.
* elf64-x86-64.c: Likewise.
* format.c (bfd_check_format_matches): Bump match_priority
for matching e_ident EI_OSABI.
binutils/
* testsuite/binutils-all/nm.exp: Use !supports_gnu_osabi to
disable ifunc test.
gas/
* testsuite/gas/elf/section13.d: Only run on supports_gnu_osabi
targets. Remove xfails.
Alan Modra [Sat, 3 Jan 2026 03:21:21 +0000 (13:51 +1030)]
ELF OSABI matching
Currently a binutils ELF target with ELF_OSABI defined to something
other than the default ELFOSABI_NONE will only accept object files
with e_ident[EI_OSABI] having the value ELF_OSABI. An ELF target with
ELF_OSABI as ELFOSABI_NONE will match any e_ident[EI_OSABI] value, and
typically that target's object files will have ELFOSABI_NONE or one
other value in e_ident[EI_OSABI]. Given an object file with that
"other value" we'd like to be able to choose the correct target but
currently have no way to do so. This patch is a step towards
implementing better target matching.
It does so by adding an ELF_OSABI_EXACT to the target description,
setting that true for all targets that currently define ELF_OSABI, and
testing the new flag for exact matching. This will allow a future
patch to define ELF_OSABI without forcing exact matching but giving a
hint as to the best target match.
Some other tweaks are done as shown by the changelog below but no
user functional changes should be seen with this patch.
* elf-bfd.h (struct elf_backend_data): Add osabi_exact.
* elf.c (_bfd_elf_final_write_processing): Only set e_ident
from elf_osabi when osabi_exact.
* elfcode.h (elf_object_p): Test osabi_exact to reject
mismatching e_ident. Remove unnecessary EM_NONE test.
* elfcore.h (elf_core_file_p): Likewise.
* elfxx-target.h (ELF_OSABI_EXACT): Provide default of 0,
and init elfNN_bed.
(elf_match_priority): Handle ELF_OSABI_EXACT.
* elf32-arm.c (ELF_OSABI_EXACT): Define and undef along with
ELF_OSABI.
* elf32-hppa.c: Likewise.
* elf32-i386.c: Likewise.
* elf32-mips.c: Likewise.
* elf32-ppc.c: Likewise.
* elf32-tic6x.c: Likewise.
* elf32-visium.c: Likewise.
* elf64-alpha.c: Likewise.
* elf64-hppa.c: Likewise.
* elf64-ia64-vms.c: Likewise.
* elf64-mips.c: Likewise.
* elf64-ppc.c: Likewise.
* elf64-sparc.c: Likewise.
* elf64-x86-64.c: Likewise.
* elfn32-mips.c: Likewise.
* elfnn-ia64.c: Likewise.
* elf32-msp430.c: Likewise. Don't define ELF_OSABI to
ELFOSABI_NONE.
Alan Modra [Sat, 3 Jan 2026 03:20:45 +0000 (13:50 +1030)]
elf_backend_data typedef
"const struct elf_backend_data" appears many places in the source,
and in some cases makes a line too long without wrapping. This patch
introduces a "typedef const struct elf_backend_data elf_backend_data;"
and uses it throughout binutils sources, with a few exceptions for c++
use of header files.
Alan Modra [Sat, 3 Jan 2026 03:13:50 +0000 (13:43 +1030)]
Compact elf_backend_data
* elf-bfd.h (struct elf_backend_data): Make arch, elf_osabi,
elf_machine_code and target_os bitfields, and reorder. Make
maxpagesize, minpagesize, commonpagesize and p_align unsigned
int.
* elfxx-target.h (elfNN_bed): Reorder to suit. Delete useless
comments.
Alan Modra [Sat, 3 Jan 2026 03:12:30 +0000 (13:42 +1030)]
ld/deffilep.y tidies
Formatting. Replace "sizeof (type)" with "sizeof (*varp)" where that
makes sense. Use xcalloc in place of xmalloc+memset. Don't special
case xrealloc of NULL pointer, xrealloc handles that fine.
Tom de Vries [Sat, 3 Jan 2026 15:10:41 +0000 (16:10 +0100)]
[gdb/testsuite] Fix gdb.base/local-env.exp on remote host
With host/target board local-remote-host-native.exp and other remote host
configurations, and test-case gdb.base/local-env.exp I get:
...
(gdb) show environment^M
...
(gdb) FAIL: $exp: show environment displayed variable
...
The test attempt to detect variable GDB_TEST_ENV_VAR in the environment, which
has been set with setenv.
This doesn't work with remote host, so declare the test unsupported. Likewise
in gdb.base/environ.exp.
Tom de Vries [Sat, 3 Jan 2026 15:06:29 +0000 (16:06 +0100)]
[gdb/testsuite] Fix gdb.base/gdb11531.exp with m32 PIE
With test-case gdb.base/gdb11531.exp and target board unix/-m32/-fPIE/-pie I get:
...
(gdb) next^M
34 myrec.x = 5;^M
(gdb) FAIL: gdb.base/gdb11531.exp: watchpoint variable triggers at next
...
For contrast, with target board unix/-m32 I get instead:
...
(gdb) next^M
^M
Hardware watchpoint 2: myrec.x^M
^M
Old value = 0^M
New value = 5^M
main () at /data/vries/gdb/src/gdb/testsuite/gdb.base/gdb11531.c:35^M
35 myrec.y = 3.4;^M
(gdb) PASS: gdb.base/gdb11531.exp: watchpoint variable triggers at next
...
The problem is that the runto_main doesn't set a breakpoint on the same line
in both cases.
Fix this by using runto "$srcfile:34".
[ The underlying problem here is the failure of prologue analysis to deal with
get_pc_thunk. But since there's a PR [1] open about this, and the problem is
unrelated to the test-case, we work around it. ]
Tom de Vries [Sat, 3 Jan 2026 15:04:41 +0000 (16:04 +0100)]
[pre-commit] Move codespell-log back to commit-msg stage
Commit 7acd390ffd9 ("[pre-commit] Move codespell-log to post-commit") moved
the codespell-log hook from the commit-msg to the post-commit stage.
This was deemed to make git rebase too slow [1], so move it back to the
commit-msg stage. Don't do this using a full revert, to keep unrelated
improvements from that commit.
Since we use codespell-log to produce warnings rather than errors, running the
hook at the commit-msg stage requires us to ignore codespell exit status, and
set verbose=true.
Tom de Vries [Sat, 3 Jan 2026 15:01:25 +0000 (16:01 +0100)]
[gdb/testsuite] Fix another timeout in gdb.mi/mi-multi-commands.exp
On aarch64-linux, with a gdb version 16.3 based package, I ran into (edited
for readability):
...
(gdb)
<LOTS-OF-SPACES>-data-evaluate-expression $a
^done,value="\"FIRST COMMAND\""
(gdb) -data-evaluate-expression $b
^done,value="\"TEST COMPLETE\""
(gdb)
PASS: $exp: look for first command output, command length $n
FAIL: $exp: look for second command output, command length $n (timeout)
...
For contrast, a passing example looks like:
...
(gdb)
<LOTS-OF-SPACES>-data-evaluate-expression $a
-data-evaluate-expression $b
^done,value="\"FIRST COMMAND\""
(gdb)
PASS: $exp: look for first command output, command length $n
^done,value="\"TEST COMPLETE\""
(gdb)
PASS: $exp: look for second command output, command length $n
...
The setup is that the test-case issues these two commands at once:
...
-data-evaluate-expression $a
-data-evaluate-expression $b
...
where the length of the first command is artificially increased by prefixing
it with spaces, shown as <LOTS-OF-SPACES> above.
What happens is that gdb, after parsing the first command, executes it, which
generates output and a prompt. Then that prompt intermixes with the echoing
of the second command, and consequently the matching of the prompt fails.
This is very similar to what was fixed in commit 59c9bc5fb6c ("[gdb/testsuite]
Fix timeout in gdb.mi/mi-multi-commands.exp").
Fix this by making the matching of the first prompt optional.
While we're at it, make the test-case more readable using {}, string_to_regexp
and multi_line_input.
Alan Modra [Thu, 1 Jan 2026 21:52:02 +0000 (08:22 +1030)]
Solaris .strtab and .shstrtab flags
These sections have SHF_STRINGS in sh_flags on Solaris. Commit 84865015459b in part implemented this variation by an elf_backend_data
field used to set the flags, but that only works of course if one of
the solaris targets is used. Which in some ways is fair enough. If
you want solaris support then it is reasonable to require the solaris
targets to be compiled in. However if they are not the default, other
ELF targets may be used even when the solaris targets are compiled in,
because many ELF targets allow any ELFOSABI object to match. (Which
is arguably a bug.)
So instead of the current scheme this patch implements the solaris
specific sh_flags in _bfd_elf_final_write_processing. That way either
a solaris target being used, or ELFOSABI_SOLARIS in the object will
get the correct sh_flags.
Alan Modra [Thu, 1 Jan 2026 21:51:31 +0000 (08:21 +1030)]
gas .xstabs missing string results in a segfault
Found by oss-fuzz.
* stabs.c (s_xstab): Check result of demand_copy_C_string.
(s_stab_generic): Remove duplicate warning and ignore_r_o_l
after demand_copy_C_string error.
Alan Modra [Thu, 1 Jan 2026 21:51:16 +0000 (08:21 +1030)]
ld config targ_extra_emuls and targ_extra_libpath
There is no need to duplicate targets in these variables, one or the
other is sufficient. This patch removes such duplication but
otherwise makes no user visible changes. Quite likely some targets
ought to be in targ_extra_emuls rather than targ_extra_libpath.
* configure.tgt: Don't duplicate targ_extra_libpath targets
in targ_extra_emuls, and similarly for targ64 variants.
Alan Modra [Thu, 1 Jan 2026 12:25:19 +0000 (22:55 +1030)]
Update year range in copyright notice of binutils files
Avoid warnings about invalid escapes in etc/update-copyright.py by
using raw strings, add BinutilsFilter to skip psql.rc and add
"Kalray SA." as another copyright holder.
Alice Carlotti [Sat, 27 Dec 2025 18:26:26 +0000 (18:26 +0000)]
aarch64: Remove a space from movaz za operand
The za operands of most movaz instructions were originally printed with
an extra space compared to other za operands. Remove this space, and
reduce code duplication in the process.
Alice Carlotti [Sat, 27 Dec 2025 20:46:25 +0000 (20:46 +0000)]
aarch64: Accept .b/.h/.s in movaz (array to vector)
While the .d form is preferred for disassembly, assemblers should accept
any element size that is used consistently. The sme2_mov class handles
this already for mov instructions, so use that here as well.
Alice Carlotti [Sat, 27 Dec 2025 14:43:40 +0000 (14:43 +0000)]
aarch64: Fix luti2/luti4 decode mask
Neither the opcode mask nor the size determination were checking bit 13,
so some undefined opcodes were being incorrectly disassembled as valid
luti2/luti4 instructions.
Rainer Orth [Mon, 29 Dec 2025 10:16:04 +0000 (11:16 +0100)]
bfd: Re-enable 64-bit support for 32-bit Solaris targets
One of the recent Solaris patches removed want64=true from the 32-bit
Solaris targets. This breaks GCC bootstrap: unlike Linux, GCC on
Solaris is always biarch, both in 32-bit-default and 64-bit-default
configurations, so the 64-bit multilib fails to build.
This patch undoes this incompatible change.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11.
Sivan Shani [Wed, 17 Dec 2025 16:58:52 +0000 (16:58 +0000)]
AArch64: Add FEAT_F16F32MM
This patch includes:
- The feature flag for the FEAT_F16F32MM feature.
- Instruction FMMLA Half-precision matrix multiply-accumulate to single-precision.
Sivan Shani [Wed, 17 Dec 2025 16:36:54 +0000 (16:36 +0000)]
AArch64: Add FEAT_F16F32DOT instructions
This includes the instructions for the F16F32DOT feature:
- FDOT half-precision to single-precision, by element
- FDOT half-precision to single-precision, vector
In addition, new operands:
- OPND_SME_Zmx2_INDEX_22: an operand represents a list of vector registers with an index.
- OPND_SME_Zn7xN_UNTYPED: an operand represents an untyped list of vector registers.
Alan Modra [Fri, 26 Dec 2025 00:26:15 +0000 (10:56 +1030)]
Re: bfd ASSOCIATED_VECS
What I committed in f4e835a40c wasn't wrong but it wasn't elegant.
Unlike looking for a word separated by spaces, it isn't necessary
to prepend and append the separators in the match string.
Alan Modra [Thu, 25 Dec 2025 11:47:10 +0000 (22:17 +1030)]
PR 33726, symbols in excluded sections
This improves "nearby" section choice when memory regions are active,
preferring a section in the same region as the excluded section over
other sections.
The problem lies in existence of "freestanding" code, a code that is
part of a CU but does not have any block associated with it. Consider
following program:
int main(int argc, char **argv) {
return foo(argc);
}
When compiled, the foo function has no block of itself:
Blockvector:
no map
block #000, object at 0x55978957b510, 1 symbols in 0x1129..0x1148
int main(int, char **); block object 0x55978957b380, 0x112d..0x1148 section .text
block #001, object at 0x55978957b470 under 0x55978957b510, 2 symbols in 0x1129..0x1148
typedef int int;
typedef char char;
block #002, object at 0x55978957b380 under 0x55978957b470, 2 symbols in 0x112d..0x1148, function main
int argc; computed at runtime
char **argv; computed at runtime
In this case lookup(0x1129) returns static block and, because of the
change in cc1fc6af4, contains(0x1129) which is wrong.
Such "freestanding" code is perhaps not common but it does exist,
especially in system code. In fact the regressions were at least in part
caused by such "freestanding" code in glibc (libc_sigaction.c).
The whole idea of commit cc1fc6af4 was to handle "holes" in CUs, a case
where one CU spans over multiple disjoint regions, possibly interleaved
with other CUs. Consider somewhat extreme case with two CUs:
This when compiled with a carefully crafted linker script to force code
at certain positions, creates following layout:
0x080000..0x080007 # "freestanding" bar from hole-2.c
0x080008..0x080016 # give_me_zero() from hole-2.c
0x080109..0x080114 # main from hole-1.c
0xf00000..0xf0000b # baz() from hole-2.c
0xf0000b..0xf00011 # "freestanding" foo from hole-2.
0xf0000b..0xf0001c # gice_me_one() from hole-2.
The block vector for hole-1.c looks:
Blockvector:
no map
block #000, object at 0x555a5d85fb90, 1 symbols in 0x80109..0x80114
int main(void); block object 0x555a5d85faa0, 0x80109..0x80114 section .text
block #001, object at 0x555a5d85faf0 under 0x555a5d85fb90, 1 symbols in 0x80109..0x80114
typedef int int;
block #002, object at 0x555a5d85faa0 under 0x555a5d85faf0, 0 symbols in 0x80109..0x80114, function main
block #000, object at 0x555a5d8603b0, 3 symbols in 0x80008..0xf0001d
int give_me_zero(void); block object 0x555a5d85ff50, 0x80008..0x80016 section .text
int give_me_one(void); block object 0x555a5d860110, 0xf00012..0xf0001d section .text
int baz(void); block object 0x555a5d860280, 0xf00000..0xf0000b section .text
block #001, object at 0x555a5d8602d0 under 0x555a5d8603b0, 1 symbols in 0x80008..0xf0001d
typedef int int;
block #002, object at 0x555a5d85ff50 under 0x555a5d8602d0, 0 symbols in 0x80008..0x80016, function give_me_zero
block #003, object at 0x555a5d860280 under 0x555a5d8602d0, 0 symbols in 0xf00000..0xf0000b, function baz
block #004, object at 0x555a5d860110 under 0x555a5d8602d0, 0 symbols in 0xf00012..0xf0001d, function give_me_one
Note that despite the fact "freestanding" bar belongs to hole-2.c, the
corresponding CU's global and static blocks start at 0x80008! Looking
at DWARF for the second program, it looks like that the compiler (GCC 15)
did not record the presence of "freestanding" code:
Thiago suggested to use minsymbols to tell whether or a CU contains
given address. I do not think this would work reliably as minsymbols do
no know to which CU they belong. In slightly more complicated case of
interleaved CUs it does not seem to be possible to tell for sure to which
one a given minsymbol belongs.
Moreover, Tom suggested that the comment in find_compunit_symtab_for_pc_sect
(which led to cc1fc6af4) may be outdated [2].
projects / thirdparty / binutils-gdb.git / log
