Matthieu Longo [Thu, 17 Apr 2025 14:02:18 +0000 (15:02 +0100)]
gas: use common code for object attribute v1 & v2 parsing
Since the previous patch added all the code to be able to parse both
OAv1 and OAv2 directives, this patch switches OAv1 to use this common
code.
Additionally to the common code in obj-elf.c, the following backends
using a custom object attribute directive were impacted.
- ARC
- Arm
- m68k
- PowerPC
- RISC-V
- TI C6X
A parsing test for Arm had to be adapted to the error messages of the
new parser.
The gas and ld test suites were successfully run for the following
backends: S390, ARC, Arm, CSky, m68k, msp430, PowerPC, TI C6X, RISC-V,
AArch64, MIPS, SPARC.
Richard Ball [Tue, 28 Jan 2025 17:06:58 +0000 (17:06 +0000)]
gas: implement parsing of object attributes v2
This patch adds the parsing logic for Object Attributes v2 (OAv2), enabling
Gas to interpret and process these attributes correctly. It also updates the
AArch64 backend to utilize the new parsing capabilities, and handle the new
AArch64-specific directives.
This patch relies on the abstractions introduced in the previous patch to
store the data. Its scope is limited to parsing the new assembly directives,
checking the inputs, and storing the data into the relevant OAv2 abstractions.
Note that, for now, the new parsing capabilities are only available for AArch64.
Even if the implementation was splitted into a generic part available in
gas/config/obj-elf.c, and an AArch64-specific one in gas/config/tc-aarch64.c,
the lack of GNU generic directives to handle OAv2 prevented the capability
from being exposed to others backends.
** GNU assembler interface for aeabi subsections
OAv2 introduced two new directives for AArch64:
- .aeabi_subsection name, comprehension, encoding
Create or switch the current subsection to 'name'.
Comprehension values can be 'required' or 'optional'.
Encoding values are limited for now to 'ULEB128', and 'NTBS'
The comprehension and encoding are mandatory arguments on the first
declaration of the subsection, but become optional for subsequent
ones.
- .aeabi_attribute tag, value
Set 'tag' to 'value' in the current subsection.
Tag can either be an integer, or one of the defined symbols in the backend.
The usage of those directives will error if the following requirements
are breached:
- If the subsection X has been previously declared, the comprehension and
encoding parameters of the current .aeabi_subsection that redeclares X
have to match with the previous declaration. If those parameters are
omited, no check is performed.
- The type of the value set via .aeabi_attribute has to align with
the current subsection.
- If the tag N has already been declared for the current subsection, a
later assignment to tag N is tolerated only if the newly set value is
equal to the former one. This check is stricter than needed. Ideally,
the tag N's values should be merged together, and an error should be
raised only if an incompatibility is detected. Because the attributes
are set in one chunk by GCC, there is no real use case for such a merge.
The new parsing code is enabled/disabled via the TC_OBJ_ATTR_v1 and
TC_OBJ_ATTR_v2 defines, and supports the following configurations:
- enable both OAv1 and OAv2 parsing. This is currently used by no
target, but is useful for migration from OAv1 to OAv2.
- enable OAv1 parsing only. This is used by all targets supporting OAs
except for AArch64.
- enable OAv2 parsing only. This is only used by AArch64.
** Regarding the implementation
The logic of OAv1 does not always keep separated the different data processing
steps: parsing, convertion to internal abstractions, error checking and further
processing (if any) on those abstractions, and their serialization into the
object files.
This patch takes into account the specifities of syntax for OAv1 and OAv2, but
mutualize as much as possible the common behavior so that the same methods can
be used for parsing the OAv1 and OAv2 directives.
However, the mutualization of the code is limited by a different internal model
for OAv1 and OAv2. Even if it is technically feaseable to have only one middle
-end for OAv1, OAv2 and even GNU properties, sharing the same data model to
perform the merge logic with the same code, it is a significant amount of work.
This extra work was not considered as a part of this new feature, so this patch
series will stick with the minimum of mutualization as possible.
Co-Authored-By: Matthieu Longo <matthieu.longo@arm.com>
Richard Ball [Mon, 20 Jan 2025 13:01:12 +0000 (13:01 +0000)]
Object Attributes v2: new abstractions for subsections and attributes
This patch lays the groundwork for the support of Object Attributes v2 (OAv2).
OAv2 is an enhancement of OAv1. They retain successful aspects of OAv1, define
the relationship between object attributes and existing GNU properties, separate
architectural requirements from software ABI requirements, and simplify the
format to make it easier for OAv2 consumers to parse, and skip subsections and
attributes. Interestingly, OAv2 have only one scope: the whole relocatable file
where they were specified. For the reason behind this choice, see [1], "Build
attributes at file scope only". This document also provides more insights into
the design rationale for OAv2.
Even if OAv2 was designed primarily for AArch64, this implementation splits the
generic core logic from the backend-specific one, and aims at facilitating OAv2
adoption by others backend. This logic will apply for any subsequent OAv2 patch.
New abstractions for attributes and subsections are introduced in bfd/elf-attrs.h
Those align with the format of OAv2 proposed in [2].
An object attribute obj_attr_v2 is a tag-value pair:
- tag: a key, i.e. a unique identifier for the attribute in the
subsection.
- value: a variant for which the interpretation depends on the encoding
set in the subsection it was stored in. 2 types of values are possible:
ULEB128 (Unsigned Little Endian Base 128) or a string encoded as NTBS
(Null-Terminated Byte String).
A subsection obj_attr_subsection_v2 has the following members:
- name: the name of this subsection.
- scope: the prefix in the subsection name determines whether the
subsection is public or private.
- optionality: is this subsection optional or required ? Depending on
whether the subsection is public or private, it can be ignored by the
consumer.
- encoding: see previous note regarding the value of an attribute. This
encoding applies to all the attributes in this subsection.
- list of object attributes.
Even if OAv1 and OAv2 data structures are similar, their processing is
different. Thus refactoring the code of OAv1 and OAv2 to share it does not
seem the right approach for clarity and maintainability, and minimalization
of the risk of introducing regressions.
Consequently, utility functions to initialize, copy, swap, free, compare,
mutate, and sort those structures won't be shared between OAv1 and OAv2.
Finally, the version ID used to identify the storage format of the object
attributes is object and backend dependent. This approach allows mixing
OAv1 and OAv2 in input objects. Then the deserializer translates the input
data to the internal model (currently OAv2, but it could be a more generic
one in the future) to perform the merge. In the end, the output format is
set by the backend: OAv2 for AArch64, OAv1 for others. The only exception
for this is objcopy, which won't change the format of the object attributes,
and will preserve the format of the data during the copy.
Hopefully, this mechanism will make easy the migration from OAv1 to OAv2 if
anyone is interested.
[1]: [Design Rationale for Build Attributes for the Arm 64-bit Architecture (AARCH64)]
(https://github.com/ARM-software/abi-aa/blob/eec881270d5e3b23e58a6250640d06ff545ec1fc
/design-documents/buildattr64-rationale.rst)
[2]: [Build Attributes for the Arm® 64-bit Architecture (AArch64)](https://github.com
/ARM-software/abi-aa/blob/eec881270d5e3b23e58a6250640d06ff545ec1fc/buildattr64
/buildattr64.rst)
Co-Authored-By: Matthieu Longo <matthieu.longo@arm.com>
Tom de Vries [Thu, 22 Jan 2026 09:48:45 +0000 (10:48 +0100)]
[gdb/symtab] Fix segfault in cutu_reader::read_toplevel_die
PR 33818 reports a problem when running test-case
gdb.ada/uninitialized-variable-record.exp:
...
(gdb) print y2
dwarf2/read.c:14073:20: runtime error: member access within null pointer of \
type 'struct dwarf2_cu'
ERROR: GDB process no longer exists
...
bisecting to commit 2f23cf07253 ("[gdb] Add regression test for PR
symtab/33777").
I managed to reproduce it using target board readnow.
The problem is here in cutu_reader::read_toplevel_die:
...
m_new_cu.get ()->per_objfile->per_bfd->nr_toplevel_dies_read++;
...
Class cutu_reader has two fields pointing to a dwarf2_cu:
...
/* The CU of the DIE we are parsing. */
struct dwarf2_cu *m_cu;
...
and:
...
dwarf2_cu_up m_new_cu;
...
and m_new_cu is not always set.
Fix this by using m_cu instead.
Reported-By: Jan Vrany <jan.vrany@labware.com Suggested-By: Simon Marchi <simon.marchi@efficios.com>
Tested on x86_64-linux.
reset_resolved_wilds didn't clear out matching_sections in output
sections with constraint -1. Fix that and tidy call sites of
obstack_init and obstack_free for matching_obstack so that the obstack
is allocated later and freed completely. Also tidy ptroot.
PR 33821
* ldlang.c (the_root): Delete, replacing with..
(ptroot): ..this, no longer a pointer. Update all uses.
(lang_for_each_statement_worker): Add "constrained" param.
Ignore os.constraint if false.
(reset_resolved_wilds): Use lang_for_each_statement_worker.
Move obstack_init..
(lang_init): ..and this obstack_init of matching_obstack..
(resolve_wilds): ..to here.
* ldlang.h (lang_for_each_statement_worker): Update declaration.
(lang_for_each_statement): Update.
* emultempl/xtensaelf.em: Update lang_for_each_statement_worker
calls throughout.
Alan Modra [Mon, 19 Jan 2026 23:57:45 +0000 (10:27 +1030)]
sframe fre sanity checks
I noticed the fre esz check in flip_sframe_fdes_with_fres_* was wrong,
testing against the full buffer size rather than the remaining size.
It is also ineffective at stopping buffer overflows to check after the
buffer accesses have occurred.
Likely many more buffer overflow checks in the sframe code are needed
before anyone can claim it is secure. Even in the fre code, I see
things like sframe_decoder_get_fres_buf merrily iterating over fres
without a concern for buffer overflow.
* sframe.c (flip_fre): Add fp_size param. Use it to avoid
buffer overflow on fuzzed input.
(flip_sframe_fdes_with_fres_v2): Pass remaining buffer size to
flip_fre. Remove now redundant and wrong esz check.
(flip_sframe_fdes_with_fres_v3): Likewise.
Tom Tromey [Sun, 18 Jan 2026 17:09:19 +0000 (10:09 -0700)]
Remove lookup_transparent_type lang hook
C++ was the only user of the lookup_transparent_type lang hook, so it
can be removed entirely. basic_lookup_transparent_type and its helper
function are renamed as appropriate.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Sun, 18 Jan 2026 17:05:23 +0000 (10:05 -0700)]
Remove cp_lookup_transparent_type
cp_lookup_transparent_type seems to be a workaround for bugs in very
old compilers. A comment mentions that the bugs are fixed in GCC 3.4
-- released in 2004.
I think this is long past due for removal, which this patch does.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Alan Modra [Wed, 21 Jan 2026 04:57:34 +0000 (15:27 +1030)]
hppa64 root.u.def assertions
The aim here is to add assertions when root.u.def is accessed that
the field is valid, ie. we have a bfd_link_hash_defined or
bfd_link_hash_defweak symbol. On doing so I found the assertion
triggering on one of the ld undefweak tests, fixed with the
elf64_hppa_finish_dynamic_symbol change.
The patch also refactors code using text_hash_entry and
data_hash_entry.
* elf64-hppa.c (elf64_hppa_finish_dynamic_symbol): Use zero
value for both undefined and undefweak symbols, and when
non-pic too. Assert when accessing root.u.def that the symbol
is the correct type.
(elf64_hppa_finalize_opd, elf64_hppa_finalize_dlt),
(elf64_hppa_finalize_dynreloc): Similarly assert here.
(elf64_hppa_finalize_dlt): Move duplicate code involving
text_hash_entry and data_hash_entry out of conditionals.
(elf64_hppa_finalize_dynreloc, elf_hppa_dlt_dynrel_reloc),
(elf_hppa_final_link_relocate): Likewise.
A previous commit added new backend hook sframe_support_flex_fde_p by
defining a new function for each backend that supports SFrame stack
trace format:
As pointed out in a review comment, simply providing the definition to
use true/false (as applicable) is sufficient for the purpose, and helps
generate better code. So do that.
https://inbox.sourceware.org/binutils/80404871-53b4-4f5c-9d86-7a3a4d0a920e@suse.com/
GNU doesn't generally use the "<...>" convention, but instead uses
upper case for "metasyntactic variables". See the GNU coding
standards for this topic.
In this particular spot, though, I think the old form using quotes is
preferable. This patch reverts this change.
Commit a1c2fa92ac93bf50227941bd82094e6997c5fd56 broke the ld
testcase for .note.GNU-stack wanting to be SHT_NOTE. Fix this
by falling back to .text if .dynamic isn't available to define
the text segment base.
2026-01-21 John David Anglin <danglin@gcc.gnu.org>
bfd/ChangeLog:
* elf64-hppa.c (elf64_hppa_late_size_sections): Fallback
to .text if .dynamic section isn't found.
Tom de Vries [Wed, 21 Jan 2026 15:43:07 +0000 (16:43 +0100)]
[gdb] Ignore .sframe section in dtrace_static_probe_ops::get_probes
On aarch64-linux (Debian testing), with test-case gdb.base/fission-macro.exp I
run into:
...
(gdb) set complaints 5^M
(gdb) file fission-macro-v4-b32-s0^M
Reading symbols from fission-macro-v4-b32-s0...^M
During symbol reading: \
skipping section '.sframe' which does not contain valid DOF data.^M
(gdb) FAIL: $exp: lang=c: dwarf_version=4: dwarf_bits=32: strict_dwarf=0: \
No complaints
...
The problem is that there's an overlap between:
...
./include/elf/common.h:#define SHT_SUNW_dof 0x6ffffff4
...
and:
...
./include/elf/common.h:#define SHT_GNU_SFRAME 0x6ffffff4
...
So when dtrace_static_probe_ops::get_probes tries reading an SHT_SUNW_dof
section, it fails to read the corresponding magic number and bails with this
complaint:
...
During symbol reading: \
skipping section '.sframe' which does not contain valid DOF data.^M
...
But the section actually being read is not an SHT_SUNW_dof section, but an
SHT_GNU_SFRAME section:
...
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[17] .sframe GNU_SFRAME 00000000000008f0 0008f0 000035 00 A 0 0 8
...
Fix this by checking for the section name .sframe in
dtrace_static_probe_ops::get_probes.
Tested on aarch64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33813
Michal Sobon [Wed, 21 Jan 2026 13:45:05 +0000 (14:45 +0100)]
opcodes: Fix BMASKI disassembly for immediate 32 on M*Core
The BMASKI instruction has three encoding variants (OMa, OMb, OMc).
The OMa encoding (0x2C00, mask 0xFFF0) specifically represents
BMASKI with immediate 32, encoded as IMM5=0.
Per Motorola M*Core specification: "An IMM5 value of 0 is interpreted
as a value of 32."
Previously, all three variants extracted the immediate the same way,
causing OMa to incorrectly display 0 instead of 32.
opcodes/
* mcore-dis.c (print_insn_mcore): Handle OMa encoding to display
immediate 32 instead of 0 for BMASKI.
gas/testsuite/
* gas/mcore/allinsn.s: Add test for bmaski with immediate 32.
Replace two clrc padding instructions with one for 4-byte alignment.
Fix missing newline at end of file.
* gas/mcore/allinsn.d: Update expected output.
Evgeny Karpov [Wed, 21 Jan 2026 13:44:44 +0000 (14:44 +0100)]
aarch64: Add bigobj support to AArch64 COFF
During Boost library testing on aarch64-w64-mingw32, it appeared that 2^16
sections are not enough. It can be handled by using the bigobj format to extend
the total amount of sections to 2^32. This patch adds bigobj support to
AArch64 COFF in a similar way to how it is done for x86_64.
Co-authored-by: Martin Vejbora <mvejbora@microsoft.com> Signed-off-by: Evgeny Karpov <evgeny@kmaps.co>
Jan Beulich [Wed, 21 Jan 2026 13:43:54 +0000 (14:43 +0100)]
ld: testcase for .note.GNU-stack wanting to be SHT_NOTE
If --noexecstack is removed and instead of empty.s a source file is used
which explicitly creates a @progbits .note.GNU-stack, the test fails (for
the absence of a NOTE segment).
Jan Beulich [Wed, 21 Jan 2026 13:42:39 +0000 (14:42 +0100)]
readelf: don't (silently) fail on empty SHT_NOTE sections
Them containing no entries is not an error. Such sections simply have
nothing to dump. (Exiting with non-zero status but no error message isn't
quite appropriate anyway.)
Matthieu Longo [Thu, 4 Dec 2025 15:50:30 +0000 (15:50 +0000)]
aarch64: silence GCS warnings on shared libraries for -z gcs=implicit
Dynamic library incompatibilities should not be reported when no GCS
option is provided (defaults to '-z gcs=implicit') and no explicit
diagnostic is provided via '-z gcs-report-dynamic'.
Binary Linux distributions do not rebuild all packages from scratch
when rolling out a new feature or creating a new release; only
modified packages get rebuilt. In the context of GCS deployment, this
meant that some packages were rebuilt with GCS enabled while their
dependencies were not yet GCS-compatible, resulting in warnings. These
warnings caused build failures for packages that treat linker warnings
as errors. Those errors slowed down the GCS deployment, and Linux
distribution maintainers requested that no GCS option provided should
be equivalent to '-z gcs=implicit -z gcs-report-dynamic=none'.
In contrast, '-z gcs=always' should continue to report such issues by
default. Warnings can still be disabled or promoted to errors by
explicitly setting '-z gcs-report-dynamic' to respectively 'none' or
'error'.
This patch preserves the existing behaviour for '-z gcs=never', changes
the default behaviour of '-z gcs=implicit' or no GCS option, and removed
the inheritance mechanism between '-z gcs-report' and '-z gcs-report-dynamics'.
The expected behaviour with the different possible combinations is as
follows:
* -z gcs=never:
No diagnostic messages are emitted.
* -z gcs=implicit:
No diagnostic messages are emitted for input static objects.
However, if all the input static objects are marked for GCS, the
output object will also be marked for GCS.
In this case the output is marked with GCS, '-z gcs-report-dynamic'
defaults to 'none' and no diagnostics are emitted. Diagnostics can
be enabled by explicitly providing the option.
* -z gcs=always:
Warning diagnostics for both static and dynamic input objects are
enabled by default. The two options are independent of one another,
and the diagnostic level can be adjusted for each by explicitly
providing the desired level to '-z gcs-report-dynamic' and '-z
gcs-report'.
The patch also updates the existing tests, removes redundant test cases,
and adds new tests covering cases with no report option provided, or
report options explicitly set.
The SFrame test for PR ld/33401 is a two-step link test where the
second link depends on the output of the first. In the first step, the
linker process generates R_*_NONE relocs for .sframe section, while
the second link process should pass without any issue.
This patch reworks the PR ld/33401 test by removing the call to
run_cc_link_tests, and use individual command invocation for
compilation, assembling and linking. It introduces the UNRESOLVED
status if the first step contains a linking or assembling error. The
UNTESTED status is emitted if the first stage doesn't produce R_*_NONE
relocs in .sframe section to test the original issue.
ld/
PR ld/33784
* testsuite/ld-sframe/sframe.exp (check_pr33401): Rework the
procedure for UNRESOLVED and UNTESTED cases.
(check_dump): New procedure.
* testsuite/ld-sframe/pr33401.rd: Add extra line at the end of the
file.
As a result of the mail exchange in
https://sourceware.org/pipermail/binutils/2026-January/147439.html,
the run_cc_link_test procedure may want to link standard libs
too. However, this is not required for running PR 32789 tests. Add
-nostdlib option.
ld/
* testsuite/ld-sframe/sframe.exp: Add nostdlib when testing PR
32789.
Alan Modra [Mon, 19 Jan 2026 22:13:25 +0000 (08:43 +1030)]
libsframe misaligned uint32_t
I saw asan complaints about misaligned loads and stores when taking a
quick look at pr33810 before Jens' patch was applied. They have
disappeared now, but it looks to me like a FRE can start on any
address boundary and there is no padding or suchlike to align the
FRE fields.
* sframe.c (flip_fre_stack_offsets): Let the compiler know
that integers may be misaligned.
Simon Marchi [Sat, 17 Jan 2026 06:02:35 +0000 (01:02 -0500)]
gdb/dwarf: add unit_lists structure to index writer
I think it makes the code more readable than the pair of vector. Also,
I'm considering adding a third list (foreigh type units), which will be
easier with the structure.
Change-Id: I38ec4ddf8f786a2ba10c5b371cfe04c2baaa7da9 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 17 Jan 2026 06:02:32 +0000 (01:02 -0500)]
gdb/dwarf: move DWP htab nullptr check to lookup_dwo_unit_in_dwp
cutu_reader::lookup_dwo_cutu gets hold of the right htab for the kind of
unit to look up (CU or TU), but then just uses the pointer to know if it
should call lookup_dwo_unit_in_dwp or not. lookup_dwo_unit_in_dwp then
uses the same condition to obtain the correct htab. I think it would
make more sense to return early from lookup_dwo_unit_in_dwp instead, if
the required htab does not exist.
Change-Id: I6f8f96aba2452f8261b3c60667e72fb21b97c89d Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Tue, 20 Jan 2026 15:08:38 +0000 (15:08 +0000)]
gdb: fail for 'maint print frame-id LEVEL' of an invalid frame
I noticed that 'maint print frame-id LEVEL' will always print a
frame-id, just not always for LEVEL, for example:
(gdb) bt
#0 woof () at stack.c:4
#1 0x000000000040111f in bar () at stack.c:10
#2 0x000000000040112f in foo () at stack.c:16
#3 0x000000000040113f in main () at stack.c:22
(gdb) maintenance print frame-id 4
frame-id for frame #3: {stack=0x7fffffffa640,code=0x0000000000401131,!special}
(gdb)
Notice that the request was for the frame-id of #4, which doesn't
exist, but what I got was the frame-id for #3.
Fix this by adding a check to maintenance_print_frame_id (frame.c), so
the new behaviour is:
(gdb) maintenance print frame-id 4
No frame at level 4.
(gdb)
This matches the behaviour of the 'frame' command:
(gdb) frame 4
No frame at level 4.
(gdb)
I've added a new test to cover this case.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
hppa64: Improve relocation handling for local symbols and add gc_section support
With this patch, gcc-16 can be built and there are significant
improvements in test results. I spent a lot of time trying to
fix the EH exception support. While there are still issues with
handling relocations in linkonce sessions, exception handling
mostly works if pc-relative and text relative encoding is used
in .eh_frame. The main problems are the HP-UX dynamic linker
relocates the text and data segements indpendently, and it does
not support unaligned dynamic relocations.
Due to a configure bug in libstdc++-v3, the lack of gc_section
support caused many test failures, so I added the gc_section
support form elf32-hppa.c.
I also move the HP_LOAD_MAP scratchpad to the end of the .bss
section and fixed a number of issues with the linker scripts.
2026-01-20 John David Anglin <danglin@gcc.gnu.org>
bfd/ChangeLog:
* elf64-hppa.c (elf64_hppa_check_relocs): Drop NEED_PLT
from R_PARISC_LTOFF_FPTR relocations. Revise R_PARISC_FPTR64
relocation to use maybe_dynamic. Add support for
R_PARISC_GNU_VTINHERIT and R_PARISC_GNU_VTENTRY relocations.
Add code to handle dynamic relocations of local symbols.
(elf64_hppa_gc_mark_hook): New.
(ensure_undef_dynamic): New.
(allocate_dynrel_entries): Revise checks to determine when
to discard relocs.
(elf64_hppa_late_size_sections): Revise allocation of local
PLT, DLT and OPD entries.
(elf64_hppa_finalize_opd): Remove assert.
(elf64_hppa_finalize_dlt): Change type of dynindx to long.
(elf64_hppa_finalize_dynreloc): Likewise. Add check for
discarded sections. Correct handling of R_PARISC_FPTR64
relocation. Remove assert. Add new assert to check that
we don't allocate more relocs in .rela.data than it can
hold.
(elf64_hppa_finish_dynamic_sections): Move allocation for
DT_HP_LOAD_MAP to end of .bss section. Only allocate on
HP-UX.
(elf_hppa_dlt_dynrel_reloc): Add dynrel_type argument.
Change type of dynindx. Drop use of value. Remove assert.
(elf_hppa_opd_dynrel_relocs): Rename to elf_hppa_opd_eplt_reloc.
Drop code to to emit R_PARISC_FPTR64 relocation.
(elf_hppa_opd_fptr_reloc): New.
(elf_hppa_final_link_relocate): Add SYM arguement. Move
check for SEC_DEBUGGING. Rework DLT, LTOFF, FPTR and DIR64
relocation handling.
(elf64_hppa_relocate_section): Add asserts to ensure symbol
isn't undefined and input_section hasn't been discarded.
(elf_backend_gc_mark_hook): Define.
(elf_backend_can_gc_sections): Define.
ld/ChangeLog:
* emulparams/elf64hppa.sh (DATA_ADDR): Revise value to match
HP-UX 11 value.
(SHLIB_DATA_ADDR): Likewise.
(NOP): Define.
(OTHER_READONLY_SECTIONS): Add .data.rel, .HP.init, .preinit,
.init and .fini sections to list.
(__SYSTEM_ID_D, __TLS_SIZE_D, __FPU_REVISION, __FPU_MODEL,
__CPU_REVISION, __CPU_KEYBITS_1, __LOAD_INFO, __ARGC, __ARGV,
__ENVP, __libdl_jmp_tbl, __systab): Provide.
(DATA_START_SYMBOLS, OTHER_SYMBOLS, INIT_START): Delete.
(PREINIT_START, PREINIT_END, INIT_START): Define.
emulparams/hppa64linux.sh (NOP): Define.
(DATA_START_SYMBOLS): Delete.
scripttempl/elf64hppa.sc: Delete .init and .fini sections
from script. Allocate 16 bytes at end of .bss for HP_LOAD_MAP.
Tom Tromey [Thu, 8 Jan 2026 15:03:33 +0000 (08:03 -0700)]
Move puts_tabular to obj-lang.c
Only objc-lang.c uses puts_tabular. This patch moves the function
there and makes it 'static'. It is also updated not to depend on the
global (but private to utils.c) chars_printed, and not to call
begin_line.
Tom Tromey [Fri, 16 Jan 2026 18:27:46 +0000 (11:27 -0700)]
Remove all globals from coffread.c
This patch changes coffread.c to add a reader object type. All
globals are moved into this type, and the majority of functions in
coffread.c are changed to be methods.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Fri, 16 Jan 2026 18:18:20 +0000 (11:18 -0700)]
Use coffread_objfile throughout coffread.c
coffread.c:coff_symtab_read sets a global objfile while working. It
seemed nicer to me to hoist this so that it is set by the main entry
point, and then used throughout the file.
Normally I wouldn't encourage the use of globals, but shortly we'll be
replacing these with an object.
Note that while coff_symtab_read cleared coffread_objfile when it was
finished, I haven't preserved this in the new patch. First, this
should have been done with a scoped_restore. Second, this is the only
global to get this treatment. Third, it's not necessary at all. And,
finally, this will be moot anyway when the globals are removed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Fri, 16 Jan 2026 18:08:58 +0000 (11:08 -0700)]
Remove redundant nlist_bfd_global
coffread.c has two BFD globals: nlist_bfd_global and symfile_bfd.
There's no need for both, and since symfile_bfd is set early (in
coff_symfile_read, the entry point), this removes nlist_bfd_global and
replaces all the uses.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
BFD: Remove extraneous BFD struct member setup from `bfd_make_readable'
Complementing commit 3097045a18a8 ("ld plugin bfd_make_readable leak")
remove assignments to BFD struct members from `bfd_make_readable' that
now duplicate ones unconditionally made by `_bfd_free_cached_info'
called earlier on.
BFD: Remove null pointer checks for `bfd_hash_table_free' calls
Given that as from commit 90e5645309be ("libiberty: Make `objalloc_free'
`free'-like WRT null pointer") `bfd_hash_table_free' now returns with no
action taken when called for a hash table with no allocation present,
remove null pointer checks guarding invocations.
Jens Remus [Tue, 20 Jan 2026 09:33:56 +0000 (10:33 +0100)]
s390: gas: Remove support for register names "ap" and "cc" in CFI directives
The assembler erroneously converted the special register names "ap" and
"cc" to the DWARF register numbers 32 and 33 respectively, which are
actually assigned to the control registers c0 and c1 according to both
the s390 32-bit (s390) ELF ABI [1] and s390 64-bit (s390x) ELF ABI [2].
Register numbers 32 and 33 are used internally by GCC as "argument
pointer" (ap) and "condition code" (cc). Very early GCC versions leaked
this out into DWARF. However, those GCC-internal special register names
should never be actually used in CFI, especially given their resulting
DWARF register numbers have a different meaning in DWARF (CFI).
Jens Remus [Tue, 20 Jan 2026 09:33:56 +0000 (10:33 +0100)]
s390: gas: Support access register names in CFI directives
Convert access register (AR) names a0-a15 to DWARF register numbers when
used in CFI directives. Convert an access register number (0..15) to
its corresponding DWARF register number (48..63) as specified in the
s390 64-bit (s390x) ELF ABI [1] by adding 48.
gas/testsuite/
* gas/s390/cfi-regnames.d: Add test for AR names in in CFI
directives.
* gas/s390/cfi-regnames.s: Likewise.
* gas/s390/cfi-regnames-err.l: Likewise.
* gas/s390/cfi-regnames-err.s: Likewise.
Jens Remus [Tue, 20 Jan 2026 09:33:56 +0000 (10:33 +0100)]
s390: gas: Support vector register names in CFI directives
Convert vector register names v0-v31 to DWARF register numbers when used
in CFI directives. Convert a vector register number (0..31) to its
respective DWARF register number (16..31, 68..83) as specified in the
s390 64-bit (s390x) ELF ABI [1] as follows:
Right rotate the least significant three bits and add 16 for register
numbers 0..15 or 68 for register numbers 16..31.
Add a test case for the use of vector register (VR) names in CFI
directives.
Jens Remus [Tue, 20 Jan 2026 09:33:55 +0000 (10:33 +0100)]
s390: gas: Fix conversion of FP register names to DWARF register numbers
The assembler supports register names in CFI directives. For floating-
point (FP) registers f0..f15 the register numbers 0..15 are erroneously
converted to DWARF register numbers 16..31 by adding 16. This is wrong
as the s390 64-bit (s390x) ELF ABI [1] specifies the DWARF register
numbers for the FP registers as follows:
Convert a FP register number (0..15) to its respective DWARF register
number (16..31) as follows:
Right rotate the least significant three bits and add 16.
Add a test case for the use of general register (GR; r0..r15) and
floating-point register (FPR; f0..f15) names in CFI directives.
gas/
* config/tc-s390.c (tc_s390_regname_to_dw2regnum): Fix
conversion of FP register names to DWARF register numbers.
gas/testsuite/
* gas/s390/s390.exp (cfi-regnames, cfi-regnames-err): Run new
tests.
* gas/s390/cfi-regnames.d: New test for GR and FPR names in CFI
directives.
* gas/s390/cfi-regnames.s: Likewise.
* gas/s390/cfi-regnames-err.l: Likewise.
* gas/s390/cfi-regnames-err.s: Likewise.
Jens Remus [Tue, 20 Jan 2026 09:22:52 +0000 (10:22 +0100)]
libsframe: use proper FRE type when flipping SFrame V3 FREs
flip_sframe_fdes_with_fres_v3 was erroneously using a fixed FRE type
of 0 (= SFRAME_FRE_TYPE_ADDR1) when endianness byte-flipping the FREs,
regardless of the actual FRE type (i.e. ADDR1, ADDR2, or ADDR4). This
only affected cross builds, where the .sframe section data may needed
to be endianness byte-flipped (e.g. binutils cross-built for s390
64-bit (s390x) on x86-64).
As a consequence objdump/readelf with option --sframe could fail to dump
e.g. s390 64-bit (s390x) .sframe section data on x86-64 with the
following error message:
Error: SFrame decode failure: Buffer does not contain SFrame data.
The linker ld-sframe test "PR ld/33401 (Step 1: Create relocatable
object and check R_*_NONE)" cross-build for s390 64-bit (s390x) on
x86-64 could fail with ld error message:
error in tmpdir/StatePlaying.o(.sframe); no .sframe will be created
The linker ld-sframe test "PR ld/33401 (Step 1: Create relocatable
object and check R_*_NONE)" cros-build for s390 64-bit (s390x) on
x86-64 could fail with BDF assertion:
Add a common cfi-sframe assembler test, that forces a FDE type of
SFRAME_FRE_TYPE_ADDR2. When the test is run cross-build it may
exercise the SFrame FDE and FDE endianness byte flipping.
libsframe/
PR ld/33810
* sframe.c (sframe_decode_fde_attr_v3): Decode and return FRE
type from FDE attributes.
(flip_sframe_fdes_with_fres_v3): Use proper FRE type from
FDE attributes when flipping FREs.
gas/testsuite/
PR ld/33810
* gas/cfi-sframe/cfi-sframe.exp (cfi-sframe-common-pr33810): Run
new test.
* gas/cfi-sframe/cfi-sframe-common-pr33810.d: New test.
* gas/cfi-sframe/cfi-sframe-common-pr33810.s: Likewise.
Bug: https://sourceware.org/pr33810 Fixes: 8ab6e4c72ab6 ("[SFrame-V3] include: gas: libsframe: split FDE into idx and attr") Reported-by: Alan Modra <amodra@gmail.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Tom de Vries [Tue, 20 Jan 2026 08:06:20 +0000 (09:06 +0100)]
[gdb] Add regression test for PR symtab/33777
PR symtab/33777 reports a problem where toplevel DIEs of partial units are
read many times.
The problem manifest as a timeout when building gdb with -O0 and Asan, and
running test-case gdb.base/tls-dlobj.exp with glibc debuginfo installed.
Reproduce the problem in a simpler and quicker way, without relying on glibc
debuginfo:
- build an executable with 100 partial units
- run info line "$file:$line" a 100 times
- add a line to "maint print statistics" that tells us how many time a
toplevel DIE is read.
Without the fix we have:
...
Number of read units: 1
Number of unread units: 108
Number of read top-level DIEs: 10118
...
and with the fix we have:
...
Number of read units: 1
Number of unread units: 108
Number of read top-level DIEs: 218
...
Detect the problem by asserting:
...
gdb_assert { $top_level_die <= 3 * ( $read_cu + $unread_cu ) }
...
The factor 3 is used because for some target boards $top_level_die is slightly
more than 2 * ( $read_cu + $unread_cu ).
Tom Tromey [Sun, 18 Jan 2026 17:42:34 +0000 (10:42 -0700)]
Remove "alias" hack from add_symbol_to_list
add_symbol_to_list has this code:
/* If this is an alias for another symbol, don't add it. */
if (symbol->linkage_name () && symbol->linkage_name ()[0] == '#')
return;
This appears to be an old stabs hack. In the stabs removal patch
(commit eaea19f98d8) we see:
- /* '#' is a GNU C extension to allow one symbol to refer to another
- related symbol.
-
- Generally this is used so that an alias can refer to its main
- symbol. */
This is a classic example of an old style problem that gdb had:
sometimes hacks were added to the gdb core to work around problems in
symbol readers -- IMO this kind of thing should have always been
handled by the stabs reader itself, not add_symbol_to_list.
Anyway, this is obsolete now and this patch removes it.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Mon, 19 Jan 2026 18:14:11 +0000 (19:14 +0100)]
[gdb/symtab] Handle zero opcode_base in line number program header
I build gdb with TSAN, and with test-case gdb.dwarf2/malformed-line-header.exp
ran into a heap-use-after-free:
...
(gdb) info line 1
==================
WARNING: ThreadSanitizer: heap-use-after-free (pid=897504)
Write of size 1 at 0x72040000d000 by main thread:
#0 dwarf_decode_line_header() gdb/dwarf2/line-header.c:356 (gdb+0xa0618c)
...
Location is heap block of size 0 at 0x72040000d000 allocated by main thread:
#0 operator new[](unsigned long) <null> (libtsan.so.2+0xa6b01)
#1 dwarf_decode_line_header() gdb/dwarf2/line-header.c:354 (gdb+0xa06159)
...
This is caused by allocating a zero-sized array (lh->opcode_base == 0), and
writing to it:
...
lh->standard_opcode_lengths.reset (new unsigned char[lh->opcode_base]);
lh->standard_opcode_lengths[0] = 1; /* This should never be used anyway. */
...
Fix this by skipping this code if lh->opcode_base == 0.
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Jan Beulich [Mon, 19 Jan 2026 09:42:25 +0000 (10:42 +0100)]
PPC: permit %dm0 as insn operand
When the DM registers were added, sorting of the table was broken. With
the present arrangement, this leads to (only) %dm0 not being found by the
binary search that both use sites of the table entertain.
Jan Vrany [Mon, 19 Jan 2026 08:58:41 +0000 (08:58 +0000)]
gdb/testsuite: fix FAILs in fileio.exp
I'm experiencing intermittent FAILs in fileio.exp when running on (my)
CI:
FAIL: gdb.base/fileio.exp: Open a file
FAIL: gdb.base/fileio.exp: Creating already existing file returns EEXIST
FAIL: gdb.base/fileio.exp: Open for write but no write permission returns EACCES
FAIL: gdb.base/fileio.exp: Writing to a file
...
The problem turned out to be the way the OUTDIR gets defined in fileio.c.
The path is passed down "naked" and turned into string by STRINGIFY macro.
However, if the path happens to contain name of unrelated pre-existing
C macro, this macro gets expanded during the "stringification", resulting
in (likely) different path than used in fileio.exp and therefore causing
failures.
For example, if the GDB is compiled and tested in directory
This commit fixes this by defining the OUTDIR as string literal in first
place (similarly to how it was done prior commit cc91060) and updating
quote_for_host to handle strings that themselves contains quote (").
Tested on x86_64-linux by running all tests using quote_for_host with
both target board unix and host/target board local-remote-host-native.
Alan Modra [Mon, 19 Jan 2026 04:15:26 +0000 (14:45 +1030)]
asan: coff-alpha use of uninitialised value
I think this is a false positive as the "use" is reported at a
_bfd_link_reloc_status_error call, and the value passed is not used
except when bfd_reloc_dangerous. Avoid the warning anyway.
Tom Tromey [Sun, 18 Jan 2026 02:28:13 +0000 (19:28 -0700)]
Fix multiple-successive-infcall.exp with gdbserver
PR gdb/33791 points out that my recent change to emit the thread ID in
the thread notification message broke multiple-successive-infcall.exp
when run with gdbserver. This patch fixes the oversight.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33791 Approved-By: Simon Marchi <simon.marchi@efficios.com>
Eli Zaretskii [Sun, 18 Jan 2026 09:30:06 +0000 (11:30 +0200)]
gdb/
PR gdb/33761
* gdb/ui-style.c (colorsupport) [__MINGW32__]: MS-Windows always
supports at least 8 colors, even if the "Co" capability is not in
the terminfo DB. This fixes "set style FOO foreground COLOR"
commands in the Windows native build of GDB.
Alan Modra [Sat, 17 Jan 2026 08:13:06 +0000 (18:43 +1030)]
PR 33801 strip doesn't remove .gnu.lto_.opts
OK, so people want to be able to partly destroy gcc slim LTO object
files. I don't see why not, despite HJ's policy-setting slim lto
strip -R tests. I also don't see why it matters that objcopy/strip
won't similarly break LLVM objects (pr33271).
So out goes the slim lto strip -R tests, and the strip-debug test
expecting slim lto files won't be modified in any way. strip-debug
now removes a FILE symbol, which isn't unreasonable.
PR 33801
PR 33271
PR 33246
binutils/
* objcopy.c (copy_archive, copy_file): Do not special case
gcc LTO IR files.
ld/
* testsuite/ld-plugin/lto-binutils.exp: Remove slim lto strip -R
tests.
(run_pr33246_test): Don't compare slim object files after
strip-debug.
* testsuite/ld-plugin/strip-1a-s-all.nd: Delete.
H.J. Lu [Sat, 17 Jan 2026 00:48:59 +0000 (08:48 +0800)]
gas: Update PR gas/33744 tests
Since .set directive doesn't work on alpha and hpux has a non-standard
common directive, skip the relevant tests on alpha and hpux. Also allow
2, 4, 8 byte section alignment for 1-byte section since some targets
have a minimum section alignment.
Simon Marchi [Sat, 17 Jan 2026 03:44:56 +0000 (22:44 -0500)]
gdb/i386: remove i386_dbx_reg_to_regnum
Following the removal of gdbarch_sdb_reg_to_regnum,
i386_dbx_reg_to_regnum is only used by i386_svr4_dwarf_reg_to_regnum to
handle SSE and MMX registers. Remove it and inline the relevant bits in
i386_svr4_dwarf_reg_to_regnum.
Change-Id: Id74fad6ef6798c4cd061905f1c01eadd90e0a118 Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom de Vries [Sat, 17 Jan 2026 07:44:57 +0000 (08:44 +0100)]
[gdb/tdep] Fix gdb.base/siginfo.exp on s390x-linux
On s390x-linux (SLES 15 SP5), I'm running into:
...
FAIL: gdb.base/siginfo.exp: backtrace for nexti (pattern 2)
FAIL: gdb.base/siginfo.exp: step out of handler
...
The first FAIL is caused by a failure to unwind:
...
(gdb) bt^M
#0 handler (sig=26, info=0x3ffffffe428, context=0x3ffffffe4a8) at \
gdb.base/siginfo.c:31^M
Backtrace stopped: Cannot access memory at address 0x1a00000088^M
(gdb)
...
In contrast, on x86_64-linux I get instead:
...
(gdb) bt^M
#0 handler (sig=26, info=0x7fffffffc170, context=0x7fffffffc040) at \
gdb.base/siginfo.c:31^M
#1 <signal handler called>^M
#2 0x0000000000401201 in main () at gdb.base/siginfo.c:67^M
(gdb)
...
The memory access error is triggered here in s390_sigtramp_frame_unwind_cache:
...
/* Restore the previous frame's SP. */
prev_sp = read_memory_unsigned_integer (
info->saved_regs[S390_SP_REGNUM].addr (),
word_size, byte_order);
...
while trying to read an "Old-style RT frame" (for syscall sigreturn).
The problem is that we actually have a "New-style RT frame" (for syscall
rt_sigreturn).
[ See linux kernel source file arch/s390/kernel/signal.c for a detailed
explanation of the two. ]
The choice between the two is made earlier in that same function:
...
/* New-style RT frame:
retcode + alignment (8 bytes)
siginfo (128 bytes)
ucontext (contains sigregs at offset 5 words). */
if (next_ra == next_cfa)
{
...
}
/* Old-style RT frame and all non-RT frames:
old signal mask (8 bytes)
pointer to sigregs. */
else
...
I'm not sure why the check gives the wrong result, but I noticed that
s390_sigtramp_frame_sniffer is able to distinguish between the two, so fix
this by:
- factoring out new function s390_sigtramp_p out of
s390_sigtramp_frame_sniffer, and
- using s390_sigtramp_p in s390_sigtramp_frame_unwind_cache to distinguish
between the "Old-style RT frame" and "New-style RT frame".
This fixes the backtrace.
The second failure is:
...
(gdb) step^M
32 } /* handler */^M
1: x/i $pc^M
=> 0x1000772 <handler+50>: nopr^M
(gdb) step^M
0x000003fffdffe490 in __kernel_rt_sigreturn ()^M
1: x/i $pc^M
=> 0x3fffdffe490 <__kernel_rt_sigreturn>: svc 173^M
(gdb) FAIL: gdb.base/siginfo.exp: step out of handler
...
There is some code in process_event_stop_test that is supposed to trigger:
...
if (ecs->event_thread->control.step_range_end != 1
&& (ecs->event_thread->control.step_over_calls == STEP_OVER_UNDEBUGGABLE
|| ecs->event_thread->control.step_over_calls == STEP_OVER_ALL)
&& get_frame_type (frame) == SIGTRAMP_FRAME)
{
infrun_debug_printf ("stepped into signal trampoline");
/* The inferior, while doing a "step" or "next", has ended up in
a signal trampoline (either by a signal being delivered or by
the signal handler returning). Just single-step until the
inferior leaves the trampoline (either by calling the handler
or returning). */
keep_going (ecs);
return;
}
...
but it doesn't because frame is a NORMAL_FRAME instead of a SIGTRAMP_FRAME.
This is caused by the "dwarf2" unwinder triggering, which has higher priority
than the "s390 linux sigtramp" unwinder:
...
(gdb) maint info frame-unwinders
Name Type Class Enabled
dummy DUMMY_FRAME GDB Y
dwarf2 tailcall TAILCALL_FRAME DEBUGINFO Y
inline INLINE_FRAME GDB Y
jit NORMAL_FRAME EXTENSION Y
python NORMAL_FRAME EXTENSION Y
dwarf2 NORMAL_FRAME DEBUGINFO Y
dwarf2 signal SIGTRAMP_FRAME DEBUGINFO Y
s390 linux sigtramp SIGTRAMP_FRAME ARCH Y
s390 stub NORMAL_FRAME ARCH Y
s390 prologue NORMAL_FRAME ARCH Y
...
I found some code in dwarf2_frame_sniffer:
...
/* On some targets, signal trampolines may have unwind information.
We need to recognize them so that we set the frame type
correctly. */
if (fde->cie->signal_frame
|| dwarf2_frame_signal_frame_p (get_frame_arch (this_frame),
this_frame))
return self->type () == SIGTRAMP_FRAME;
...
and an example implementation i386_linux_dwarf_signal_frame_p, and after
copying this approach, indeed the stepping failure was fixed, but the
backtrace broken again.
Instead, fix this by giving the "s390 linux sigtramp" unwinder a higher
priority:
...
(gdb) maint info frame-unwinders
Name Type Class Enabled
dummy DUMMY_FRAME GDB Y
dwarf2 tailcall TAILCALL_FRAME DEBUGINFO Y
inline INLINE_FRAME GDB Y
jit NORMAL_FRAME EXTENSION Y
python NORMAL_FRAME EXTENSION Y
s390 linux sigtramp SIGTRAMP_FRAME ARCH Y
dwarf2 NORMAL_FRAME DEBUGINFO Y
dwarf2 signal SIGTRAMP_FRAME DEBUGINFO Y
s390 stub NORMAL_FRAME ARCH Y
s390 prologue NORMAL_FRAME ARCH Y
...
Also fixes test-case gdb.base/sigaltstack.exp and gdb.base/sigbpt.exp.
Tested on s390x-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
PR tdep/33708
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33708
Alan Modra [Fri, 16 Jan 2026 05:49:31 +0000 (16:19 +1030)]
ld: put wild matching_sections on an obstack
so that the memory can be reclaimed easily when reset_resolved_wilds
throws it all away.
* ldlang.c (matching_obstack): New static var.
(add_matching_section): Rewrite to use matching_obstack.
(lang_init): Init matching_obstack.
(reset_resolved_wilds): Free matching_obstack.
Alan Modra [Fri, 16 Jan 2026 05:43:21 +0000 (16:13 +1030)]
Make some ldlang functions inline
These are small, and making them inline lets me call
lang_statement_append without adding a forward declaration in the
next patch.
* ldlang.c (lang_for_each_statement, lang_list_init),
(lang_statement_append): Move to..
* ldlang.h: ..here making them inline functions.
(bfd_input_just_syms): Group with other inlines.
Simon Marchi [Fri, 16 Jan 2026 18:35:57 +0000 (13:35 -0500)]
gdb/windows: replace bfd_map_over_sections with gdb_bfd_sections
Replace bfd_map_over_sections with iteration over gdb_bfd_sections.
Change core_process_module_section's signature to take a cpms_data
reference instead of a void pointer.
Change-Id: Ic4f9a12c9c1479799ec87658fd88490106b61836 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Fri, 16 Jan 2026 18:35:56 +0000 (13:35 -0500)]
gdb/compile: replace bfd_map_over_sections with gdb_bfd_sections
Replace bfd_map_over_sections with iteration over gdb_bfd_sections.
Rename copy_sections to copy_section and change its signature to take
explicit parameters instead of the callback-style void pointer.
Change-Id: I30f1c3c051415722f2220b7fba48103101b640e8 Approved-By: Tom Tromey <tom@tromey.com>
projects / thirdparty / binutils-gdb.git / log
