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.
MAINTAINERS: Add Maciej W. Rozycki as a global maintainer
By Nick Clifton's appointment and with the endorsement of Alan Modra
I have the privilege to become a global maintainer. Thank you for
the trust put in me.
Andrew Burgess [Thu, 30 Apr 2026 08:29:38 +0000 (09:29 +0100)]
gdb/tui: fix debuginfod prompt using 'C-x C-a' to enter TUI
This commit ties closely into the previous commit. The previous
commit looks at issues that can arise when using 'tui enable' to enter
TUI mode if a debuginfod prompt is triggered. This commit looks at
the problems that can arise when a multi-key combination is used to
enter TUI mode, e.g. 'C-x C-a'. Bug PR gdb/33794 discusses this
issue.
There has been a previous attempt to address this issue here:
The approach taken in that patch was to prevent switching to TUI mode
if debuginfod is still in ASK mode, this means the switch could
potentially trigger a secondary prompt.
While the previous commit is relatively simple, the complexity in this
case arises from how multi-key combinations are handled by readline.
Currently global readline state is used to track the multi-key press
situation, and when the multi-key is dispatched back to application
(GDB) code, the globals are still live.
If GDB then triggers reentry into readline, e.g. by triggering a
secondary prompt, the call into readline for this prompt will cause
the global state to be released. When the secondary prompt is
finished and we return back to readline the global state will be
accessed, and undefined behaviour occurs, including crashes.
The core idea of my proposed solution to this is to move handling of
the multi-key actions out of the readline callback, and into GDB's
normal event loop.
When the user presses a combination like 'C-x C-a' this will call a
templated tui_rl_keybinding function as it currently does, but instead
of immediately forwarding to another function to carry out the TUI
changes, we instead schedule a callback with the event loop and then
return.
As far as readline is concerned the multi-key action has now been
dealt with, however, no interface changes have yet occurred. As
readline has now finished handling this key press, readline returns to
the event loop to get the next user input.
At the event loop the pending callback is seen and dispatched. This
callback triggers the actual UI changes, e.g. entering TUI mode. As
we are not inside readline at this point we are free to create
secondary prompts if needed.
In tui_rl_keybinding we use run_on_main_thread to schedule a callback
with the event loop, but there are some additional changes needed:
1. If we changed the tui_active state then we need to call
reinitialize_more_filter. Previously tui_rl_switch_mode would call
rl_newline which would make readline think that a command had been
fully entered, this would trigger a call to GDB's
command_line_handler, which calls command_handler, which then calls
reinitialize_more_filter.
For reasons explained below tui_rl_switch_mode can no longer call
rl_newline, so the reinitialize_more_filter is never reached. This
means that especially when switching CLI to TUI, when the `cmd`
window is smaller than the CLI terminal, GDB might enter TUI mode
thinking that the TUI is already full. This leads to incorrect
pager prompts appearing. Resolve this by explicitly resetting the
pager.
2. After changing the tui_active state (i.e. entering or leaving TUI
mode), there will not be a GDB prompt displayed. Under the old
scheme, the rl_newline call in tui_rl_switch_mode would trick GDB
into thinking an empty command had just been completed, this would
then trigger a prompt redisplay.
Under the new scheme we need to explicitly call display_gdb_prompt
or tui_redisplay_readline to redraw the prompt. However, as we
were at a GDB prompt already when the user pressed a key like 'C-x
C-a', the current_ui will not think that a prompt is needed, if we
plan to call display_gdb_prompt then we'll need to change the
prompt_state to PROMPT_NEEDED before calling display_gdb_prompt.
When possible we prefer calling tui_redisplay_readline, as this
preserves the current readline input line buffer contents, so if
the user types something at the prompt and then does 'C-x o' to
change window focus, the partially typed text is preserved.
Both of these additional actions need to be performed for both the
normal exit path, and the exception path in order that the prompt be
correctly displayed, so this code is done in a SCOPE_EXIT block.
The other set of changes are in tui_rl_switch_mode:
1. The calls to rl_prep_terminal are no longer needed as
display_gdb_prompt will take care of calling this for us if
appropriate (e.g. we are not in TUI mode).
2. The gdb_exception_forced_quit handling can now just propagate the
exception, We are no longer within a readline callback, and so can
throw this exception further up the stack.
3. Likewise with gdb_exception, we can re-throw this. As the
run_on_main_thread mechanism silently swallows all gdb_exceptions
except the gdb_exception_forced_quit sub-class, we do need to print
the exception ourselves first though. This is why we had to
separate out the gdb_exception_forced_quit handling.
4. The rl_kill_text call is no longer needed as the following
rl_newline call is going to be removed.
5. The rl_newline call was a neat trick to force a prompt redisplay,
but this only works when we are within a readline callback, it
injects a newline so that when we return from this callback
readline will see the pending newline character, process the now
empty line (thanks to the rl_kill_text call), and the print the
prompt. This is replaced by the display_gdb_prompt call that was
added to tui_rl_keybinding.
6. The dont_repeat call was needed because the rl_kill_text and
rl_newline calls were tricking readline into thinking the user had
pressed Enter on an empty line, this was done to force a prompt
redisplay.
However, pressing Enter on an empty line repeats the previous
command unless dont_repeat has been called. Now we don't use the
rl_newline trick, the dont_repeat call is not needed.
The gdb.tui/debuginfod-query.exp test is updated to include tests that
switch using multi-key combinations.
Andrew Burgess [Tue, 28 Apr 2026 06:40:11 +0000 (07:40 +0100)]
gdb/tui: fix for debuginfod prompt while enabling the TUI
PR tui/31449 reports a SIGFPE when the debuginfod query happens while
enabling TUI using the "tui enable" command:
Thread 1 "gdb" received signal SIGFPE, Arithmetic exception.
0x0000000001021084 in tui_inject_newline_into_command_window () at /data/vries/gdb/src/gdb/tui/tui-io.c:1096
1096 py += px / tui_cmd_win ()->width;
due to divide-by-zero because tui_cmd_win ()->width == 0.
The corresponding backtrace is:
(gdb) bt
#0 0x0000000001021084 in tui_inject_newline_into_command_window () at gdb/tui/tui-io.c:1096
#1 0x0000000000fe65fd in gdb_readline_wrapper_line (line=...) at gdb/top.c:939
#2 0x0000000000944eef in gdb_rl_callback_handler (rl=0x2cc865a0 "n") at gdb/event-top.c:288
#3 0x0000000001175779 in rl_callback_read_char () at readline/readline/callback.c:302
#4 0x0000000000944bc3 in gdb_rl_callback_read_char_wrapper_sjlj () at gdb/event-top.c:197
#5 0x0000000000944cd4 in gdb_rl_callback_read_char_wrapper_noexcept () at gdb/event-top.c:240
#6 0x0000000000944d52 in gdb_rl_callback_read_char_wrapper (...) at gdb/event-top.c:252
#7 0x0000000001062352 in stdin_event_handler (error=0, client_data=0x2c865150) at gdb/ui.c:154
#8 0x0000000001a04edf in handle_file_event (file_ptr=0x2ccf8850, ready_mask=1) at gdbsupport/event-loop.cc:551
#9 0x0000000001a05522 in gdb_wait_for_event (block=1) at gdbsupport/event-loop.cc:672
#10 0x0000000001a043ff in gdb_do_one_event (mstimeout=-1) at gdbsupport/event-loop.cc:263
#11 0x00000000006d5480 in interp::do_one_event (this=0x2cc2af20, mstimeout=-1) at gdb/interps.h:93
#12 0x0000000000fe670d in gdb_readline_wrapper (prompt=0x2ccca4e0 "Enable debuginfod for this session? (y or [n]) ") at gdb/top.c:1033
#13 0x00000000010c6853 in defaulted_query(...) (...) at gdb/utils.c:844
#14 0x00000000010c6b8a in nquery (...) at gdb/utils.c:901
#15 0x00000000007a9324 in debuginfod_is_enabled () at gdb/debuginfod-support.c:268
#16 0x00000000007a950d in debuginfod_source_query (...) at gdb/debuginfod-support.c:311
#17 0x0000000000efc2c7 in open_source_file (s=0x2cc8f4b0) at gdb/source.c:1152
#18 0x0000000000efc619 in symtab_to_fullname (...) at gdb/source.c:1214
#19 0x0000000000f5ebb3 in find_line_symtab (...) at gdb/symtab.c:3287
#20 0x0000000000f5f0e5 in find_pc_for_line (...) at gdb/symtab.c:3391
#21 0x0000000001011f54 in tui_get_begin_asm_address (...) at gdb/tui/tui-disasm.c:404
#22 0x000000000104888d in tui_source_window_base::rerender (this=0x2cbdc570) at gdb/tui/tui-winsource.c:474
#23 0x0000000001028e81 in tui_win_info::resize (this=0x2cbdc570, height_=21, width_=127, origin_x_=0, origin_y_=0) at gdb/tui/tui-layout.c:299
#24 0x00000000010297d0 in tui_layout_window::apply (this=0x2cc50350, x_=0, y_=0, width_=127, height_=21, preserve_cmd_win_size_p=false) at gdb/tui/tui-layout.c:432
#25 0x000000000102bfea in tui_layout_split::apply (this=0x2caea920, x_=0, y_=0, width_=127, height_=33, preserve_cmd_win_size_p=false) at gdb/tui/tui-layout.c:1026
#26 0x0000000001028267 in tui_apply_current_layout (...) at gdb/tui/tui-layout.c:68
#27 0x0000000001028737 in tui_set_layout (layout=0x2c9b9e90) at gdb/tui/tui-layout.c:133
#28 0x0000000001028af5 in tui_set_initial_layout () at gdb/tui/tui-layout.c:209
#29 0x000000000104b795 in tui_enable () at gdb/tui/tui.c:496
#30 0x000000000104bab3 in tui_enable_command (args=0x0, from_tty=1) at gdb/tui/tui.c:591
#31 0x00000000006c5ffe in do_simple_func (args=0x0, from_tty=1, c=0x2c9bb2f0) at gdb/cli/cli-decode.c:94
#32 0x00000000006cc94f in cmd_func (cmd=0x2c9bb2f0, args=0x0, from_tty=1) at gdb/cli/cli-decode.c:2831
#33 0x0000000000fe53ad in execute_command (p=0x2c86699a "", from_tty=1) at gdb/top.c:563
#34 0x000000000094584d in command_handler (command=0x2c866990 "tui enable") at gdb/event-top.c:611
#35 0x0000000000945dfe in command_line_handler (rl=...) at gdb/event-top.c:844
#36 0x000000000101e916 in tui_command_line_handler (rl=...) at gdb/tui/tui-interp.c:101
#37 0x0000000000944eef in gdb_rl_callback_handler (rl=0x2cc86a30 "tui enable") at gdb/event-top.c:288
#38 0x0000000001175779 in rl_callback_read_char () at readline/readline/callback.c:302
#39 0x0000000000944bc3 in gdb_rl_callback_read_char_wrapper_sjlj () at gdb/event-top.c:197
#40 0x0000000000944cd4 in gdb_rl_callback_read_char_wrapper_noexcept () at gdb/event-top.c:240
#41 0x0000000000944d52 in gdb_rl_callback_read_char_wrapper (...) at gdb/event-top.c:252
#42 0x0000000001062352 in stdin_event_handler (error=0, client_data=0x2c865150) at gdb/ui.c:154
#43 0x0000000001a04edf in handle_file_event (file_ptr=0x2ccf8850, ready_mask=1) at gdbsupport/event-loop.cc:551
#44 0x0000000001a05522 in gdb_wait_for_event (block=1) at gdbsupport/event-loop.cc:672
#45 0x0000000001a043ff in gdb_do_one_event (mstimeout=-1) at gdbsupport/event-loop.cc:263
#46 0x00000000006d5480 in interp::do_one_event (this=0x2cc2af20, mstimeout=-1) at gdb/interps.h:93
#47 0x0000000000b77f25 in start_event_loop () at gdb/main.c:403
#48 0x0000000000b78113 in captured_command_loop () at gdb/main.c:468
#49 0x0000000000b7a07c in captured_main (context=0x7fff660b9e60) at gdb/main.c:1381
#50 0x0000000000b7a178 in gdb_main (args=0x7fff660b9e60) at gdb/main.c:1400
#51 0x0000000000419705 in main (argc=5, argv=0x7fff660b9f98) at gdb/gdb.c:38
(gdb)
The problem is that while the TUI is being enabled for the first time,
none of the TUI windows yet exist. As each window is created its
contents are rendered (i.e. filled in based on GDB's state), which for
some windows can trigger an interactive prompt, in this case a missing
source file triggers a debuginfod prompt while trying to render the
`src` window.
The interactive prompt will be written to the `cmd` window, but at
this point the `cmd` window has not yet been created.
There have been several different attempts to fix this issue:
The patch presented here is similar to what was presented in (3)
above, but I think the implementation is maybe a little simpler.
Additionally, all but (6) of the above patches don't address issues
related to using multi-key combinations like 'C-x C-a' to enable TUI
mode, and that patch just takes the (admittedly safe) approach of
preventing the user from activating the TUI using a multi-key
combination if debuginfod is in ASK mode (and so could trigger an
interactive prompt).
This patch doesn't address the multi-key problem, that is left for the
next patch in this series.
This patch ensures that the `cmd` window always exists before
rendering the windows (i.e. filling in their content). This is done
by introducing a tui_defer_rerender global which is set in tui_enable,
and checked in tui_win_info::resize. Then, prior to the prompt being
displayed, if the flag is set, we render the contents of all visible
windows. This can trigger a secondary prompt (e.g. the debuginfod
prompt), but by this point the `cmd` window exists, and can display
the prompt.
The debuginfod-query.exp test included here is based on the test Tom
de Vries wrote for one of his patches listed above, but extended to
cover some additional cases. The activate-with-key-combo.exp test is
new for this series.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31449 Co-Authored-By: Tom de Vries <tdevries@suse.de>
Andrew Burgess [Tue, 28 Apr 2026 10:06:48 +0000 (11:06 +0100)]
gdb/tui: prevent TUI activation from a secondary prompt
The TUI can be activated with key combinations like 'C-x C-a'. This
is handled by readline calling the function tui_rl_switch_mode, or
various other functions which indirectly call that function.
These multi-key combinations can be used even at a secondary prompt,
e.g. the:
Make breakpoint pending on future shared library load? (y or [n])
The problem with this is that when the TUI activates CLI content
doesn't carry over into the `cmd` window, so the secondary prompt is
not visible to the user after the mode switch. Worse, because the
content doesn't carry over we clear the readline state, and this
involves sending a '\n' to readline. This newline will select the
default action at the secondary prompt, which might not be what the
user actually wants.
Now, we could imagine trying to "fix" this so that the CLI content is
copied over into the `cmd` window, and the secondary prompt is
represented to the user, so they can then make the choice they want,
but implementing this fix would be a big job, for very little gain.
I think it is easier to just prevent the user switching to TUI mode
while at a secondary prompt.
I created a new templated wrapper function tui_rl_keybinding, which is
then used to wrap every function that is bound to a readline multi-key
combination. The wrapper function checks if we are in a secondary
prompt, and if we are, performs an early return.
For completeness, I've added an assert that we are not in a secondary
prompt to all of the wrapped functions, this (hopefully) will help
catch cases where these functions are called directly without going
through the wrapper. I also added the same assert to
tui_rl_command_key and tui_rl_command_mode which are not themselves
wrapped functions, but are only used when in single key mode, and it
is not possible to enter single key mode when at a separate prompt,
see tui_rl_startup_hook (which checks for being at a secondary prompt)
and tui_rl_next_keymap (which is wrapped).
There's a new helper proc added to lib/gdb.exp, this will be used by
additional tests later in this series.
The user can still switch to TUI mode at the primary '(gdb)' prompt.
Andrew Burgess [Tue, 28 Apr 2026 12:59:22 +0000 (13:59 +0100)]
gdb/testsuite: fix tuiterm linefeed scrolling new line content
I came across a bug in the implementation of line feed in tuiterm.
Consider the gdb.tui/tuiterm.exp test 'test_linefeed_scroll', before
sending the line feed we have:
Notice that the new line #3 retains its previous contents, all lines
have scrolled up, with the old line #0 having been moved off the
terminal, but the new line is starting with these cloned contents.
I don't believe this is correct. My understanding is that new lines
should be created empty -- or really full of space characters.
After fixing this issue so that new lines are created empty, the only
test failure is the tuiterm.exp unit test mentioned above, this was
added in commit:
This commit is fixing an issue with cursor placement after a scroll,
there is no mention of the content of the new line, which makes me
think that the test is just checking whatever behaviour used to be
there.
In this commit I think we should fix the new line content, and update
the existing unit test to match the new behaviour.
Andrew Burgess [Mon, 27 Apr 2026 20:18:56 +0000 (21:18 +0100)]
gdb/tui: convert a window handle `if` into an `assert`
It should only be possible to call tui_win_info::refresh_window on a
window with a valid handle member. To do otherwise would suggest
we're trying to draw to the screen a window which GDB doesn't think is
part of the current layout, which is just wrong.
Currently tui_win_info::refresh_window guards its content with an
`if (handle != NULL)`, but this can be changed to an assert.
A similar assert can be added to
tui_source_window_base::refresh_window, there's no `if` in this
function, which only backs up the reasoning in the first paragraph.
There should be no user-visible changes after this commit.
gdb.rocm/watchpoint-basic: add XFAILs for known configurations
Some of the tests in gdb.rom/watchpoint-basic are destined to fail
due to a problem in KFD. This patch marks those tests as such on
configurations that this can happen.
Reviewed-by: Tankut Baris Aktemur <tankutbaris.aktemur@amd.com> Approved-by: Luis Machado <luis.machado.foss@gmail.com>
Jan Beulich [Mon, 27 Jul 2026 07:14:57 +0000 (09:14 +0200)]
aarch64: remove casts from more struct initializers
Commit 0e89ce812b79 ("aarch64: Remove cast from struct initializer")
didn't go quite far enough: The building of aarch64-gen itself has a
similar issue. Cover that as well. Since FLD_CONST_* are used only there,
move their #define-s there rather than introducing more #undef-s.
Alan Modra [Mon, 27 Jul 2026 05:28:50 +0000 (14:58 +0930)]
Use ufile_ptr for file position
This is in response to a fuzzed objcopy test that overflows file_ptr
addition. It makes sense to use an unsigned value for current file
offset, and allows a couple of casts to be removed.
* elf.c (assign_file_positions_for_load_sections): Make off unsigned.
(assign_file_positions_except_relocs): Likewise.
(_bfd_elf_assign_file_positions_for_non_load): Likewise.
Alan Modra [Mon, 27 Jul 2026 01:57:45 +0000 (11:27 +0930)]
DWARF1 AT_sibling sanity check
I am not absolutely certain that DWARF version 1 AT_sibling always
points forward, but that seems to be the case for gcc-3.3 from a quick
look at gcc/dwarfout.c and examining some i686-linux output. I
believe gcc stopped supporting DWARF version 1 after gcc-3.3.
If backward links are allowed then it is considerably more tedious to
protect against fuzzed object files that loop forever reading DWARF1.
So this patch may break addr2line and objdump -dS for some old files.
If it does, well, removing DWARF1 support entirely would break that
support too. (readelf doesn't support DWARF version 1).
* dwarf1.c (parse_die): Replace abfd and aDiePtrEnd parameters
with stash pointer. Adjust to suit. Sanity check AT_sibling
value.
(parse_functions_in_unit, _bfd_dwarf1_find_nearest_line): Adjust
parse_die calls.
projects / thirdparty / binutils-gdb.git / log
