Sunil Dora [Tue, 24 Mar 2026 16:45:27 +0000 (09:45 -0700)]
gdb/ser-unix: add POSIX cfsetispeed/cfsetospeed support for custom baud rates
glibc 2.42 and later, and GNU Hurd, accept arbitrary baud rates
directly via cfsetispeed and cfsetospeed. This behaviour is expected
to be standardized in a future POSIX revision.
Introduce a configure-time test (HAVE_CFSETSPEED_ARBITRARY) that
detects this capability and add a new platform-agnostic helper
set_custom_baudrate_posix. The main dispatcher now prefers the POSIX
path when it is available, falling back to the existing Linux (BOTHER)
or Darwin (IOSSIOSPEED) implementations otherwise.
The HAVE_CUSTOM_BAUDRATE_SUPPORT guard is extended to also cover the
new POSIX case.
Suggested-by: Kevin Buettner <kevinb@redhat.com> Suggested-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-by: Kevin Buettner <kevinb@redhat.com>
Sunil Dora [Tue, 24 Mar 2026 16:45:26 +0000 (09:45 -0700)]
gdb/ser-unix: fix musl build failure when setting custom baud rates
On musl-based systems, <asm/termbits.h> may expose BOTHER even though
struct termios does not define c_ispeed/c_ospeed. This causes the
Linux-specific custom baud rate path to be compiled and fail to build.
Fix the problem at the macro level by requiring
HAVE_STRUCT_TERMIOS_C_OSPEED (obtained via AC_CHECK_MEMBERS) together
with BOTHER in the HAVE_CUSTOM_BAUDRATE_SUPPORT guard. This prevents
the Linux-specific code from being compiled on musl while leaving
set_custom_baudrate_linux unchanged.
This is a pure build fix with no functional or behavioural change on
any existing platform.
Suggested-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com> Approved-by: Kevin Buettner <kevinb@redhat.com>
Tom de Vries [Sat, 18 Apr 2026 09:54:01 +0000 (11:54 +0200)]
[gdb/build] Fix Wunused-variable in selftests::test_enumerate
On openSUSE Leap 15.6, with gcc 7.5.0, I ran into:
...
enumerate-selftests.c: In function 'void selftests::test_enumerate()':
enumerate-selftests.c:85:22: error: \
unused variable 'i' [-Werror=unused-variable]
for (auto [i, val] : gdb::ranges::views::enumerate (vec))
^
cc1plus: all warnings being treated as errors
...
Simon Marchi [Sat, 18 Apr 2026 02:41:52 +0000 (22:41 -0400)]
gdbsupport: remove iteration_status_str
When building with g++ 8 (on Alma Linux 8), we get:
CXX ada-exp.o
In file included from /binutils-gdb/gdb/../gdbsupport/array-view.h:24,
from /binutils-gdb/gdb/../gdbsupport/common-utils.h:27,
from /binutils-gdb/gdb/../gdbsupport/common-defs.h:214,
from /binutils-gdb/gdb/defs.h:26,
from <command-line>:
/binutils-gdb/gdb/../gdbsupport/iteration-status.h: In function ‘constexpr const char* iteration_status_str(iteration_status)’:
/binutils-gdb/gdb/../gdbsupport/gdb_assert.h:43:22: error: call to non-‘constexpr’ function ‘void internal_error_loc(const char*, int, const char*, ...)’
internal_error_loc (__FILE__, __LINE__, _("%s: " message), __func__, \
~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
##__VA_ARGS__)
~~~~~~~~~~~~~~
/binutils-gdb/gdb/../gdbsupport/iteration-status.h:45:3: note: in expansion of macro ‘gdb_assert_not_reached’
gdb_assert_not_reached ("invalid iteration_status value");
^~~~~~~~~~~~~~~~~~~~~~
It turns out that iteration_status_str isn't used, it apparently was
only used transiently in my series. Remove it to fix the build failure.
Andrew Burgess [Wed, 15 Apr 2026 09:43:31 +0000 (10:43 +0100)]
gdb: don't use .text as default entry point section
We got a Fedora GDB bug report that a user tried to debug an Appimage,
and GDB would reliably crash like this:
(gdb) run
Starting program: /tmp/build/gdb/testsuite/outputs/gdb.base/solib-bad-entry-addr/solib-bad-entry-addr
../../src/gdb/symfile.c:843: internal-error: sect_index_text not initialized
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
... etc ...
The specific AppImage being debugged can be found here, I've modified
the URL with a warning marker. I make no claims about whether it is
safe to download the image, and running it is definitely at your own
risk. If you wish to, delete the warning marker to download:
https://github.com/Murmele/Gittyup/<RUN AT YOUR OWN RISK>/releases/download/gittyup_v1.4.0/Gittyup-1.4.0-x86_64.AppImage
At the point of the above crash GDB's stack is:
#9 0x000000000190c6ed in internal_error_loc (file=0x1e4a94e "../../src/gdb/symfile.c", line=838, fmt=0x1e4aa50 "sect_index_text not initialized") at ../../src/gdbsupport/errors.cc:57
#10 0x0000000000f5f5ac in init_entry_point_info (objfile=0x5a98e80) at ../../src/gdb/symfile.c:838
#11 0x0000000000f5f943 in syms_from_objfile (objfile=0x5a98e80, addrs=0x7ffd78728490, add_flags=...) at ../../src/gdb/symfile.c:962
#12 0x0000000000f5fe6d in symbol_file_add_with_addrs (abfd=..., name=0x3e76e50 "/tmp/.mount_GittyujmIBkD/usr/bin/../../home/runner/work/Gittyup/Qt/5.15.2/gcc_64/lib/./libicudata.so.56", add_flags=..., addrs=0x7ffd78728490, flags=..., parent=0x0) at ../../src/gdb/symfile.c:1071
#13 0x0000000000f601aa in symbol_file_add_from_bfd (abfd=..., name=0x3e76e50 "/tmp/.mount_GittyujmIBkD/usr/bin/../../home/runner/work/Gittyup/Qt/5.15.2/gcc_64/lib/./libicudata.so.56", add_flags=..., addrs=0x7ffd78728490, flags=..., parent=0x0) at ../../src/gdb/symfile.c:1145
#14 0x0000000000f0f2ad in solib_read_symbols (so=..., flags=...) at ../../src/gdb/solib.c:627
#15 0x0000000000f10263 in solib_add (pattern=0x0, from_tty=0, readsyms=1) at ../../src/gdb/solib.c:960
From this we can see GDB is trying to add the shared library:
1. There really is no .text section, or any executable sections,
2. there are 3 LOAD segments. This will be important later, and
3. the "Entry point address" is outside all sections, and is
non-zero.
Next we can investigate where objfile::sect_index_text is set to
something other than -1. Starting in init_objfile_sect_indices, if
the objfile has a ".text" section then sect_index_text can be set.
This case clearly doesn't apply.
Next symfile_find_segment_sections is called. This tries to match a
common case where we have either 1 or 2 LOAD segments, and assumes a
default distribution of sections to segments. However, we have 3 LOAD
segments, so these lines:
result in an early return from symfile_find_segment_sections without
sect_index_text being set.
Back in init_objfile_sect_indices, if no sections have an offset then
we set any currently unset sect_index_* values, including
sect_index_text, to point at section 0. However, in our case the
objfile is a relocatable shared library, so the sections will have an
offset, and so this final fallback case doesn't apply.
The result is that init_objfile_sect_indices never sets
sect_index_text. This worries me a little as
init_objfile_sect_indices contains this comment:
/* This is where things get really weird... We MUST have valid
indices for the various sect_index_* members or gdb will abort.
So if for example, there is no ".text" section, we have to
accommodate that. First, check for a file with the standard
one or two segments. */
Notice the emphasis on MUST in that comment, and indeed, we exit this
function without setting sect_index_text, and GDB does indeed abort.
The comment seems to imply that the following code is going to try to
figure out a suitable stand-in sect_index_text for when there is no
".text" section, but clearly I've run into a case that isn't covered.
All of this code relating to setting sect_index_text was introduced in
commit:
Which unfortunately is from a time where we didn't write useful commit
messages, so to understand the commit you need to go read the mailing
list archive, but they don't offer much more insight:
Clearly the comment in init_objfile_sect_indices would suggest that
the fix here is to figure out some "fake" value for sect_index_text,
and that would certainly avoid the problem here. But, at least for
this problem, I think there's maybe a better solution.
The original internal error is triggered by a use of SECT_OFF_TEXT in
init_entry_point_info. We have an entry point address, we try to find
the section index for the section containing the entry point, and
failing that, we assume the entry point is in the text section. This
fall-back assumption means that, if the text section has an offset
applied, then the entry point will also have that same offset
applied. But it's not clear to me why picking the text section is
going to be any more valid than any other section, especially in a
case like this where we don't even have a text section, so the
sect_index_text might itself point to some other arbitrary section.
Earlier in init_entry_point_info we already have a fall-back case
where we set entry_info::entry_point_p to false to indicate that the
objfile has no entry point, so this is always a possibility. So I
wondered about writing something like:
if (!found)
{
if (objfile->sect_index_text != -1)
ei->the_bfd_section_index = SECT_OFF_TEXT (objfile);
else
ei->entry_point_p = false;
}
If we have no text section index then we just claim the objfile has no
entry point. But I didn't like this for two reasons, first, the
comment back in init_objfile_sect_indices saying that the index should
be set, this seems to indicate that we should not be making decisions
later within GDB based on whether the index is set or not.
And second, using the text section as a fall back, when the entry
address is outside every section, just seems off. So I wondered, why
not just reject the entry point completely in this case? Which is how
I ended up with:
if (!found)
ei->entry_point_p = false;
With this patch in place I was able to start debugging the AppImage
linked above.
I created a simple test case which reproduces this issue. It's a
little contrived because it has to hit all the points required to
trigger this bug:
1. No .text section,
2. more than 2 LOAD segments, and
3. entry address outside every section.
I have no idea what caused the original shared library to take on
these characteristics, it might even be a tool issue building the
original shared library. I haven't investigated this, as I don't
think it really matters, GDB shouldn't be crashing just because the
incoming objects are a little weird.
I've attached a link to the Fedora bug in the 'Bug:' tag, but it's a
little confusing. An automated system has merged together two bug
reports. As such the overall bug report linked too is for a
completely different issue, only comments 21, 22, 23, and 24 relate to
the bug being fixed here.
Andrew Burgess [Wed, 15 Apr 2026 09:42:03 +0000 (10:42 +0100)]
gdb: int to bool in struct entry_info
Convert 'struct entry_info' to use bool for flag fields. The places
where these flags are set are updated too. I have also removed the
bit width specifier ": 1" from the flag field definitions. There is
one entry_info struct per BFD in GDB, which is not a huge number, so
forcing the bool fields to 1-bit doesn't seen necessary.
There should be no user visible changes after this commit.
Simon Marchi [Thu, 16 Apr 2026 20:16:21 +0000 (16:16 -0400)]
gdb: make iterate_over_symbols return void, rename to for_each_symbol
Nothing really uses the return value of iterate_over_symbols and
language::iterate_over_symbols. Also, all provided callback always
return true, iterating on all matching symbols. Simplify them to not
return a value and not have the "stop iterating" feature.
Rename to for_each_symbol, just to be consistent with previous patches.
Also rename symbol_found_callback_ftype to
for_each_symbol_callback_ftype for consistency.
Change-Id: I55ff3162098bb069dc1de1afca10dd9abfc05c34 Approved-By: Andrew Burgess <aburgess@redhat.com>
Simon Marchi [Thu, 16 Apr 2026 20:16:19 +0000 (16:16 -0400)]
gdb: change objfile::map_symtabs_matching_filename to find_symtab_matching_filename
The only user of objfile::map_symtabs_matching_filename uses that method
to find the first matching symtab. It would therefore be more natural
for that method to be a "find" method, returning the first symtab
matching the predicate.
Change map_symtabs_matching_filename to be
find_symtab_matching_filename, and the internal
iterate_over_one_compunit_symtab to be find_symtab_in_compunit_symtab.
This makes function find_symtab simpler.
Change-Id: Id14a95498fad243495d6eab18810d0c4ab8dbf90 Approved-By: Andrew Burgess <aburgess@redhat.com>
Simon Marchi [Fri, 17 Apr 2026 14:30:23 +0000 (10:30 -0400)]
gdb: split iterate_over_symtabs into for_each_symtab and find_symtab
Same rationale as the previous patches.
For the moment, find_symtab is only needed internally in symtab.c, so
keep it static there. Note that the interaction with
objfile.map_symtabs_matching_filename gets cleaner in a subsequent
patch.
for_each_symtab is implemented using find_symtab, because the iteration
behavior is not completely trivial.
find_symtab_callback_ftype is in the header file, because it is used
from another source file in the next patch.
Change-Id: I6ab8342151eb735327fc2e7935e7a65cede5e1dd Approved-By: Andrew Burgess <aburgess@redhat.com>
Simon Marchi [Thu, 16 Apr 2026 20:16:16 +0000 (16:16 -0400)]
gdb: split iterate_over_threads into for_each_thread and find_thread
Same rationale as the previous patch, I think the code would be clearer
and simpler with separate "for each" and "find" functions rather than
one that does both jobs.
No need for the callbacks of the "for each" function to return anything,
as none of them needs to interrupt the iteration.
Change-Id: I4b7bcc5e9a319369d75a22b11114e943951e546a Approved-By: Andrew Burgess <aburgess@redhat.com>
Simon Marchi [Thu, 16 Apr 2026 20:16:15 +0000 (16:16 -0400)]
gdb, gdbserver: split iterate_over_lwps into for_each_lwp and find_lwp
Even though it works, I have always been mildly annoyed by
iterate_over_lwps being used for both iterating over all lwps and
finding one lwp matching a criterion. I think it would be clearer to
have two functions for the two use cases. Then it would be 100% clear
at the call site what the intention is. It would be clear that a
callback returning bool is meant to be a predicate for the find
function, while a callback returning void is meant to be a callback for
the "for each" function.
Therefore, split iterate_over_lwps in two:
- find_lwp to find the first lwp matching a boolean predicate (and the
given ptid filter)
- for_each_lwp to apply a function on all lwps (optionally filtering by
ptid or pid)
The callbacks given to for_each_lwp can now return void.
Introduce some overloads for for_each_lwp, for the various common use
cases:
- filtering by ptid
- filtering by pid
- no ptid/pid filter
find_lwp and two overloads of for_each_lwp are actually only used in
gdb/linux-nat.c, so make them local to that file. Only the pid variant
of for_each_lwp is used in shared code.
The pattern used in this patch serves as the basis for subsequent
patches that split other "iterate over" functions the same way.
Change-Id: I49d3af0916622300cc81e3c32d22e1aff13cf38f Approved-By: Andrew Burgess <aburgess@redhat.com>
Simon Marchi [Thu, 16 Apr 2026 20:16:13 +0000 (16:16 -0400)]
gdb: introduce iteration_status enum, use it for search callbacks
There are a bunch of iteration functions that take a callback returning
true or false to indicate whether to continue or stop iterating. These
functions then return the same value, indicate whether the iteration was
done until the end of interrupted. I think this is confusing and
error-prone, as I never know which value means what. It is especially
confusing when two opposite conventions collide, such as in
objfile::map_symtabs_matching_filename.
I propose to make that more obvious by introducing a new
iteration_status enum with self-documenting values.
I started to change the callback type
compunit_symtab_iteration_callback, taken by
quick_symbol_functions::search, and then followed that path to update a
bunch of other functions.
I chose the name to be kind of generic, so that it can be used for other
similar iteration patterns. I also put it in gdbsupport, in case we
want to use it in gdbserver too.
Change-Id: I55d84d0c1af8ac0b82cc9f49ccf0d6b60e1769e0 Approved-By: Andrew Burgess <aburgess@redhat.com>
I think that the name search_symtabs_expansion_listener function type
no longer makes sense for the following reasons:
- Since we have both `symtab` and `compunit_symtab` structs, I like
when we are specific about which one we're talking about. In this
case, the callback takes a `compunit_symtab`.
- Following series "Search symbols via quick API" [1] last year (I
believe commit f88f9f42db8 ("Have expand_symtabs_matching work for
already-expanded CUs")), the callback gets called for all matching
compunit_symtabs, not just those that get expanded.
I therefore propose to rename it to compunit_symtab_iteration_callback.
I chose "callback" over "listener", because I think that listener
implies that there is some event happening, that we listen for. That
made sense before where we would listen for the "expansion" event. But
now since it just gets called back for all matching CUs, I think that
"callback" makes more sense.
This test currently fails on PowerPC due to architectural differences
in function return handling.
On PowerPC64 ELFv2, calls to external functions are followed by a
`nop` instruction that serves as a placeholder for TOC pointer
restoration. Since this `nop` typically has no DWARF line entry,
`finish` reports the call line instead of the next line.
The fix proposed there was to add a PowerPC specific check so that the
test would send a `next` command after using `finish` to advance to
the expected source line.
This commit actually takes a more general approach. After calling
`finish` we check which line we ended up on. If it was the caller
line then we send GDB a `next` to move to the expected line. If we
arrive directly at the next line, then no `next` is needed.
I've tested this change on x86-64, where no `next` is needed, and
PowerPC, where `next` is now used as required to get the test
passing.
To simplify the pattern matching in the exp file, I tweaked the source
file slightly. But adding a call to a dummy 'func5' it's now easy to
pattern match as we step through 'func1', 'func2', etc.
Jan Beulich [Fri, 17 Apr 2026 06:06:39 +0000 (08:06 +0200)]
x86: refine special casing of insns with MSR as immediate
PR gas/34028
i.op[].imms is legitimate to de-reference only when the operand actually
is an immediate. The pointer happens to be non-NULL for most other operand
kinds (i.e. a deref is UB, but would likely not fault), just not for
memory operands without displacement.
Leverage that the to-be-special-cased insns all only have just a single
immediate, and leverage further that after the immediately preceding
swapping of operands valid immediates will come first. Hence the
conditional can be adjusted to satisfy the criteria above, and no loop is
needed at all.
With the conditional changed, leverage the property also in optimize_imm()
itself, reducing the number of loop iterations.
Add a "enumerate" utility, that acts pretty much like Python's
enumerate(). It makes the code slightly nicer, for when you would
otherwise need to handle the counter by hand.
It can be used like this:
std::vector<int> my_vector;
for (auto [i, val] : gdb::ranges::views::enumerate (my_vector))
...
`i` will hold the 0-based index of the current iteration, and `val` will
be a reference to the value of the current iteration.
The name is chosen to match std::ranges::views::enumerate from C++23,
making it easy to switch to that eventually.
An #undef seems to have sneaked into gdbsupport/scoped_signal_handler.h.
This causes the HAVE_SIGACTION macro to be cleared unintentionally.
Remove the line.
While working on commit 391c4026573 ("[gdb] Simplify debuginfod_is_enabled") I
noticed this Wstringop-overread workaround:
...
url_view = url_view.substr (off);
/* g++ 11.2.1 on s390x, g++ 11.3.1 on ppc64le and g++ 11 on
hppa seem convinced url_view might be of SIZE_MAX length.
And so complains because the length of an array can only
be PTRDIFF_MAX. */
DIAGNOSTIC_PUSH
DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD
off = url_view.find_first_of (' ');
DIAGNOSTIC_POP
...
I had difficulty understanding how the warning got triggered, and why it was
ok to ignore it, so I investigated this and ended up filing a gcc PR [1].
While doing so, I realized that this:
...
- url_view = url_view.substr (off);
+ url_view = url_view.substr (off, PTRDIFF_MAX);
...
is a simpler workaround, that:
- is not specific to the warning and also
- states explicitly what the assumption is we're making.
I ended up using this instead to make the workaround part more minimal:
...
url_view = url_view.substr (off);
+ url_view = url_view.substr (0, PTRDIFF_MAX);
off = url_view.find_first_of (' ');
...
The gcc PR got closed because it's supposed to be fixed in 12.1, so the
workaround is enabled only for g++ < 12.1.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124879
Following Simon Marchi's fix for dw2-empty-inline-ranges.exp [1], this
test exhibits the same failure pattern when running in an environment
where GDB can't disable address space randomization (such as in a
container where that capability is removed) with a toolchain generating
position-independent executables.
The test does a first run to grab addresses of labels and function
boundaries (foo_middle, foo_start, foo_end, and range labels). It then
crafts DWARF using these addresses across multiple test iterations.
When the executable is PIE and ASLR is active, the addresses in each
subsequent run don't match the addresses from the initial run.
The failure manifests in the 'maint info blocks' output comparisons,
where the expected addresses (from the first run) don't match the
actual addresses in the test runs.
The simplest fix, following Simon's approach, is to use "nopie" when
building the binaries. This doesn't affect the effectiveness of the
test, which is exercising different ways DW_AT_entry_pc can be
expressed in DWARF.
Also, with a non-PIE executable, it is no longer necessary to run the
inferior before grabbing the addresses in the initial run, as they are
stable. So remove that runto_main call.
Tom de Vries [Tue, 14 Apr 2026 20:45:23 +0000 (22:45 +0200)]
[gdb/symtab] Add find_symbol_for_pc_maybe_inline
We have function find_symbol_for_pc:
...
find_symbol_for_pc (CORE_ADDR pc)
{
return find_symbol_for_pc_sect (pc, find_pc_mapped_section (pc));
}
...
which uses some standard way of getting the section for the given pc.
Add a similar function find_symbol_for_pc_maybe_inline that calls
find_symbol_for_pc_sect_maybe_inline, and use it in jump_command.
Andrew Burgess [Tue, 14 Apr 2026 20:36:09 +0000 (22:36 +0200)]
gdb: use get_current_frame consistently in print_stop_location
In print_stop_location, in the PRINT_UNKNOWN case we currently use a
strange mix of get_current_frame and get_selected_frame. This works
fine because at the point print_stop_location is called the selected
frame will always be the current frame, but calling these two
different functions is confusing, at least for me.
Since bpstat_print selects the frame to print (which usually is the current
frame, but not always), the correct frame to use is the selected frame after
the bpstat_print call.
Assign the selected frame to a variable print_frame, and use it throughout the
function.
There should be no user visible changes after this commit.
Co-Authored-By: Tom de Vries <tdevries@suse.de> Approved-By: Andrew Burgess <aburgess@redhat.com>
we change the 36/0x401165 entry into a 37/0x401165 entry:
...
File name Line number Starting address View Stmt
dw2-extend-inline-block.c 34 0x401116 x
dw2-extend-inline-block.c 35 0x401129 x
dw2-extend-inline-block.c 26 0x401138 x
dw2-extend-inline-block.c 27 0x401147 x
dw2-extend-inline-block.c 28 0x401156 x
dw2-extend-inline-block.c 36 0x401156
-dw2-extend-inline-block.c 36 0x401165
+dw2-extend-inline-block.c 37 0x401165
dw2-extend-inline-block.c 37 0x401174 x
dw2-extend-inline-block.c 38 0x401183 x
dw2-extend-inline-block.c 39 0x401192 x
dw2-extend-inline-block.c 40 0x4011a1 x
dw2-extend-inline-block.c - 0x4011b7
...
As it happens, the fix to extend truncated inlined function blocks
doesn't work in this case. This is PR gdb/33930.
We can work around this by making sure that the inlined function block
isn't truncated in the first place:
What happens is that the slightly different line program triggers a
different stepping path, which includes a case of "stepped to a
different frame, but it's not the start of a statement", which
refreshes the stepping info and consequently updates
tp->control.step_frame_id to the frame id of main.
So by the time we're stopped at line 37, and are trying to figure out
what to print in print_stop_location, this condition evaluates to
true:
...
/* Finished step in same frame and same file, just print source
line. */
source_flag = SRC_LINE;
...
It's good to realize here that because foo is inlined into main,
tp->control.step_start_function is not foo but main, so consequently
the step_start_function check (which checks if we are still in the
same function) also passes, even though we actually stepped from foo
into main.
The problem is the use of find_symbol_for_pc, this function
deliberately skips over inline frames and returns the symbol for the
innermost non-inline frame.
It might be tempting to think that we should switch to use
find_symbol_for_pc_sect_maybe_inline, which will return the symbol for
an inline frame, but this also has problems, specifically, attempting
this caused a regression in gdb.opt/inline-cmds.exp. The previous
version of this patch, which showed the regression can be found here:
At a given $pc the inferior might be reported as being within an
inline frame, or it might be reported as being in the containing
non-inline frame. When the user performs a 'step' the
step_start_function needs to be set based on the function symbol of
the frame the inferior is actually reported in. And we have a
function that gives us this information, get_frame_function. So
instead of looking up the step_start_function based on the $pc value,
set it based on the frame.
Test gdb.dwarf2/dw2-extend-inline-block.exp is extended with the
additional test case described above.
Tested on x86_64-linux.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33930
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33981
Andrew Burgess [Tue, 14 Apr 2026 20:36:09 +0000 (22:36 +0200)]
[gdb/testsuite] Extend gdb.opt/inline-cmds.exp
When using this tentative patch [1], GDB regresses like this in test-case
gdb.opt/inline-cmds.exp:
...
Temporary breakpoint 1, main () at inline-cmds.c:64
64 y = 8; /* set mi break here */
(gdb) s
+main () at inline-cmds.c:66
66 result = func1 ();
(gdb) s
func1 () at inline-cmds.c:35
35 bar ();
(gdb)
...
but the regression doesn't produce a FAIL.
The regression does produce a FAIL during the part of the test that runs in MI
mode.
Extend the test so the regression also produces a FAIL in CLI mode.
Approved-By: Andrew Burgess <aburgess@redhat.com>
[1] https://sourceware.org/pipermail/gdb-patches/2026-March/226272.html
Simon Marchi [Wed, 18 Mar 2026 20:27:23 +0000 (16:27 -0400)]
gdb/dwarf: fix internal error when FDEs do not describe the CFA
New in v2: change how undefined_retaddr is set, to avoid regressions on
AArch64 (among possibly others).
This patch fixes an internal error problem that happens when a frame
description entry does not define the Canonical Frame Address (CFA).
This problem was initially reported downstream as a ROCgdb issue (see
Bug trailer below), but I wrote a reproducer that uses the .debug_frame
functionality added to the DWARF assembler in the previous patch.
The error is:
/home/smarchi/src/binutils-gdb/gdb/dwarf2/frame.c:1046: internal-error: Unknown CFA rule.
The original bug was encountered while debugging a GPU kernel written
with Triton [1]. From what I understand, the generated kernel does not
really use a stack, so the .debug_frame contents generated is quite
bare:
$ readelf --debug-dump=frames k
Contents of the .debug_frame section:
For those who don't speak fluent .debug_frame, what we see here is a
Frame Description Entry (FDE) that doesn't define any register rule,
referring to a Common Information Entry (CIE) that also doesn't define
any initial register rule. This is equivalent to having no unwind
information at all. One question is: why generate these at all? I
suppose that this is an edge case, that the compiler is written in a way
that that presumes there will always be some unwind info. That there is
no "if unwind info is empty, skip emitting the FDE" check. Anyway, the
important thing for us is that these can be found in the wild, so GDB
shouldn't crash.
The fix consists of handling CFA_UNSET in the dwarf2_frame_cache switch.
CFA_UNSET is the initial state when we start interpreting a CFA program,
meaning that we don't know yet how the CFA is defined. In our case, it
remains unset after interpreting the CFA program.
With just the fix above, we get:
(gdb) bt
#0 0x000055555555511d in main ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Which is good (better than crashing), but it would be good to avoid the
error. To do so, set the undefined_retaddr flag to true. This has
two effects:
- dwarf2_frame_this_id won't try to build a frame id from the CFA
(which is good, we don't have a CFA)
- dwarf2_frame_unwind_stop_reason will return UNWIND_OUTERMOST, which
is the most accurate thing we can return here (there is no outer
frame)
Simon Marchi [Wed, 18 Mar 2026 20:27:22 +0000 (16:27 -0400)]
gdb/testsuite: add .debug_frame support in DWARF assembler
Add support to the DWARF assembler for generating .debug_frame sections.
My initial use case is to reproduce a crash happening when encountering
an empty FDE, but I suppose that other use cases will pop up in the
future.
- Generate procs for the `DW_CFA_*` constants, similar to how the
DW_OP_* constants are handled. These `DW_CFA_*` procs are expected
to be used in the CIE and FDE bodies, described below.
- Add handlers for `DW_CFA_*` operations that take arguments. I tried
to cover everything that is in DWARF 5.
- Add the `frame` proc, used to generate one .debug_frame section.
- Add the `_frame_CIE` proc (available as `CIE` in the context of the
frame proc), used to generate one Common Information Entry.
- Add the `_frame_FDE` proc (available as `FDE` in the context of the
frame proc), used to generate one Frame Description Entry.
Due to the nature of the .debug_frame contents (it describes how
specific machine registers get saved), I expect that most of
the tests written using this will be arch-specific. But I think it
will still be useful, as it will let us craft .debug_frame sections to
look exactly how we want.
I included a test (gdb.dwarf2/debug-frame.exp), which is more like a
proof that we can build something useful using this, and can serve as an
example for whoever wants to write a test case using this in the future.
Change-Id: I048568ded53883abf52d70139e5cd3e7b4ac3841 Approved-By: Tom Tromey <tom@tromey.com>
Jan Beulich [Fri, 10 Apr 2026 06:43:22 +0000 (08:43 +0200)]
x86/AT&T: make GOT-relative expressions work
The expressions used in intel-got{32,64}.s should equally work (or not) in
AT&T mode. Changing the Intel syntax parser such that O_symbol wouldn't
happen to be wrapped around such expressions breaks it there, too. It
really isn't correct to limit this to just O_symbol. Permitting O_add and
O_subtract as well requires taking care of the other operand as well then.
(Strictly speaking non-zero offsets aren't very useful here, but then at
least with an equate of 0 this ought to work. The non-zero offset in the
testcase helps demonstrate that this offset isn't lost.)
Jan Beulich [Fri, 10 Apr 2026 06:42:10 +0000 (08:42 +0200)]
gas: distinguish local symbol flavors when printing symbols
Ordinary symbols fulfilling S_IS_LOCAL() criteria aren't the same as local
symbols. Make sure one can tell them apart in print_symbol_value()'s (and
print_expr()'s) output.
Alice Carlotti [Thu, 9 Apr 2026 01:17:48 +0000 (02:17 +0100)]
aarch64: Remove constraints on sysp operands
The CRn and CRm operands of sysp were unnecessarily constrained to the
ranges C8-C9 and C0-C7. This constraint has been removed from the
architecture spec, and was never implemented in LLVM, so remove it here
as well.
Additionally, add some more tests to cover the full range of valid sysp
operands, including omitting the pair of optional operands.
Alice Carlotti [Thu, 9 Apr 2026 00:16:12 +0000 (01:16 +0100)]
aarch64: Disallow movprfx before revd
An architectural relaxation in 2024 (listed in the "Known issues in
Issue K.a" of the Arm ARM) removed support for revd to be prefixed by a
movprfx instruction.
Remove two movprfx/revd tests from sme-9.s, and replace the
unnecessarily strict address checks with more permissive regexes
Muhammad Kamran [Wed, 18 Mar 2026 13:49:57 +0000 (13:49 +0000)]
aarch64: Reject no-Xt SYS aliases when Rt != 31 in disassembly
For SYS-encoding aliases that do not take Xt (for example TLBI ALLE1,
PLBI ALLE1), disassembly should not print the alias form when Rt != 31.
In that case, disassemble as the generic sys form instead.
Add a focused gas test that checks:
- Rt=31 still disassembles to aliases for no-Xt forms.
- Rt!=31 disassembles to sys ... , xN for those no-Xt forms.
- A valid Xt alias (TLBI VALE1) continues to disassemble as the alias.
opcodes/ChangeLog:
* aarch64-dis.c (aarch64_ext_regrt_sysins): Mark present as
whether Rt is non-default or the SYS op accepts Xt, so aliases
that do not take Xt are rejected when Rt != 31.
gas/ChangeLog:
* testsuite/gas/aarch64/sys-rt-alias.s: New test.
* testsuite/gas/aarch64/sys-rt-alias.d: New test.
aarch64: Add support for %dtprel(var) and R_AARCH64_TLS_DTPREL64
This patch allows R_AARCH64_TLS_DTPREL64 relocations in non-allocated
sections, which is required for DWARF debug information when using
Thread Local Storage. This matches the behavior in LLD.
Also a new syntax to parse dtprel operator use to describe tls
location in debug information. Please see the reference 3 below.
References:
- https://github.com/llvm/llvm-project/pull/146572
[AArch64] Support TLS variables in debug info
- https://github.com/llvm/llvm-project/pull/183962
[LLD][AArch64] Handle R_AARCH64_TLS_DTPREL64 in non-alloc sections
- https://github.com/ARM-software/abi-aa/pull/330
[AAELF64] Allow R_AARCH64_TLS_DTPREL to be used statically.
Alan Modra [Wed, 8 Apr 2026 23:36:27 +0000 (09:06 +0930)]
PR 34053 buffer overflow in xcoff_link_add_symbols
This patch adds two sanity checks with error reporting in
xcoff_link_add_symbols before reading symbol aux entries, add extends
assertions in later functions. A whole lot of unnecessary casts are
also tidied.
PR 34053
* xcofflink.c: Remove unnecessary casts throughout.
(xcoff_link_add_symbols): Sanity check aux entries are within
symbol buffer.
(bfd_xcoff_build_dynamic_sections): Assert the above is true.
(xcoff_link_input_bfd): Likewise.
Remove static variables do_ctf and do_sframe that are set but never
read, causing build failures with LLVM's extended
-Wunused-but-set-variable warning.
These variables are dead code:
- Declared at lines 244-245 as static booleans
- Set to true when --ctf or --sframe options are parsed
- Never actually used or read anywhere in the code
- The actual dump functionality is triggered by request_dump() calls
Build error with -Werror enabled:
binutils/readelf.c:244:13: error: variable 'do_ctf' set but not used
[-Werror,-Wunused-but-set-variable]
binutils/readelf.c:245:13: error: variable 'do_sframe' set but not used
[-Werror,-Wunused-but-set-variable]
Jan Beulich [Thu, 9 Apr 2026 06:39:10 +0000 (08:39 +0200)]
bfd/ELF: fold BFD_RELOC_<arch>_PCREL*
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, as long as the
resulting reloc's properties fit such a generic use (in the assembler it
could, after all, also result from ordinary expressions or uses with the
.reloc directive). Arm64, C-Sky, and KVX - sadly - are once again
exceptions.
For cris it's a PLT reloc which is being replaced.
For msp430 also drop BFD_RELOC_MSP430_16_BYTE, which has already been
merely an alias of BFD_RELOC_16 (resolving to R_MSP430_16_BYTE).
Jan Beulich [Thu, 9 Apr 2026 06:38:33 +0000 (08:38 +0200)]
bfd/Sparc: drop 64-bit BFD_RELOC_* aliases
For other relocations (e.g. BFD_RELOC_{8,16,32}{,_PCREL} or
BFD_RELOC_32_PCREL_S2) the generic enumerator is used. Plus use of such
aliases obfuscates where the generic types are actually in use.
Jan Beulich [Thu, 9 Apr 2026 06:37:51 +0000 (08:37 +0200)]
bfd/ELF: fold BFD_RELOC_<arch>_GOTPC*
For many of the cases there's no need to have separate relocs per arch;
just like for other more or less generic ones a single one (per purpose;
a 64-bit generic one is being introduced) will do. C-Sky - sadly -
continues to be an exception.
Jan Beulich [Thu, 9 Apr 2026 06:36:55 +0000 (08:36 +0200)]
bfd/s390+sh: don't abuse BFD_RELOC_32_GOT_PCREL
Neither R_390_GOT32 nor R_SH_GOT32 are PC-relative relocations, so don't
use a generic PC-relative enumerator for them. Doing so gets in the way
of properly using that enumerator.
Jan Beulich [Thu, 9 Apr 2026 06:36:19 +0000 (08:36 +0200)]
bfd/ELF: fold BFD_RELOC_<arch>_GOTOFF*
For many of the cases there's no need to have separate relocs per arch;
just like for other more or less generic ones a single one (per purpose;
a 64-bit generic one is being introduced) will do. Arm64, C-Sky, and
KVX - sadly - continue to be exceptions.
Tom Tromey [Sat, 28 Mar 2026 23:44:54 +0000 (17:44 -0600)]
Add command styling to error messages
This changes a number of error messages in gdb to use command_style.
In some places I've added double quotes around the command name for
consistency with other messages.
Alan Modra [Tue, 7 Apr 2026 23:27:39 +0000 (08:57 +0930)]
Don't write uninitialised data in .note.gnu.property
Seen when running the binutils x86-64 pr23494 tests.
_bfd_elf_convert_gnu_properties doesn't initialise its "contents"
buffer, and elf_write_gnu_properties doesn't write to padding.
Fix this by initialising the padding and then dispense with zeroing
contents in _bfd_elf_link_setup_gnu_properties.
Matthieu Longo [Wed, 28 Jan 2026 13:09:51 +0000 (13:09 +0000)]
gdb: add new helpers for retrieving a type's fully qualified name
Py_TYPE (self)->tp_name is the traditional idiomatic way to get a Python
type's fully qualified name. However, in the context of the Python
limited API, PyTypeObject is opaque, so the 'tp_name' attribute is no
longer accessible. Additionally, retrieving the type of a Python object
requires Py_TYPE, which is only available as part of the stable API
starting with Python 3.14.
This patch increases minimal Python limited API version from 3.11 to 3.14.
It also introduces two new helpers to retrieve a type's fully qualified
name: gdb_py_tp_name() and gdbpy_py_obj_tp_name(), which extract the fully
qualified name from a PyTypeObject and a PyObject, respectively. Ifdefery
allows these wrappers to select the appropriate API depending on the Python
version and whether the Python limited API is enabled. For any Python
version less than 3.13, gdb_py_tp_name() fallbacks using __qualname__
instead. However, the result may differ slightly in some cases, e.g. the
module name may be missing.
Finally, this patch adapts the existing code to use these wrappers, and
adjusts some test expectations to use the fully qualified name (or
__qualname__ for versions <= 3.13) where it was not previously used.
Note that the corner case where the module name would be missing does not
appear in the testsuite.
Matthieu Longo [Fri, 6 Mar 2026 17:50:45 +0000 (17:50 +0000)]
gdb: fail configure if Python version is too old for limited API
GDB can be built against the Python limited API using the configure
flag '--enable-py-limited-api=yes'. This flag is currently experimental,
and the build is not yet fully successful. Today, the minimum required
Python version for this option is 3.11. This requirement is not final
and will be raised to a later version as the migration progresses.
However, the configure script does not currently report an error if an
older version of Python is used. Instead, the build fails later with
numerous errors that are difficult to relate to Python limited API
compatiblity.
This patch adds a version check when '--enable-py-limited-api=yes' is
specified, ensuring that the provided Python version meets the minimum
requirements for the limited API support. If it does not, configure will
now fail with a clear error message.
Tom Tromey [Sun, 30 Mar 2025 15:50:18 +0000 (09:50 -0600)]
Update .debug_names documentation
This updates the .debug_names documentation to explain some DWARF
issues that we've handled in gdb.
This list still isn't exhaustive. I think there are some situations
where gdb may examine a declaration (which DWARF says not to do), but
I didn't document this as I don't recall the details.
Approved-By: Eli Zaretskii <eliz@gnu.org> Acked-By: Tom de Vries <tdevries@suse.de>
Tom Tromey [Tue, 22 Oct 2024 22:29:46 +0000 (16:29 -0600)]
Handle inline functions with dwz
Currently, gdb does not properly handle inline functions when dwz is
used. This can be seen by running gdb.cp/breakpoint-locs.exp with the
cc-with-dwz target board.
The problem here is that inline functions need special handling in the
dwz case.
First, recall that a DWARF partial unit cannot, in general, be read in
isolation, as it may not have a language. To handle this, gdb defers
scanning partial units directly, and instead scans them in the context
of some including CU.
Entries coming from the PU are attributed to this reading CU. If
multiple CUs import a PU, gdb has the reader threads race to see which
one does the actual reading.
However, if an inline function is moved into a partial unit, then that
means it has potentially been inlined somewhere in every including CU.
Thus, when linespec searches for this function, each such including CU
should be expanded. But because gdb only attributed the function's
index entry to one CU, only that particular one is expanded.
This patch fixes this bug. All inclusions of a PU are recorded.
Entries coming from a PU are attributed to that PU. For most entries
coming from the PU, a single "canonical" outer CU is chosen to expand.
However, when an inline function is found, all such CUs are expanded.
A change was also needed to the index writer to handle this case.
There, entries coming from a PU should note the correct including CU.
This must be done because, with .debug_names or .gdb_index, gdb does
not have information about unit imports. Handling inline functions
here means writing out a separate entry for each outermost CU that
includes the function's PU.
I did consider changing the cooked indexer to create an internal table
more similar to what would be created by the .debug_names (e.g.)
reader: that is, multiple entries for each inline function. However,
this seemed more expensive at read time, and a main goal of the cooked
indexer is to be fast.
This version updates an assert in the .debug_names writer, and adds a
regression test for that.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30728 Acked-By: Tom de Vries <tdevries@suse.de>
Tom Tromey [Sat, 24 Jan 2026 21:56:10 +0000 (14:56 -0700)]
Have iterate_over_one_compunit_symtab search included symtabs
A latent bug in the search-via-psyms series was that it neglected to
update iterate_over_one_compunit_symtab to search included symtabs.
I think lookups that needed this search used to work by accident -- an
included CU would be expanded but not searched, but a search of all
compunits() would then find it.
This patch corrects the oversight. I'm not sure if this bug is
readily visible without the next patch.
Acked-By: Tom de Vries <tdevries@suse.de> Approved-By: Simon Marchi <simark@simark.ca>
Tom Tromey [Sat, 24 Jan 2026 21:56:16 +0000 (14:56 -0700)]
Remove C++ special case from process_imported_unit_die
process_imported_unit_die has a special case for C++, added as a
performance improvement.
While I somewhat agree with the general idea of this snippet --
importing a compilation unit seems like a strange thing to do, given
that partial units exist -- I think there are two issues with it.
First, it is specific to C++. I don't see any real reason that this
should be the case.
Second, it does not have a corresponding bit of code in the indexer.
This means that the cooked index's view of the DWARF differs from the
full reader's view here. This causes regressions in this series,
because the indexer assumes that reading a CU will cause all the
imported CUs to be read as a side effect -- but that does not happen
here.
I think fixing this in the indexer is not trivial. The reason for
this is that the indexer works in parallel, and once a reader has
acquired the "scan" bit for a CU, it is obligated to read it.
However, in this case this would require making a new cooked indexer.
Instead, because (1) this is weird and rare DWARF anyway, and (2) this
is just a performance optimization, I propose removing this.
Acked-By: Tom de Vries <tdevries@suse.de> Approved-By: Simon Marchi <simark@simark.ca>
Tom Tromey [Fri, 21 Nov 2025 16:43:11 +0000 (09:43 -0700)]
Combine two cases in cooked_index_functions::search
This combines a couple of 'if' statements in
cooked_index_functions::search. This simplifies the code a little and
also makes a subsequent patch a bit simpler as well.
Acked-By: Tom de Vries <tdevries@suse.de> Approved-By: Simon Marchi <simark@simark.ca>
Tom Tromey [Sun, 30 Mar 2025 19:52:57 +0000 (13:52 -0600)]
Don't consider DW_TAG_inlined_subroutine as interesting
tag_interesting_for_index returns true for DW_TAG_inlined_subroutine
-- but this tag only appears where the function is actually inlined,
which is not interesting for the index.
Acked-By: Tom de Vries <tdevries@suse.de> Approved-By: Simon Marchi <simark@simark.ca>
Tom Tromey [Sun, 30 Mar 2025 13:52:34 +0000 (07:52 -0600)]
Skip partial units in process_psymtab_comp_unit
process_psymtab_comp_unit passes 'false' for the 'skip_partial'
argument to the cutu_reader constructor, but then proceeds to skip
partial units. This patch simplifies the code by passing 'true'
instead.
Acked-By: Tom de Vries <tdevries@suse.de> Approved-By: Simon Marchi <simark@simark.ca>
Some gdb.dwarf2 tests match the output of commands like frame and
expect to see locations printed as fission-base.c:LINE (no directory
prefix). When the test programs are built with clang as CC_FOR_TARGET,
GDB can print an absolute source path instead, causing FAILs.
For example, with clang:
(gdb) PASS: gdb.dwarf2/fission-base.exp: ptype func
(gdb) frame
#0 main () at /path/to/gdb/testsuite/fission-base.c:27
27 return func (-1);
(gdb) FAIL: gdb.dwarf2/fission-base.exp: frame in main
With gcc:
(gdb) PASS: gdb.dwarf2/fission-base.exp: ptype func
(gdb) frame
#0 main () at fission-base.c:27
27 return func (-1);
(gdb) PASS: gdb.dwarf2/fission-base.exp: frame in main
The difference comes from the DWARF line table contents. With clang,
the .debug_line directory table can contain an absolute directory that
the file table entries reference:
The Directory Table:
0 /path/to/gdb/testsuite
The File Name Table:
0 Dir=0 Name=fission-base.c
1 Dir=0 Name=fission-base.c
Whereas with gcc the directory table is empty and only the bare filename
is present:
The Directory Table is empty.
The File Name Table:
1 Name=fission-base.c
This difference reflects toolchain/assembler behavior in how .file/.loc
are translated into .debug_line and is orthogonal to what these tests
aim to validate.
Force set filename-display basename in the affected tests so the
output is stable across toolchains.
Alan Modra [Tue, 7 Apr 2026 04:25:36 +0000 (13:55 +0930)]
various xcoff rs6000 linker issues
This patch started out as an exercise in sanity checking r_symndx
before indexing symbol hashes, but grew as I noticed other issues.
Merges xcoff_ppc_relocate_section and xcoff64_ppc_relocate_section.
All of the xcoff_reloc_function now return a status, with the idea
that error reporting can be done in one place.
* libxcoff.h (xcoff_reloc_function): Return bfd_reloc_status_type
rather than bool.
(_bfd_xcoff_relocate_section): Declare.
* coff-rs6000.c (xcoff_reloc_type_noop, xcoff_reloc_type_fail),
(xcoff_reloc_type_pos, xcoff_reloc_type_neg, xcoff_reloc_type_rel),
(xcoff_reloc_type_toc, xcoff_reloc_type_ba, xcoff_reloc_type_br),
(xcoff_reloc_type_crel, xcoff_reloc_type_tls): Return
bfd_reloc_status_type rather than bool. Don't emit standard
error message and don't set bfd error. Replace r_symndx
non-negative check with check against obj_raw_syment_count.
(_bfd_xcoff_relocate_section): Extracted from
xcoff_ppc_relocate_section and xcoff64_ppc_relocate_section.
Move error reporting to end of loop. Report error for
r_symndx out of range. Adjust for reloc howto special
function change. Properly check that reloc offset is in range.
Prevent possible segfault in _bfd_coff_internal_syment_name.
* coff64-rs6000.c: Similarly.
Alan Modra [Mon, 6 Apr 2026 13:28:22 +0000 (22:58 +0930)]
PR 34049 buffer overflow in xcoff_link_add_symbols
The fact that coffcode.h:coff_set_alignment_hook for rs6000 removes
sections can result in target_index > section_count. Thus any array
indexed by target_index must not be sized by section_count.
PR ld/34049
* xcofflink.c (xcoff_link_add_symbols): Size reloc_info array
using max target_index.
projects / thirdparty / binutils-gdb.git / log
