which converted GDB to use init_extended_pair where possible, I
realised we could also make use of init_extended_color.
The motivation for using init_extended_color is slightly less than
init_extended_pair. Assuming the terminal supports it the standard
init_color API supports up to SHRT_MAX (32767) different colors,
switching to init_extended_color removes the SHRT_MAX limit on color
indices, allowing us to support the full range of COLORS.
But the cost of making this change is minimal, we already track the
color indices as an `int` within the global COLOR_MAP, so it's mostly
just a case of calling init_extended_color where needed.
We only use init_extended_color when both that function and
init_extended_pair is available. The fallback to init_extended_pair
is init_pair, which expects the color indices to be shorts. If we are
using the init_pair fallback then using init_extended_color is
pointless.
In reality init_extended_pair and init_extended_color were both added
in ncurses 6.1, so should both be available together.
There is one additional change in here. Assuming that a terminal does
support more than SHRT_MAX colours, but for some reason GDB is
compiled with a version of the curses library that doesn't support
init_extended_color, then it is possible that in `get_color` the value
of NEXT could end up above SHRT_MAX, in which case the `init_color`
call will truncate the value of NEXT to a short and we will end up
redefining an earlier color index. To avoid this unlikely case I've
added a compare against SHRT_MAX.
The init_extended_color path doesn't have this risk as COLORS is an
`int` and NEXT is passed as an `int` on this path so there is no risk
of truncation.
Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Tue, 11 Aug 2026 12:18:02 +0000 (13:18 +0100)]
gdb/configure: fix string quoting in AC_MSG_WARN and AC_MSG_ERROR
Eli pointed out an issue with --enable-binary-file-formats, when GDB
is built with --enable-binary-file-formats='coff,xcoff,elf,macho' on a
target that doesn't support Mach-O, then GDB would configure
correctly, but then fail to build with an error like:
CXXLD gdb.exe
d:/usr/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe:
machoread.o: in function `macho_check_dsym':
d:\gnu\gdb-18.0.90\gdb/machoread.c:738:(.text+0xb16):
undefined reference to `bfd_mach_o_lookup_command'
d:/usr/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe:
d:\gnu\gdb-18.0.90\gdb/machoread.c:757:(.text+0xbe6):
undefined reference to `bfd_mach_o_lookup_command'
collect2.exe: error: ld returned 1 exit status
It turns out the problem was incorrect quoting in an AC_MSG_ERROR call
within the configure script. The current code is structured like
this:
if CONDITION_1; then
AC_MSG_ERROR("some message, some more message")
elif CONDITION_2; then
AC_MSG_ERROR("some message, some more message")
fi
As "..." is not recognized as quoting by m4, the comma inside is
interpreted as an m4 argument separator, so 'some more message"'
including the trailing quote becomes the exit status and '"some
message' becomes the error message.
Configure understands to quote the '"' in the error message, but the
'"' in the exit status is not quoted, which leaves an unbalanced quote
in the configure script.
Luckily the second AC_MSG_ERROR line also has the same problem, which
adds a second unbalanced '"' into the configure script, which closes
the string started by the first unbalanced quote.
The string formed by these two unbalanced quotes just happens to
include the entire CONDITION_2 `if` check.
Fix this by replacing the use of '"..."' with '[...]' instead.
gdb, configure: Add enable-binary-file-format option for configure
As well as the two AC_MSG_ERROR calls the above commit introduced an
incorrectly quoted AC_MSG_WARN call, I've fixed that too.
The above commit also added an unnecessary ';' at the end of the two
AC_MSG_ERROR lines, I've removed them in this commit.
While reviewing the above commit I spotted a couple of issues with the
error messages themselves. First 'elf' should be 'ELF' when talking
about the file format, so I fixed that. And second, AC_MSG_ERROR
calls normally don't have a trailing period, so I removed these from
the error messages added by 809c1abc19d487da.
Now when configuring with
--enable-binary-file-formats='coff,xcoff,elf,macho' on a target that
doesn't support Mach-O, e.g. GNU/Linux, the configure will stop like
this:
checking for ELF support in BFD... yes
checking for library containing dlopen... (cached) none required
checking for Mach-O support in BFD... no
configure: error: Mach-O support was requested, but BFD does not support it
make: *** [Makefile:13461: configure-gdb] Error 1
Finally, during a final review of this patch I spotted another place
in our configure script where we were not quoting the argument to
AC_MSG_WARN correctly. In this case the error was added in commit e76c5d173bbf7137. The problem line is:
AC_MSG_WARN(disabling guile support, $GUILD fails compiling for $host)
As AC_MSG_WARN expects only a single argument, everything after the
comma will be discarded. Quote the string with '[...]' to ensure the
full string is printed.
Tom de Vries [Thu, 13 Aug 2026 01:59:17 +0000 (03:59 +0200)]
[gdb/cli] Don't emit emojis in MI
PR mi/34501 reports the following:
...
$ gdb -q \
-ex 'set charset UTF-8' \
-ex 'interpreter-exec mi2 "-break-insert -f foo' \
-ex quit
&"�\235\214�\217 No symbol table is loaded. Use the \"file\" command.\n"
...
$
...
The output is a bit odd, but that gets better if we use
'set print sevenbit-strings on':
...
&"\342\235\214\357\270\217 No symbol table is loaded. Use the \"file\" command.\n"
...
The output we see there is the error emoji:
...
$ gdb
(gdb) b foo
❌️ No symbol table is loaded. Use the "file" command.
...
More specifically, two utf-8 encoded unicode characters:
- Cross Mark [1]: 0xE2 0x9D 0x8C
- Variation Selector-16 (VS16) [2]: 0xEF 0xB8 0x8F
Now the question: is GDB doing something wrong?
I think we probably should encode unicode characters in MI error strings as
octal escapes, independent of the sevenbit-strings setting. This patch does
not address this part.
Then there's the question whether we should emit emojis in MI error strings in
the first place [3]. In principle they're unicode characters encoded in UTF-8,
and we can expect other such unicode characters in translated error strings.
But, given that MI has can_emit_style_escape () == false, and already filters
out ANSI escape sequences, I think it's reasonable to also disable emojis.
As for implementation, I introduced a function emoji_allowed alongside
can_emit_style_escape, which defaults to the value of can_emit_style_escape.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34501
Tom de Vries [Wed, 12 Aug 2026 21:18:20 +0000 (23:18 +0200)]
[gdb] Rewrite error and warning emojis
While working on PR34501 I realized that these two strings actually contain
two unicode characters:
...
static std::string warning_prefix = "⚠️ ";
static std::string error_prefix = "❌️ ";
...
Both the Warning Sign [1] and the Cross Mark [2] are followed by Variation
Selector-16 (VS16) [3].
To make this obvious, I decided to rewrite in a style that makes it explicit
both which unicode characters are used, and how they are encoded:
...
static std::string warning_prefix = u8"\u26A0\uFE0F ";
...
In the process I found out that the Cross Mark doesn't need VS16, because its
default presentation is already "Emoji" rather than "Text", so that one simply
becomes:
...
static std::string error_prefix = u8"\u274C ";
...
AFAICT, this property (default presentation == "Emoji") can be verified by
finding Cross Mark here [4] and checking that property Emoji_Presentation
applies.
Tom de Vries [Wed, 12 Aug 2026 21:16:25 +0000 (23:16 +0200)]
[gdb/testsuite] Fix gdb.python/py-mi-cmd.exp
On Fedora Rawhide aarch64-linux (using Python 3.15.0b4), with test-case
gdb.python/py-mi-cmd.exp I ran into:
...
Expecting: ^(-pycmd bk3[^M
]+)?(&"TypeError.*: __repr__ returned non-string \(type BadKey\).."^M
\^error,msg="Error occurred in Python: __repr__ returned non-string \(type BadKey\)"[^M
]+[(]gdb[)] ^M
[ ]*)
-pycmd bk3^M
&"TypeError: ReallyBadKey.__repr__() must return a str, not BadKey\n"^M
^error,msg="Error occurred in Python: ReallyBadKey.__repr__() must return a str, not BadKey"^M
(gdb) ^M
FAIL: $exp: -pycmd bk3 (unexpected output)
...
Fix this by updating the regexp.
Tested with aarch64-linux (Python 3.15.0b4) and x86_64-linux (Python 3.13.14).
Tom de Vries [Wed, 12 Aug 2026 21:11:46 +0000 (23:11 +0200)]
[gdb/python] Handle error in gdbpy_initialize_gdb_readline
On Fedora Rawhide aarch64-linux, with test-case gdb.python/py-failed-init.exp
I ran into:
...
builtin_spawn $build/gdb/gdb -nw -nx -q -iex set height 0 -iex set width 0 \
-data-directory $build/gdb/data-directory -iex set interactive-mode on
WARN: Could not find the standard library directory! The Python 'home' \
directory was set to 'foo', is this correct?
Error occurred computing Python error message.
$build/gdb/gdb: warning:
Could not load the Python gdb module from `$build/gdb/data-directory/python'.
Limited Python support is available from the _gdb module.
Suggest passing --data-directory=/path/to/gdb/data-directory.
(gdb) set height 0
(gdb) set width 0
(gdb) dir
Reinitialize source path to empty? (y or n) y
Source directories searched: $cdir:$cwd
(gdb) dir $src/gdb/testsuite/gdb.python
Source directories searched: $src/gdb/testsuite/gdb.python:$cdir:$cwd
(gdb) python print (1)
1
(gdb) FAIL: $exp: gdb-command<python print (1)>
quit
Exception ignored on threading shutdown:
Traceback (most recent call last):
File "<string>", line 2, in <module>
ModuleNotFoundError: No module named 'importlib'
PASS: $exp: quit
...
The test-case tries to break python:
...
save_vars { env(PYTHONHOME) } {
setenv PYTHONHOME foo
clean_restart
}
...
enough to get it to this point:
...
gdb_test "python print (1)" \
"Python not initialized"
...
but apparently, that doesn't work anymore in this python version:
...
$ python --version
Python 3.15.0b4
...
The test-case needs updating, and I've submitted a testsuite patch [1] for
that.
The next question is why we're seeing a ModuleNotFoundError on quit.
I investigated this, and found that it originates from
gdbpy_initialize_gdb_readline, where we do:
...
if (eval_python_command (code, Py_file_input) == 0)
PyOS_ReadlineFunctionPointer = gdbpy_readline_wrapper;
...
but don't report and reset the python error state, so instead the error is
reported by Py_Finalize.
Fix this by:
- making sure that the error is reported immediately, though in the form of a
warning rather than an error, and
- disabling the python-interactive command if gdbpy_initialize_gdb_readline
fails, to avoid broken readline behavior in a python-interactive session.
Also make the test-case a bit stricter by checking that there's no output when
quitting.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Changes in v2:
- use gdbpy_print_stack instead of PyErr_Print/PyErr_Clear
- Fix error/warning message by ensure that command name is double-quoted and
displayed using command_style
Tom Tromey [Wed, 1 Jul 2026 18:48:49 +0000 (12:48 -0600)]
Use F_SETFL after F_SETOWN
This changes enable_async_notification to use F_SETFL after F_SETOWN.
This order more correct because it ensures that the owning process is
set before the request to enable SIGIO.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Jens Remus [Wed, 12 Aug 2026 12:39:50 +0000 (14:39 +0200)]
gas: sframe: Add test for signal frame with unsupported CFI
Usually if the generation of SFrame from CFI directives encounters
unsupported CFI the generation of SFrame FDE is skipped. For signal
frames (.cfi_signal_frame) an "empty" FDE without any FREs is generated
instead.
This adds a test for the issue fixed with commit fa11363bc9ad ("Ensure
that sframe_xlate_ctx_cleanup() doe snot leave any dangling pointers").
gas/testsuite/
* gas/cfi-sframe/cfi-sframe.exp (cfi-sframe-common-14): Run
new common test.
* gas/cfi-sframe/cfi-sframe-common-14.d: New common test for
signal frame with unsupported CFI.
gas/cfi-sframe/cfi-sframe-common-14.s: Likewise.
Jens Remus [Wed, 12 Aug 2026 12:39:50 +0000 (14:39 +0200)]
gas: sframe: Fix non-SP/FP CFA base register if flexible FDE
.cfi_def_cfa_offset modifies the current CFA rule to use the provided
offset but keep the current CFA base register. It therefore requires
a CFA base register to be in effect. Relax the check to simply test
for whether a CFA base register is in effect instead of restricting
it to SP/FP. The latter is checked when the CFA base register is
modified.
This enables .cfi_def_cfa_offset with non-SP/FP CFA base register for
targets that support SFrame flexible FDE.
While at it simplify the logic to test for error cases first.
gas/
* gen-sframe.c (sframe_xlate_do_def_cfa_offset): Allow non-SP/FP
CFA base register if flexible FDE.
Evgeny Karpov [Fri, 7 Aug 2026 14:37:11 +0000 (16:37 +0200)]
aarch64: Implement Structured Exception Handling (SEH) on AArch64
The patch reuses shared helpers for SEH and implements SEH on AArch64.
The implementation is based on
(https://learn.microsoft.com/en-us/cpp/build/arm64-exception-handling?view=msvc-170)
and pdata/xdata SEH records are emitted from md_finish.
When .pdata/.xdata is emitted, the function size is required.
Function sizes are calculated as late as possible, and the code segment needs
to be relaxed to be able to calculate the function sizes.
Initially, obj_coff_generate_pdata was called in write_object_file.
Before the change, obj_coff_generate_pdata was used only to validate
syntax, which was sufficient for that purpose. However, that location
seems incorrect, as it is too late to emit .pdata/.xdata records
in the AArch64 case.
md_finish has been declared for AArch64 and extended with
seh_aarch64_write_data to emit .pdata/.xdata records after all
assembly has been completed.
Signed-off-by: Evgeny Karpov <evgeny@kmaps.co>
gas/ChangeLog:
* gas/config/obj-coff-seh-shared.c (defined): Update.
(struct seh_seg_list): Use seh_context_t.
* gas/config/obj-coff.c (defined): Update.
* gas/config/tc-aarch64.c (defined): Add OBJ_COFF guard.
(aarch64_md_finish): Add.
* gas/config/tc-aarch64.h (defined): Add OBJ_COFF guard.
(md_finish): Add.
(aarch64_md_finish): Add.
(seh_aarch64_write_data): Add.
* testsuite/gas/pe/pe.exp: Add SEH tests.
* write.c: Update.
* write.h (subsegs_finish_section): Update.
* config/obj-coff-seh-aarch64.c: New file.
* config/obj-coff-seh-aarch64.h: New file.
* testsuite/gas/pe/seh-aarch64-error.l: New test.
* testsuite/gas/pe/seh-aarch64-error.s: New test.
* testsuite/gas/pe/seh-aarch64-large-func.d: New test.
* testsuite/gas/pe/seh-aarch64-large-func.s: New test.
* testsuite/gas/pe/seh-aarch64.d: New test.
* testsuite/gas/pe/seh-aarch64.s: New test.
The RISC-V port never defined elf_backend_dtrel_excludes_plt, unlike
x86-64, AArch64, arm, ppc, mips and s390. As a result DT_RELASZ counted
.rela.dyn + .rela.plt instead of just .rela.dyn.
With an empty .rela.dyn this makes DT_RELA alias DT_JMPREL (DT_RELA ==
DT_JMPREL, DT_RELASZ == DT_PLTRELSZ). glibc accepts the aliased range,
but tools that read the two ranges independently, such as llvm-bolt, then
process .rela.plt twice.
Define the macro so DT_RELASZ excludes .rela.plt, matching every other
target. When .rela.dyn is empty DT_RELA is now zeroed and the aliasing
is gone.
Tom Tromey [Fri, 15 May 2026 17:42:08 +0000 (11:42 -0600)]
Convert py-tui.c to the "python safety" approach
This patch mostly converts py-tui.c to use the new Python safety code.
In particular:
* All methods of gdb.TuiWindow are now implemented as straightforward
methods of gdbpy_tui_window.
* gdbpy_register_tui_window is converted and simply returns 'void'.
I converted this particular file because it was relatively
straightforward, while also demonstrating most of the features of the
new approach. For example, explicit result checks aren't needed,
try/catch can be removed, and the methods are now written in a natural
style.
Note that more conversion remains to be done here:
* gdbpy_tui_enabled hasn't been converted and still does explicit
checks.
* There's one explicit check in gdbpy_tui_window::set_title. Fully
implementing the safety approach means that some low-level things
should eventually be converted to throw; but some work has to be
deferred until a lot of the work is complete.
Tom Tromey [Sun, 22 Feb 2026 19:29:34 +0000 (12:29 -0700)]
Add wrappers for Python implementation functions and methods
This adds some wrappers for Python implementation functions and
methods, and a couple of new constexpr functions to create PyMethodDef
entries. This provides a few safety benefits:
* The new-style API approach (see previous patch) is implemented by
the wrapper. That is, exceptions are caught here and transformed.
* The implementation functions can now return any reasonable type,
with automatic conversion by the wrapper.
* The function API and the appropriate METH_* flags are handled
together, avoiding any possible discrepancy.
This approach also means that we can modify the old rule that gdb
calls must be wrapped in a try/catch -- the try/catch is now provided
by the wrapper function, so the implementation can be written in a
more natural way.
Note that while this patch is usable as-is, it is not 100% complete,
in sense that there is still future work to do when converting other
parts of the gdb Python code. For instance, there should be one more
wrapper for case where a method takes a single argument (though we
probably cannot use METH_O unfortunately).
Tom Tromey [Sun, 22 Feb 2026 19:29:00 +0000 (12:29 -0700)]
Add gdbpy_borrowed_ref
This adds new gdbpy_opt_borrowed_ref and gdbpy_borrowed_ref classes.
These classes are primarily for code "documentation" purposes -- it
makes it clear to the reader that a given reference is borrowed.
However, they also add a tiny bit of safety, in that conversion to
gdbpy_ref<> will either be rejected (by the "opt" class) or acquire a
new reference.
changes ada_main_name to use section_table_xfer_memory_partial. This
introduced a highly unlikely, but theoretical bug where stale buffer
data could cause GDB to find an invalid name for "main".
Looking at ada_main_name (in ada-lang.c), the steps to reproduce the
bug are:
1. Debug a program that causes the static buffer main_program_name
to have some content written to it. For the sake of this bug
let's assume the main name is "xxxxxxxxxx", the main_program_name
buffer will contain 10 'x' characters, a null byte, then whatever
happened to be in the section after that.
2. A new executable is loaded into GDB and ada_main_name is called
again.
3. For whatever reason the new executable is maybe not correct. The
ADA_MAIN_PROGRAM_SYMBOL_NAME symbol points to an address 5 bytes
before the end of a section. None of these 5 bytes are a null
bytes. Let's assume these 5 bytes are "aaaaa".
4. The section_table_xfer_memory_partial call will try to read up to
1024 bytes, but as there are only 5 bytes left in the section,
only 5 will be read. This leaves the main_program_name buffer
containing "aaaaaxxxxx" followed by a null character byte.
5. GDB returns this merged string as the result from ada_main_name.
Now given this depends on the second executable being broken, we maybe
don't really care too much, however, fixing this is pretty easy.
This ensures that there's a string with a null byte contained within
the buffer, but makes the assumption that we always read
sizeof (main_program_name) bytes from the section.
But we know how many bytes were read, that's the value in XFERRED.
What we really want to ask is: was there a null terminated string
within the bytes that we just read. This is:
Andrew Burgess [Fri, 7 Aug 2026 14:22:22 +0000 (15:22 +0100)]
sim: delete sim/ppc/.gdbinit
The sim/ppc/.gdbinit has existed since the initial repository creation
commits. However, I don't think it adds any value and can be
deleted. The contents of the file were just:
set output-radix 16
break error
The sim/ tree already includes rules in its Makefile to build a
.gdbinit for each simulator which sources sim/gdbinit.in, so if anyone
wants to argue for keeping either of the above lines then they should
be added to the sim/gdbinit.in file.
Keeping sim/ppc/.gdbinit in tree is an annoyance for the release
process as 'make distclean' in the sim tree ends up deleting the file.
Tom Tromey [Wed, 22 Jul 2026 13:19:21 +0000 (07:19 -0600)]
Minor 'debug_*' function improvements
I wanted to get a summary of a type in gdb and then realized I had
forgotten the function name, so I had to dig around to find it. This
made me think that perhaps renaming the debug_* functions to all just
be named 'debug' would be an improvement, since it's easier to
remember.
Then I noticed that debug_type and debug_val don't print a trailing
newline.
Finally, I needed to be able to see the contents of a gdb_mpz.
v2 changes these functions to use ATTRIBUTE_USED rather than
ATTRIBUTE_UNUSED, as the former indicates that these should not be
deleted even if apparently unused.
Kyrylo Tkachov [Wed, 5 Aug 2026 13:11:46 +0000 (15:11 +0200)]
aarch64: ERRAT_NONE is not zero, so test against it
erratum_84319_opts starts at ERRAT_NONE = (1 << 0), so a plain boolean test
on fix_erratum_843419 is true even when no erratum workaround was asked for.
Every other use in the file tests against ERRAT_NONE or masks with ERRAT_ADR /
ERRAT_ADRP. Two do not.
The bare test dates from the conversion of fix_erratum_843419 from an int to an
enum for PR ld/24373.
Having the workaround on by default all the time is, of course, undesirable as
it costs link-time and is not what the user has asked by default.
Tested on aarch64-none-linux-gnu.
bfd/
* elfnn-aarch64.c (elfNN_aarch64_write_section): Test
fix_erratum_843419 against ERRAT_NONE.
(elfNN_aarch64_late_size_sections): Likewise.
H.J. Lu [Thu, 6 Aug 2026 02:33:02 +0000 (10:33 +0800)]
readelf: Don't dump GOT section after seeing error
Don't dump GOT section contents after seeing errors in input:
readelf: Error: Section 10 has invalid sh_entsize of 0
readelf: Error: (Using the expected size of 18 for the rest of this dump)
readelf: Error: Too many program headers - 0x3030 - the file is not that big
PR binutils/34473
* elfcomm.c (seen_error): New.
(seen_elf_error): Likewise.
(clear_elf_error): Likewise.
(error): Set seen_error to true.
* elfcomm.h (seen_elf_error): New.
(clear_elf_error): Likewise.
* readelf.c (process_got_section_contents): Return false if
seen_elf_error returns true.
(main): Call clear_elf_error before calling process_file.
H.J. Lu [Wed, 5 Aug 2026 08:43:05 +0000 (16:43 +0800)]
ld: Check input section garbage collection error
The ELF backend gc_mark_extra_sections function may return false for
error and bfd_gc_sections may return false on invalid input:
ld: pr34448-bug_18.o: bad reloc symbol index (0xf2000005 >= 0x13) for offset 0x4 in section `.text.get_tls[get_tls]'
Change bfd_elf_gc_sections to return false if gc_mark_extra_sections
return false. Change lang_gc_sections to check bfd_gc_sections return
and report the fatal error.
H.J. Lu [Sat, 1 Aug 2026 03:23:39 +0000 (11:23 +0800)]
x86: Check if needed dynamic relocation section is created
Since elf_link_read_relocs_from_section aborts for bad relocation,
further relocations won't be processed and needed dynamic relocation
section won't be created. Skip dynamic relocation count if needed
dynamic relocation section hasn't been created.
PR ld/34448
* elfxx-x86.c (_bfd_x86_elf_late_size_sections): Skip dynamic
relocation count if needed dynamic relocation section hasn't been
created.
gdb: prefer lhs type's address spaces/classes in check_typedef
In commit 92fdad7 "gdb: convert type instance flags to bitfields",
`operator|=` of type_instance_flags required the address space and
address class values of left-hand-side to be zero. This introduced
the following bug (thanks to Keith Seitz for reporting it at
https://inbox.sourceware.org/gdb-patches/053e90c0-53f0-4748-9d27-0237b9f21221@redhat.com/T/#u):
typedef int myint;
(gdb) ptype (@code myint) 3
../../src/gdb/gdbtypes.h:127: internal-error: operator|=: Assertion
`harvard_aspace == 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x5bb1d1 gdb_internal_backtrace_1
../../src/gdb/bt-utils.c:122
0x5bb210 _Z22gdb_internal_backtracev
../../src/gdb/bt-utils.c:173
0xdfbbaa internal_vproblem
../../src/gdb/utils.c:434
0xdfbf45 _Z15internal_verrorPKciS0_P13__va_list_tag
../../src/gdb/utils.c:514
0x162763f _Z18internal_error_locPKciS0_z
../../src/gdbsupport/errors.cc:57
0x87e8e6 _ZN19type_instance_flagsoRERKS_
../../src/gdb/gdbtypes.h:127
0x875d71 _Z13check_typedefP4type
../../src/gdb/gdbtypes.c:3072
The |= operator is used in check_typedef as follows:
/* Preserve the instance flags as we traverse down the typedef chain.
Handling address spaces/classes is nasty, what do we do if there's a
conflict?
E.g., what if an outer typedef marks the type as class_1 and an inner
typedef marks the type as class_2?
This is the wrong place to do such error checking. We leave it to
the code that created the typedef in the first place to flag the
error. We just pick the outer address space (akin to letting the
outer cast in a chain of casting win), instead of assuming
"it can't happen". */
{
type_instance_flags new_instance_flags = type->instance_flags ();
/* Treat code vs data spaces and address classes separately. */
if (instance_flags.harvard_aspace != HARVARD_ASPACE_NONE)
new_instance_flags.harvard_aspace = HARVARD_ASPACE_NONE;
if (instance_flags.address_class != 0)
new_instance_flags.address_class = 0;
instance_flags |= new_instance_flags;
}
So, the assertion in operator|= was wrong. The outer type, which is
the left-hand-side in this case, should preserve its values if they
are non-zero. The right-hand-side values are used, if lhs values are
zero. Fix the bug accordingly.
Furthermore, rename operator|= to "merge". Type instance flags are no
longer stored as a bitmask value, but rather as a struct. Having an
operator like |= gives the wrong impression that we are doing a
bitmask OR. Using a method makes the intention clearer.
Include a regression test.
Reviewed-By: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Tue, 4 Aug 2026 18:32:28 +0000 (20:32 +0200)]
[pre-commit] Avoid tabs in .pre-commit-config.yaml
When editing .pre-commit-config.yaml with emacs, I tend to get tab-indented
lines, which causes:
...
$ git commit -a
An error has occurred: InvalidConfigError:
==> File .pre-commit-config.yaml
=====> while scanning for the next token
found character that cannot start any token
in "<unicode string>", line 150, column 1
...
H.J. Lu [Thu, 30 Jul 2026 05:43:56 +0000 (13:43 +0800)]
x86: Check invalid GOT/PLT/TLS relocations
1. Since non-alloc sections aren't checked for TLS, GOT and PLT usages,
relocate_section should issue error for TLS, GOT and PLT relocations in
non-alloc and non-debugging sections.
2. Since TLS relocations must be against thread local symbols, scan_relocs
should issue an error for TLS relocation against non-thread local symbol.
PR ld/34444
PR ld/34448
* elf32-i386.c (elf_i386_tls_transition): Replace
_bfd_x86_elf_link_report_tls_invalid_section_error with
_bfd_x86_elf_link_report_error.
(elf_i386_scan_relocs): Issue an error for TLS relocation against
non-thread local symbol.
(elf_i386_relocate_section): Issue error for TLS, GOT and PLT
relocations in non-alloc and non-debugging sections.
* elf64-x86-64.c (elf_x86_64_tls_transition): Replace
_bfd_x86_elf_link_report_tls_invalid_section_error with
_bfd_x86_elf_link_report_error.
(elf_x86_64_scan_relocs): Issue an error for TLS relocation
against non-thread local symbol.
* elfxx-x86.c (_bfd_x86_elf_link_report_tls_invalid_section_error):
Renamed to ...
(_bfd_x86_elf_link_report_error): This. Add an argument for
link error type and handle it.
* elfxx-x86.h (elf_x86_error_type): New enum.
(_bfd_x86_elf_link_report_tls_invalid_section_error): Renamed
to ...
(_bfd_x86_elf_link_report_error): This. Add an argument of
enum elf_x86_error_type.
H.J. Lu [Thu, 30 Jul 2026 07:47:05 +0000 (15:47 +0800)]
x86-64: Return SHN_COMMON on non-ELF input
elf_x86_64_common_definition segfaults on PE/x86-64 input. Return
SHN_COMMON on non-ELF input. Linker now gets assertion fail at
bfd/coffgen.c:575, instead of getting segfault.
PR ld/34449
* elf64-x86-64.c (elf_x86_64_common_definition): Return
SHN_COMMON on non-ELF input.
Tom de Vries [Mon, 3 Aug 2026 19:09:48 +0000 (21:09 +0200)]
[gdb/testsuite] Require allow_xml_test in gdb.base/gcore.exp
I build gdb without xml support, and with test-case gdb.base/gcore.exp ran
into:
...
(gdb) core $outputs/gdb.base/gcore/gcore.test
warning: Can not parse XML target description; \
XML support was disabled at compile time
...
(gdb) FAIL: $exp: corefile restored general registers
...
Tom de Vries [Mon, 3 Aug 2026 18:54:12 +0000 (20:54 +0200)]
[gdb/testsuite] Require allow_xml_test in gdb.base/foll-fork-syscall.exp
I build gdb without xml support, and ran into:
...
(gdb) catch syscall chdir
warning: Can not parse XML syscalls information; \
XML support was disabled at compile time.
Unknown syscall name 'chdir'.^M
(gdb) FAIL: $exp: follow-fork-mode=parent: detach-on-fork=on: \
test_catch_syscall: catch syscall chdir
...
With test-case gdb.dwarf2/dw-form-strx-out-of-bounds.exp, I usually get:
...
(gdb) file dw-form-strx-out-of-bounds
Reading symbols from dw-form-strx-out-of-bounds...
(gdb) ptype global_var
DWARF Error: Offset from DW_FORM_GNU_str_index or DW_FORM_strx pointing \
outside of .debug_str_offsets section in CU at offset 0x2d1 [in module \
dw-form-strx-out-of-bounds]
No symbol "global_var" in current context.
(gdb) PASS: $exp: ptype global_var
...
But I just ran into:
...
(gdb) file dw-form-strx-out-of-bounds^M
Reading symbols from dw-form-strx-out-of-bounds...
DWARF Error: Offset from DW_FORM_GNU_str_index or DW_FORM_strx pointing \
outside of .debug_str_offsets section in CU at offset 0x2df [in module \
dw-form-strx-out-of-bounds]^M
(gdb) ptype global_var^M
No symbol "global_var" in current context.^M
(gdb) FAIL: $exp: ptype global_var
...
Fix this by:
- using "maint set dwarf synchronous on" to ensure that the error happens
during the file command
- updating the matching to check $gdb_file_cmd_msg
Tested gdb.dwarf2/dw-form-strx-out-of-bounds.exp and gdb.dwarf2/dw-form-strx.exp
using make-check-all.sh on x86_64-linux.
gdb: remove dead code in make_pointer_type and make_reference_type
At the end of `make_pointer_type` and `make_reference_type`, GDB
updates the length of every type in the chain. This is practically
dead code, because if we reach this point, we must have allocated a
new type. After a new allocation, the chain contains only the
newly-created type itself. See in `type_allocator::new_type ()`:
type->chain = type; /* Chain back to itself. */
That is, we always have `ntype == ntype->chain`. Therefore, the loop
can never be entered. Remove it.
In `make_reference_type`, we also remove `*reftype = ntype;`, because
a few lines above the assignment was already made. This is repeated
code.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Wed, 29 Jul 2026 14:06:06 +0000 (08:06 -0600)]
Fix type of imported variable for arraydim.exp
The test code for gdb.ada/arraydim.exp imports a variable using a
dummy type. Then the test tries to print the type of this variable.
This works ok with GCC, because the import is emitted as a
declaration; but this fails with gnat-llvm, where a definition is
emitted.
This seems to be a test bug to me. This patch fixes the problem by
using the correct type here.
Tom Tromey [Wed, 29 Jul 2026 18:40:03 +0000 (12:40 -0600)]
Always fetch Ada "main" name from the executable
The gdb.ada/file-then-restart.exp test was failing with gnat-llvm. I
tracked this down to the "main" name not being stored in a readonly
section, meaning that the code in ada_main_name using trust_readonly
did not work.
However, it seems to me that gdb should always prefer the data from
the executable in this particular case. So, rather than relying on
trust_readonly, this patch changes gdb to do this directly.
Andrew Burgess [Mon, 3 Aug 2026 11:53:27 +0000 (12:53 +0100)]
sim: avoid segfault in sim/cris/sim-if.c
When GDB is built with --target=cris-elf and launched with "gdb
./a.out", typing "target sim" causes a crash. The issue is that
STATE_PROG_ARGV may return NULL, and in sim_open this isn't tested
before dereferencing the pointer.
Alan Modra [Sun, 2 Aug 2026 11:58:33 +0000 (21:28 +0930)]
memory mayhem in _bfd_elf_link_read_relocs
Commit c6291d749a broke linking of objects with both REL and RELA
relocations applying to the same section. Unfortunately there appears
to be no test for this in the testsuite: The test added along with the
original support in commit 19dd00f891 verified creation of such
objects, but not their use as linker inputs. If you do take the
output of ld-tic6x/pcrel-reloc-local-r-rel-rela.d and feed it through
another ld -r stage, you typically get malloc/free corruption aborts.
The problem is that the REL buffer is being reused for RELA.
Commit 3a8864b3aa neglected to update the function comment.
This patch fixes both of these problems and extends the tic6c testcase
with a trick to insert an extra ld -r link stage.
bfd/
* elflink.c (_bfd_elf_link_info_read_relocs): Correct function
description. Correct buffer handling for the case where both
rel.hdr and rela.hdr are non-NULL. Rename variables for clarity.
ld/
* testsuite/ld-tic6x/pcrel-reloc-local-r-rel-rela.d: Add an
extra ld -r stage.
Tom de Vries [Fri, 31 Jul 2026 14:50:15 +0000 (16:50 +0200)]
[gdb/testsuite] Fix gdb.python/py-finish-breakpoint-tailcall.exp with gcc 16
On openSUSE Leap 16.0, with gcc 15.3.0, for test-case
gdb.python/py-finish-breakpoint-tailcall.exp I get:
...
(gdb) python MyFinishBreakpoint(frame)
Temporary breakpoint 2 at 0x40102a: file py-finish-breakpoint-tailcall.c, \
line 43.
(gdb) PASS: $exp: parent_frame=true: create finish breakpoint
...
And on openSUSE Tumbleweed, with gcc 16.1.1 I get instead:
...
(gdb) python MyFinishBreakpoint(frame)
Temporary breakpoint 2 at 0x40102a: file py-finish-breakpoint-tailcall.c, \
line 44.
(gdb) FAIL: $exp: parent_frame=true: create finish breakpoint
...
The only difference is in the line numbers, 43 and 44, both in main:
...
39 int
40 main (void)
41 {
42 int result = tailcall_function (42);
43 result -= global_var; /* Temporary breakpoint here. */
44 return result;
45 }
...
The executable is compiled with O2, and the code for main is different.
With gcc 15, we have:
... 0000000000401020 <main>:
401020: bf 2a 00 00 00 mov $0x2a,%edi
401025: e8 26 01 00 00 call 401150 <tailcall_function>
40102a: 8b 15 e0 2f 00 00 mov 0x2fe0(%rip),%edx
401030: 29 d0 sub %edx,%eax
401032: c3 ret
...
and the line number associated with 0x40102a, the first instruction after the
call is 43:
...
File name Line number Starting address View Stmt
py-finish-breakpoint-tailcall.c 43 0x40102a x
...
With gcc 16, the mov and sub have been merged:
... 0000000000401020 <main>:
401020: bf 2a 00 00 00 mov $0x2a,%edi
401025: e8 26 01 00 00 call 401150 <tailcall_function>
40102a: 2b 05 e0 2f 00 00 sub 0x2fe0(%rip),%eax
401030: c3 ret
...
and the line number info is different:
...
File name Line number Starting address View Stmt
py-finish-breakpoint-tailcall.c 43 0x40102a x
py-finish-breakpoint-tailcall.c 44 0x40102a 1 x
py-finish-breakpoint-tailcall.c 43 0x40102a 2
...
and gdb picks 44 in this case.
Fix this by merging lines 43 and 44 in the test-case:
...
- result -= global_var; /* Temporary breakpoint here. */
- return result;
+ return result - global_var; /* Temporary breakpoint here. */
...
Tested on x86_64-linux.
I've also verified that reverting the fix in commit e6bdfed6f5d ("gdb: fix
frame_unwind_caller_WHAT functions for inline and tail calls"), the commit
that introduced the test-case still makes the test-case fail.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33989
LIU Hao [Fri, 31 Jul 2026 11:52:14 +0000 (13:52 +0200)]
ld: Prevent `_tls_used` and `_load_config_used` from being garbage-collected
In mingw-w64 there's an ongoing effort to make the TLS directory of an image
optional and only linked on demand. The approach is to have the entrypoint
function reference TLS initialization callbacks through function pointers as
tentative definitions, and the object files where TLS initialization callbacks
are defined should ensure `_tls_used` is linked, by referencing its address in
file-scope static pointers.
The issue here is that data sections of those object files are not referenced
otherwise. During linking, if LD is passed `--gc-sections`, it garbage-collects
such sections along with `_tls_used`, leaving a symbol of value zero, which
results in a broken executable:
Jan Beulich [Fri, 31 Jul 2026 11:49:06 +0000 (13:49 +0200)]
RISC-V/gas: .attribute vs .insn
"... before any instruction", as the diagnostic from s_riscv_attribute()
says, presumably ought to include also insns resulting from .insn. Make a
small helper function.
Jan Beulich [Fri, 31 Jul 2026 09:52:08 +0000 (11:52 +0200)]
RISC-V: check operands for Zqinx
By analogy to Zdinx on RV32, register pair operands are presumably (there
not being any formal spec afaict) required to be encoded with the low bit
clear in RV64; in RV32 the low two bits need to be clear. Since match
functions don't have XLEN available, introduce respective flags, to be
used explicitly in assembler and disassembler.
Jan Beulich [Fri, 31 Jul 2026 09:51:12 +0000 (11:51 +0200)]
RISC-V: check operands for Zdinx in RV32
Like for Zilsd, register pair operands are required to be encoded with the
low bit clear. Since match functions don't have XLEN available, introduce
respective flags, to be used explicitly in assembler and disassembler.
Jan Beulich [Fri, 31 Jul 2026 08:57:36 +0000 (10:57 +0200)]
RISC-V: make FP rounding mode an optional operand
Model this after Vm (and somewhat after its VM counterpart): It's similarly
always last, and we can hence similarly reduce the number of entries in the
opcode table. The exception being FCVTMOD.W.D, where M needs using.
Jan Beulich [Fri, 31 Jul 2026 08:57:20 +0000 (10:57 +0200)]
RISC-V: drop FCVT.Q.L{,U} forms with rounding mode operand
Like FCVT.D.W{,U} and FCVT.Q.W{,U} these also are unaffected by rounding
mode, and hence allowing for a respective operand is bogus. (Otherwise
MASK_RM should also be used in the match field for the respectively other
forms.)
Jan Beulich [Fri, 31 Jul 2026 08:56:13 +0000 (10:56 +0200)]
bfd/RISC-V: Zv{b,k}* imply Zve32x
The specification is quite explicit about this. Since only forward
references are permitted within the table, the pre-existing Zv{b,k} block
needs moving up.
Add support to recognise 32 bit core file formats in AIX 7.3
In AIX 7.3 when we take core dump and analyse we get,
gdb/gdb /tmp/crash32 -c /tmp/core
...
Reading symbols from /tmp/crash32...
"/tmp/core" is not a core dump: file format not recognized
The reason being BFD is not able to recognise the same.
Alan Modra [Thu, 30 Jul 2026 05:24:23 +0000 (14:54 +0930)]
Remove BFD64 checks from rs6000-core.c
On a 32-bit system it is possible to build binutils with
--enable-64-bit-bfd or with --enable-targets choosing extra targets
that require a 64-bit bfd. So all of the BFD64 tests added in commit d6867a7559 and further modified in commit f03265d9cd are bogus, in
particular the removal of code by #ifndef BFD64. It looks to me that
this would break reading of core files in rs6000-aix4.2 or earlier.
Besides removing the BFD64 ifdefs this patch also initialises c_extoff
in a !CORE_NEW code path.
gdb, dwarf: update complaint logic in read_tag_pointer_type
There is nested branching in `read_tag_pointer_type` with non-trivial
conditions. I think what is meant there is if there is a non-default
address class attribute for the type, alignment and size changes are
acceptable. Otherwise we should check for unexpected size and
alignment, and complain about them. This patch updates the logic.
In particular:
- If addr_class is default, byte_size does not match the expectation,
and the architecture defines the address_class_dwarf_to_id hook
method, code before the patch does not complain about pointer size
whereas the new code complains.
- If addr_class is non-default, byte_size does not match the
expectation, and the architecture does not define the
address_class_dwarf_to_id hook method, code before the patch
complains about pointer size whereas the code after does not
complain.
(Similar cases for alignment mismatch instead of type size, too.)
I think the new behavior is what was intended and it yields simpler
code.
H.J. Lu [Thu, 30 Jul 2026 07:10:36 +0000 (15:10 +0800)]
ld: Don't define section symbols for excluded sections
When the SEC_EXCLUDE bit is set on a section, for example, sections with
the SHF_EXCLUDE flag bit set in ELF input, the contents of the section
are excluded by the linker for non-relocatable output. Define __start,
__stop, .startof. and .sizeof. symbols for relocatable link or if the
SEC_EXCLUDE bit on the section is cleared.
PR ld/34448
* ldlang.c (lang_init_start_stop): Call lang_define_start_stop
for relocatable link or if the SEC_EXCLUDE bit on the section
is cleared.
Alan Modra [Thu, 30 Jul 2026 05:32:21 +0000 (15:02 +0930)]
Re: PR 30308 more unbounded recursion
Commit 85fb82cc8c had some errors. The extra places marking and
clearing syms as resolving didn't take into account that the sym might
already be so marked and thus should not be cleared. Fixing that
cured the first testcase addition, but not the second. Even worse is
that fact that marking X_add_symbol when trying to simplify
X_op_symbol would make it impossible to simplify x==x or other such
expressions where the symbols are the same (or the same via equates,
making a test for X_add_symbol != X_op_symbol harder). So commit 85fb82cc8c needs reverting.
When I analysed what was going on with the second testcase addition,
and reanalysed the testcase added in commit 85fb82cc8c, I decided a
better fix was to immediately fail on hitting a symbol loop; It was
the simplification done in i386_intel_simplify_symbol after hitting a
symbol loop that made the "resolving" mark set on syms insufficient.
* config/tc-i386-intel.c (i386_intel_simplify_symbol): Return
NULL on finding symbol loops.
(i386_intel_simplify): Revert commit 85fb82cc8c marking and
clearing "resolved" for X_add_symbol. For O_add, don't
simplify after i386_intel_simplify_symbol returns NULL.
* testsuite/gas/i386/intel-equ-loop.l,
* testsuite/gas/i386/intel-equ-loop.s: Extend testcase.
H.J. Lu [Thu, 23 Jul 2026 23:01:35 +0000 (07:01 +0800)]
x86: Generate PLT32 relocation for ".long foo@PLT - .L4"
LLVM assembler supports directives like ".long foo@PLT - .L4" for i386
and x86-64. Implement the same feature to generate PLT32 relocation
for directives like ".long foo@PLT - .L4" so that PLT entries are used
to resolve the PC32 relocation against function symbols.
PowerPC: Fix compile command by reverting to default code model
On ppc64le, the "compile" command produces corrupted code when the
compiled expression takes the address of a symbol in the inferior.
For example:
(gdb) break -qualified main
(gdb) run
(gdb) compile code pmf = &A::get_var1
(gdb) x/2gx &pmf
0x7fffffffeb68: 0x0000800010000d78 0x0000000000000000
The stored address is wrong: the low 32 bits are correct
(0x10000d78, the true address of A::get_var1) but bit 47 is
incorrectly set. When the compiled code later calls through such a
pointer the inferior jumps to unmapped memory and receives SIGSEGV.
Commit 533f04079c7 ("[gdb] [rs6000] Add
ppc64_linux_gcc_target_options method.") made ppc64 return an empty
string from gdbarch_gcc_target_options, overriding the
"-m64 -mcmodel=large" that default_gcc_target_options supplies for
64-bit targets, so GCC uses -mcmodel=medium instead.
With the medium model, references to the inferior's symbols are
compiled as TOC-relative accesses using R_PPC64_TOC16_HA/LO
relocations, whose combined displacement is a signed 32-bit value
(+/- 2GB). GDB allocates the compiled module in the inferior with an
mmap that the kernel places in the high mmap region (e.g. around
0x7ffff7f30000), while the inferior's own text is low (e.g. around
0x10000000). The distance between them is close to 2^47, far beyond
the reach of a TOC16 relocation, so the displacement is silently
truncated to 32 bits, producing an address that is off by 2^47.
Revert 533f04079c7 so that ppc64 again uses
default_gcc_target_options ("-m64 -mcmodel=large"). With the large
model GCC emits a real .toc section and loads addresses as full
64-bit values from it, so the only TOC-relative references are into
the module's own .toc, always in range wherever the module is mapped.
The .TOC. handling from commit bad23de3543 ("[gdb] Handle .TOC.
sections during gdb-compile for rs6000 target.") still applies, now
resolving via the genuine .toc section rather than the .text fallback
the medium model required.
Rohr, Stephan [Tue, 28 Jul 2026 08:01:13 +0000 (10:01 +0200)]
[pre-commit] add 'tomli' dependency for codespell pre-commit hook
The codespell pre-commit hook imports the 'tomllib' module to parse
'pyproject.toml'. 'tomllib' is not available for Python versions 3.10
and older. Add a dependency on 'tomli' so the hook also works on these
Python versions.
projects / thirdparty / binutils-gdb.git / log
