WANG Xuerui [Sun, 6 Jul 2025 01:06:20 +0000 (09:06 +0800)]
LoongArch: Allow to relax instructions into NOPs after handling alignment
Right now, LoongArch linker relaxation is 2-pass, since after alignment
is done, byte deletion can no longer happen. However, as the alignment
pass also shrinks text sections, new relaxation chances may well be
created after alignment is done. Although at this point we can no longer
delete unused instructions without disturbing alignment, we can still
replace them with NOPs; popular LoongArch micro-architectures can
eliminate NOPs during execution, so we can expect a (very) slight
performance improvement from those late-created relaxation chances.
To achieve this, the number of relax passes is raised to 3 for
LoongArch, and every relaxation handler except loongarch_relax_align is
migrated to a new helper loongarch_relax_delete_or_nop, that either
deletes bytes or fills the bytes to be "deleted" with NOPs, depending on
whether the containing section already has undergone alignment. Also,
since no byte can be deleted during this relax pass, in the pass the
pending_delete_ops structure is no longer allocated, and
loongarch_calc_relaxed_addr(x) degrades to the trivial "return x" in
this case.
In addition, previously when calculating distances to symbols, an
extra segment alignment must be considered, because alignment may
increase distance between sites. However in the newly added 3rd pass
code size can no longer increase for "closed" sections, so we can skip
the adjustment for them to allow for a few more relaxation chances.
A simple way to roughly measure this change's effectiveness is to check
how many pcalau12i + addi.d pairs are relaxed into pcaddi's. Taking a
Firefox 140.0.2 test build of mine as an example:
Before: 47842 pcaddi's in libxul.so
After: 48089
This is a 0.5% increase, which is kind of acceptable for a peephole
optimization like this; of which 9 are due to the "relax"ed symbol
distance treatment.
ld: bfd: sframe: Update section size also for relocatable links
For relocatable links the output .sframe section size may be wrong.
This can be observed when dumping the SFrame information from the x86-64
sframe-reloc-1 test:
When running the x86-64 test cross build on a big-endian system, such
as s390x, objdump and readelf fail to dump the SFrame information with
the following error message:
Error: SFrame decode failure: Buffer does not contain SFrame data.
This is because the following check in flip_sframe() fails, which gets
only invoked if the endianness of the SFrame data is different from the
host system one:
/* All FDEs and FREs must have been endian flipped by now. */
if ((j != ihp->sfh_num_fres) || (bytes_flipped != (buf_size - hdrsz)))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
While at it, remove the incorrect code comment. There is no
relationship between "do not update size" and the fact that the
"contents have not been relocated".
bfd/
* elf-sframe.c (_bfd_elf_write_section_sframe): Update section
size also for relocatable links.
NEWS: sframe: mention new semantics for SFrame FDE function start addr
The SFrame FDE's function start address is always emitted as follows by
GAS and ld: it is the offset of the start PC of the respective function
from the FDE field itself.
GAS and ld will emit a flag SFRAME_F_FDE_FUNC_START_PCREL set to 1
when emitting the field in this encoding.
* binutils/NEWS: Announce the change of encoding for SFrame FDE
func start addr field.
* gas/NEWS: Announce the emission of new flag
SFRAME_F_FDE_FUNC_START_PCREL.
* ld/NEWS: Likewise. Relocatable links are now fixed.
ld: bfd: sframe: fix incorrect r_offset in RELA entries
PR/32666 Incorrect .rela.sframe when using ld -r
Input SFrame sections are merged using _bfd_elf_merge_section_sframe (),
which clubs all SFrame FDEs together in one blob and all SFrame FREs in
another. This, of course, means the offset of an SFrame FDE in the output
section cannot be simply derived from the output_offset of the sections.
Fix this by providing _bfd_elf_sframe_section_offset () which returns
the new offset of the SFrame FDE in the merged SFrame section.
Unlike EH_Frame sections, which also use the _bfd_elf_section_offset (),
to update the r_offset, SFrame sections have distinct merging semantics.
In case of SFrame, the SFrame FDE will not simply sit at location
"sec->output_offset + offset of SFrame FDE in sec". Recall that information
layout in an SFrame section is as follows:
SFrame Header
SFrame FDE 1
SFrame FDE 2
...
SFrame FDEn
SFrame FREs (Frame Row Entries)
Note how the SFrame FDEs and SFrame FREs are clubber together in groups
of their own.
Next, also note how the elf_link_input_bfd () does a:
irela->r_offset += o->output_offset;
This, however, needs to be avoided for SFrame sections because the
placement of all FDEs is at the beginning of the section. So, rather than
conditionalizing this as follows:
if (o->sec_info_type != SEC_INFO_TYPE_SFRAME)
irela->r_offset += o->output_offset;
the implementation in _bfd_elf_sframe_section_offset () does a reverse
adjustment, so that the generic parts of the linking process in
elf_link_input_bfd () are not made to do SFrame specific adjustments.
Add a new enum to track the current state of the SFrame input section
during the linking process (SFRAME_SEC_DECODED, SFRAME_SEC_MERGED) for
each input SFrame section. This is then used to assert an assumption
that _bfd_elf_sframe_section_offset () is being used on an input SFrame
sections which have not been merged (via
_bfd_elf_merge_section_sframe ()) yet.
bfd/
* elf-bfd.h: New declaration.
* elf-sframe.c (_bfd_elf_sframe_section_offset): New definition.
* elf.c (_bfd_elf_section_offset): Adjust offset if SFrame
section.
ld/testsuite/
* ld-x86-64/x86-64.exp: New test.
* ld-x86-64/sframe-reloc-1.d: New test.
bfd: gas: ld: libsframe: adopt new encoding for FDE func start addr field
This patch convenes a set of changes in bfd, gas, ld, libsframe towards
moving to the new encoding for the 'sfde_func_start_address' field in
SFrame FDE.
First, gas must now mark all SFrame sections with the new flag
SFRAME_F_FDE_FUNC_START_PCREL. gas was already emitting the field
in the said encoding.
* gas/gen-sframe.c (output_sframe_internal): Emit the flag
SFRAME_F_FDE_FUNC_START_PCREL.
Similarly for ld, adopt the new semantics of sfde_func_start_address
consistently. This means:
- When merging SFrame sections, check that all input SFrame sections
have the SFRAME_F_FDE_FUNC_START_PCREL flag set. If the check
fails, ld errors out.
- When merging SFrame sections, keep even the in-memory contents of
the FDE function start address (buffer passed to libsframe
sframe_encoder_write () for writing out) encoded in the new
semantics. While it is, in theory, possible that instead of doing this
change here, we adjust the value of sfde_func_start_address at the final
write (sframe_encoder_write) time. But latter is not favorable for
maintenanance and may be generally confusing for developers.
- When creating SFrame for PLT entries, emit flag
SFRAME_F_FDE_FUNC_START_PCREL.
include/
* sframe-api.h (SFRAME_F_LD_MUSTHAVE_FLAGS): New definition.
bfd/
* elf-sframe.c (_bfd_elf_merge_section_sframe): Check for flag
combinatation SFRAME_F_LD_MUSTHAVE_FLAGS set for all input and
output SFrame sections. If not, error out. Also, adopt the new
semantics of function start address encoding.
* bfd/elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Emit flag
SFRAME_F_FDE_FUNC_START_PCREL.
Next, for dumping SFrame sections, now that we are emitting the same
encoding in GAS, non-relocatable and relocatable SFrame links, it is the
time to set relocate to TRUE in debug_displays[].
binutils/
* dwarf.c (struct dwarf_section_display): Allow sframe sections
to now be relocated.
gas/testsuite/
* gas/cfi-sframe/cfi-sframe-aarch64-pac-ab-key-1.d: Update the
test. Relocatable SFrame sections now display non-zero value
(appropriate function start address).
Now, as the SFrame sections on-disk and in-memory use the new semantics of
sfde_func_start_address encoding (i.e., function start address is the
offset from the sfde_func_start_address field to the start PC), the
calculation to make it human readable (i.e., relatable to the addresses
in .text sections) needs adjustment.
libsframe/
* sframe-dump.c (dump_sframe_func_with_fres): Adjust the
function start address for dumping.
Now that both the emission of the new encoding, and the relocation of
sections before dumping them is in place, it is time to adjust the
testcases.
Naturally, the change of semantics for 'SFrame FDE function start address'
has consequences on the implementation in libsframe. As per the new
semantics:
- Function start address in the SFrame FDE (sfde_func_start_address)
is an offset from the FDE function start address field to the start
PC of the associated function.
Note that, the libsframe library brings the SFrame section contents into
its own memory to create a sframe_decoder_ctx object via sframe_decode
(). Many internal and user-interfacing APIs then may use
sframe_decoder_ctx object to interact and fulfill the work.
In context of changing semantics for sfde_func_start_address, following
relevant examples may help understand the impact:
- sframe_find_fre () finds a the SFrame stack trace data (SFrame FRE)
given a lookup offset (offset of lookup_pc from the start of SFrame
section). Now that the sfde_func_start_address includes the
distance from the sfde_func_start_address field to the start of
SFrame section itself, the comparison checks of
sfde_func_start_address with the incoming lookup offset need
adjustment.
- Some internal functions (sframe_get_funcdesc_with_addr_internal ()
finds SFrame FDE by using binary seach comparing
sfde_func_start_address fields, etc.) need adjustments.
- sframe_encoder_write () sorts the SFrame FDEs before writing out
the SFrame data. Sorting of SFrame FDE via the internal function
sframe_sort_funcdesc() needs adjustments: the new encoding of
sfde_func_start_address means the distances are not from the same
anchor, so cannot be sorted directly.
This patch takes the approach of adding a new internal function:
- sframe_decoder_get_secrel_func_start_addr (): This function returns
the offset of the start PC of the function from the start of SFrame
section, i.e., it gives a section-relative offset.
As the sframe_decoder_get_secrel_func_start_addr () API needs the value
of the function index in the FDE list, another internal API needs
sframe_fre_check_range_p () adjustments too.
Sorting the FDEs (via sframe_sort_funcdesc ()) is done by first bringing
all offsets in sfde_func_start_address relative to start of SFrame
section, followed by sorting, and then readjusting the offsets accroding
to the new position in the FDE list.
libsframe/
* sframe.c (sframe_decoder_get_secrel_func_start_addr): New
static function.
(sframe_fre_check_range_p): Adjust the interface a bit.
(sframe_get_funcdesc_with_addr_internal): Use
sframe_decoder_get_secrel_func_start_addr () when comparing
sfde_func_start_address with user input offset.
(sframe_find_fre): Adopt the new semantics.
(sframe_sort_funcdesc): Likewise.
For the libsframe testsuite, use the new encoding for FDE func start
addr: distance between the FDE sfde_func_start_address field and the
start PC of the function itself.
Use SFRAME_F_FDE_FUNC_START_PCREL flag, though the sframe_encode ()
interface in libsframe applies no sanity checks for the encoding itself.
libsframe/testsuite/
* libsframe.find/findfre-1.c: Adjust to use the new
SFRAME_F_FDE_FUNC_START_PCREL specific encoding.
* libsframe.find/findfunc-1.c: Likewise.
* libsframe.find/plt-findfre-1.c: Likewise.
* libsframe/testsuite/libsframe.decode/DATA2: Update data file
due to usage of new SFRAME_F_FDE_FUNC_START_PCREL flag.
* libsframe/testsuite/libsframe.encode/encode-1.c: Use flag
SFRAME_F_FDE_FUNC_START_PCREL.
objdump, readelf: sframe: apply relocations before textual dump
PR libsframe/32589 - function start address is zero in SFrame section dump
Currently, readelf and objdump display the SFrame sections in ET_REL
object files with function start addresses of each function as 0. This
makes it difficult to correlate SFrame stack trace information with the
individual functions in the object file.
For objdump, use the dump_dwarf () interface to dump SFrame section.
Similarly, for readelf, use the display_debug_section () interface to
dump SFrame section. These existing interfaces (for DWARF debug
sections) already support relocating the section contents before
dumping, so lets use them for SFrame sections as well.
When adding a new entry for SFrame in debug_option_table[], use char
'nil' and the option name of "sframe-internal-only". This is done so
that there is no additional (unnecessary) user-exposed ways of dumping
SFrame sections. Additionally, we explicitly disallow the
"sframe-internal-only" from external/user input in --dwarf (objdump).
Similarly, "sframe-internal-only" is explicitly matched and disallowed
from --debug-dump (readelf).
For objdump and readelf, we continue to keep the same error messaging as
earlier:
$ objdump --sframe=sframe bubble_sort.o
...
No sframe section present
$ objdump --sframe=.sfram bubble_sort.o
...
No .sfram section present
$ objdump --sframe=sframe-internal-only sort
...
No sframe-internal-only section present
Similarly for readelf:
$ readelf --sframe= bubble_sort.o
readelf: Error: Section name must be provided
$ readelf --sframe=.sfram bubble_sort.o
readelf: Warning: Section '.sfram' was not dumped because it does not exist
$ readelf --sframe=sframe bubble_sort.o
readelf: Warning: Section 'sframe' was not dumped because it does not exist
PS: Note how this patch adds a new entry to debug_displays[] with a
relocate value set to FALSE. This will be set to TRUE in a subsequent
patch ("bfd: gas: ld: libsframe: emit func start addr field as an offset
from FDE") when fixes are made to emit the value of the
'sfde_func_start_address' field in the new encoding
SFRAME_F_FDE_FUNC_START_PCREL across gas and ld.
binutils/
* dwarf.c (display_sframe): New definition.
(dwarf_select_sections_all): Enable SFrame section too.
(struct dwarf_section_display): Add entry for SFrame section.
* dwarf.h (enum dwarf_section_display_enum): Add enumerator for
SFrame.
* objdump.c (dump_section_sframe): Remove.
(dump_sframe_section): Add new definition.
(dump_bfd): Use dump_sframe_section.
* binutils/readelf.c (dump_section_as_sframe): Remove.
include: sframe: doc: define new flag SFRAME_F_FDE_FUNC_START_PCREL
Add a new flag SFRAME_F_FDE_FUNC_START_PCREL to SFrame stack trace
format. If set, this flag indicates that the function start address
field (sfde_func_start_address) is the offset to the function start
address from the SFrame FDE function start address field itself.
Such an encoding is friendlier to the exisitng PC-REL relocations
available in the ABIs supported in SFrame: AMD64 (R_X86_64_PC32) and
AArch64 (R_AARCH64_PREL32). In subsequent patches, we will make the
implementation in gas and ld to both:
- emit the values in the same (above-mentioned) encoding uniformly.
- set the flag SFRAME_F_FDE_FUNC_START_PCREL in the SFrame header
for consumers to be able to distinguish.
Define SFRAME_V2_F_ALL_FLAGS in sframe.h to help keep the implementation
less error-prone by keeping a set of all defined flags at a central
place. Adjust the check in sframe_header_sanity_check_p () to use the
SFRAME_V2_F_ALL_FLAGS instead.
Add documentation for SFRAME_F_FDE_FUNC_START_PCREL. Update the
documentation about the encoding of the sfde_func_start_address field.
Also, update the section "Changes from Version 1 to Version 2" to
include the specification of the new flag SFRAME_F_FDE_FUNC_START_PCREL
as an erratum to the SFrame Version 2 specification.
include/
* sframe.h (SFRAME_F_FDE_FUNC_START_PCREL): New definition.
(SFRAME_V2_F_ALL_FLAGS): Likewise.
libsframe/
* sframe-dump.c (dump_sframe_header_flags): Update to include
the new flag SFRAME_F_FDE_FUNC_START_PCREL.
* sframe.c (sframe_header_sanity_check_p): Use
SFRAME_V2_F_ALL_FLAGS.
libsframe/doc/
* sframe-spec.texi: Add details about the new flag. Also update
the defails about the sfde_func_start_address encoding.
include: libsframe: add APIs for offsetof FDE func start addr field
These APIs will be later used by the linker to arrange SFrame FDEs in
the output SFrame section.
include/
* sframe-api.h (sframe_decoder_get_offsetof_fde_start_addr): New
declaration.
(sframe_encoder_get_offsetof_fde_start_addr): Likewise.
libsframe/
* libsframe.ver: List the new APIs.
* sframe.c (sframe_decoder_get_offsetof_fde_start_addr): New
definition.
(sframe_encoder_get_offsetof_fde_start_addr): Likewise.
libsframe: refactor code for dumping section flags
To prepare code for accommodating new flag additions easily as the
format evolves.
libsframe/
* sframe-dump.c (SFRAME_HEADER_FLAGS_STR_MAX_LEN): Remove.
(dump_sframe_header_flags): .. to here. New definition.
(PRINT_FLAG): New definition.
(dump_sframe_header): Move some implementation from here ..
include: libsframe: add APIs for SFrame header flags
Add new APIs, one each for getting flags from the SFrame decoder and
SFrame encoder context objects respectively.
These will later be used by the linker to uniformly access the flags,
given the SFrame decoder and SFrame encoder objects.
Use the new API, where applicable, within libsframe.
include/
* sframe-api.h (sframe_decoder_get_flags): New declaration.
(sframe_encoder_get_flags): Likewise.
libsframe/
* libsframe.ver: List new APIs.
* sframe.c (sframe_decoder_get_flags): New definition.
(sframe_encoder_get_flags): Likewise.
(sframe_get_funcdesc_with_addr_internal): Use the new API.
(sframe_encoder_get_flags): Likewise.
(sframe_encoder_write_sframe): Likewise.
The patch corrects the mips16 and micromips rela tables to *not*
use _bfd_mips_elf_{hi,lo}16_reloc. These special functions are
inappropriate for RELA relocs where addends are in the reloc rather
than in the section contents. See corresponding rela R_MIPS howtos.
bfd/
* elf64-mips.c (mips16_elf64_howto_table_rela)
<R_MIPS16_HI16, R_MIPS16_LO16>: Use _bfd_mips_elf_generic_reloc
special_function.
(micromips_elf64_howto_table_rela)
<R_MICROMIPS_HI16, R_MICROMIPS_LO16>: Similarly.
* elfn32-mips.c: As for elf64-mips.c.
MIPS/BFD: Fix RELA handling of borrow in the generic linker
Fix an issue with `_bfd_mips_elf_generic_reloc' not taking into account
any borrow from the lower part in the handling of relocations of the
HI/LO kind and resulting in incorrect calculations made for RELA targets
in the generic used for non-ELF output such as S-records. This doesn't
trigger for REL targets because they call `_bfd_mips_elf_generic_reloc'
indirectly from `_bfd_mips_elf_lo16_reloc' so as to obtain a complete
32-bit addend from relocation pairs and in calculating the addend the
latter function uses a hack to work around the lack of borrow handling
in the former function.
The MIPS/ELF linker is unaffected as it uses its own calculations.
Correct the calculation of the relevant partial relocations made in
`_bfd_mips_elf_generic_reloc' then to take the borrow into account and
remove the hack from `_bfd_mips_elf_lo16_reloc' as no longer needed.
Add generic linker test cases accordingly expecting the same disassembly
from srec output produced as from ELF output produced by the MIPS/ELF
linker.
MIPS/testsuite: Expand GAS and LD HI/LO relocation coverage
Expand test coverage for HI/LO relocation handling and add conventional
MIPS and microMIPS GAS tests as well as conventional MIPS, microMIPS,
and MIPS16e2 LD tests, covering R_MIPS_HI16, R_MIPS_LO16, R_MIPS16_HI16,
R_MIPS16_LO16, R_MICROMIPS_HI16, and R_MICROMIPS_LO16 relocations, as
well as 64-bit R_MIPS_HIGHEST, R_MIPS_HIGHER, R_MICROMIPS_HIGHEST, and
R_MICROMIPS_HIGHER relocations.
Modify the linker script so as to retain the `.MIPS.abiflags' section so
as to disassemble MIPS16e2 code correctly, as MIPS16e2 ASE information
is only carried in that section and not in ELF file header's `e_flags'.
MIPS16e2 and microMIPS code requires at least the MIPS32r2 ISA (or the
MIPS64r2 one for the n32 and n64 ABIs), which is incompatible with the
`mips:5900' linker output architecture and causes link failures such as:
./ld-new: tmpdir/mips-hilo1.o: linking mips:isa32r2 module with previous mips:5900 modules
./ld-new: failed to merge target specific data of file tmpdir/mips-hilo1.o
Therefore exclude `mips*el-ps2-elf*' targets from microMIPS and MIPS16e2
LD testing.
MIPS/LD/testsuite: Switch mips16-hilo tests to new disassembly format
Switch the o32 and n32 mips16-hilo MIPS LD tests to the new disassembly
format, to reduce discrepancies in output in preparation to reuse for
generic linker tests.
Taking the first line of disassembly output as an example the difference
is:
for ELF and srec input respectively with the currently used older format
requested with `--prefix-addresses', but with the new disassembly format
it is exactly the same between the two input formats and no information
that we need is lost in the transition:
MIPS/LD/testsuite: Remove symbol table output from mips16-hilo tests
The o32 and n32 mips16-hilo MIPS LD tests request symbol table output
only to discard it in matching. The symbol table is not relevant to
these tests, so remove it from output requested and adjust matching
patterns accordingly.
MIPS/testsuite: Fix %hi usage across MIPS16 GAS/LD tests
Fix a couple of places in MIPS GAS and LD R_MIPS16_HI16/R_MIPS16_LO16
relocation tests where the %hi operator has been incorrectly used, but
the %lo operator is expected to complement the preceding %hi operation.
IRIX 6 emulations place external small common symbols in the regular
common section instead of the small common section. With mips16-hilo
test this leads to a different symbol assignment to memory locations
between o32 and n32 ABIs, as follows:
which in turn causes a testsuite regression. Since the specific mapping
of symbols does not matter for the scope of the test, reorder the small
common section ahead of SBSS, so that the `small_external_common' symbol
ends up in the same place regardless of whether via the regular common
section or the small common section. Adjust embedded addresses in the
disassembly expected accordingly, removing the regression concerned:
mips-sgi-irix6 -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs n32
mips64el-ps2-elf -FAIL: R_MIPS16_HI16 and R_MIPS16_LO16 relocs n32
MIPS/LD/testsuite: Unify o32/n32 mips16-hilo test output
The mips16-hilo MIPS LD test case is supposed to produce the same final
linked output regardless of whether the o32 or n32 ABI has been chosen
for assembly. Reuse o32 output for the n32 test then.
Alan Modra [Sat, 5 Jul 2025 08:57:36 +0000 (18:27 +0930)]
gas pending_bundle_size assert
oss-fuzz managed to trigger this assert, by assembling directives in
the absolute section. Avoid this using similar code to that in
frags.c:frag_new (commit 2dc2dfa7d7a5).
Tom de Vries [Sat, 5 Jul 2025 11:29:53 +0000 (13:29 +0200)]
[gdb/tdep] Fix selftest scoped_mmap on freebsd
On x86_64-freebsd, I run into:
...
$ gdb -q -batch -ex "maint selftest scoped_mmap"
Running selftest scoped_mmap.
Self test failed: self-test failed at scoped_mmap-selftests.c:50
Failures:
scoped_mmap
Ran 1 unit tests, 1 failed
...
The problem is that this call:
...
::scoped_mmap smmap (nullptr, sysconf (_SC_PAGESIZE), PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
...
returns MAP_FAILED and sets errno to EINVAL because the argument fd == 0.
If MAP_ANONYMOUS is used, fd == -1 should be used on freebsd. On linux, fd is
ignored but -1 is recommended for portability.
Tom de Vries [Sat, 5 Jul 2025 11:29:53 +0000 (13:29 +0200)]
[gdb/tdep] Fix doc string of kvm pcb/proc command
On x86_64-freebsd, I ran into:
...
$ gdb -q -batch -ex "maint selftest help_doc_invariants"
Running selftest help_doc_invariants.
help doc broken invariant: command 'kvm pcb' help doc first line is not \
terminated with a '.' character
Self test failed: self-test failed at command-def-selftests.c:120
Andrew Burgess [Mon, 23 Jun 2025 15:32:28 +0000 (16:32 +0100)]
gdb: create gdb.sum/gdb.log summary after using check-all-boards
Use the contrib/dg-extract-results.sh script to create a gdb.sum and
gdb.log summary after running the check-all-boards make target.
Having the results from all the boards merged into a single file
isn't (maybe) the most useful, but it isn't a bad thing. However, the
great thing about merge the results is that the totals are also
merged.
The 'check-all-boards' recipe can then extract these totals, just as
we do for the normal 'check' recipe, this makes is much easier to
spot if there are any unexpected failures when using
'check-all-boards'.
Pietro Monteiro [Sat, 5 Jul 2025 01:13:13 +0000 (21:13 -0400)]
sim: configury: fix obsolete macros
Running `autoreconf -vf -Wall' in the sim directory shows errors about the use
of obsolete macros. This patch fix the issues with macros used or defined in
the sim directory. However, it doesn't fix all warnings. There's 1 autoconf
warning from `config/pkg.m4', and many automake warnings about target
shadowing. It cuts a lot of the noise down and makes an upgrade to
autoconf 2.71+ easier.
- Replace AC_CANONICAL_SYSTEM by AC_CANONICAL_TARGET
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fCANONICAL_005fSYSTEM-1997
- Replace AC_TRY_COMPILE by AC_COMPILE_IFELSE
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fTRY_005fCOMPILE-2203
- Replace AC_ERROR by AC_MSG_ERROR
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fERROR-2034
- Remove AC_TYPE_SIGNAL and replace `RETSIGTYPE' by `void' in the source
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fTYPE_005fSIGNAL-2213
- Remove AC_STRUCT_ST_BLKSIZE, it's already covered by a AC_CHECK_MEMBERS call
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fSTRUCT_005fST_005fBLKSIZE-2176
- Remove AC_STRUCT_ST_RDEV, it's already covered by a AC_CHECK_MEMBERS call
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fSTRUCT_005fST_005fRDEV-2180
- Remove AC_STRUCT_ST_BLOCKS. It is not obsolete, but it's already covered by a
AC_CHECK_MEMBERS call.
- Replace deprecated C macros HAVE_ST_${MEMBER} by HAVE_STRUCT_STAT_ST_${MEMBER}
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Particular-Structures.html#index-AC_005fSTRUCT_005fST_005fBLOCKS-693
Jan Beulich [Fri, 4 Jul 2025 08:42:18 +0000 (10:42 +0200)]
gas: introduce .errif and .warnif
Rather than having people resort to indirect means to issue a certain
kind of diagnostic conditionally upon an expression which can (or
should) only be evaluated when all sections were sized and all symbols
had their final values established, provide directives to directly
achieve this.
Jan Beulich [Fri, 4 Jul 2025 08:41:34 +0000 (10:41 +0200)]
gas: add a means to programmatically determine the assembler version
It has been more than once that I would have wanted to have a way to
know the gas version in assembly sources, perhaps for use with .if. Add
such a pre-defined symbol, introducing the common pattern GAS(<symbol>)
for any such symbols. The use of parentheses is to keep the risk of
collisions with users' symbols as low as possible. (Possible future
arch-specific symbols may want to use GAS(<arch>:<symbol>).)
Similarly permit determining whether the assembler is a released
version. The exact value probably isn't of much use, it's more the
defined-ness that one might care about. Yet the symbol needs to have
some value anyway.
While by default pre-defined symbols won't be emitted to the symbol
table, introduce -emit-local-absolute to allow requesting this. Re-
purpose flag_strip_local_absolute to become tristate, with a negative
value indicating to also emit pre-defined symbols.
Jan Beulich [Fri, 4 Jul 2025 08:40:31 +0000 (10:40 +0200)]
cris/testsuite: don't use --em=
Using such abbreviations is fine when written on an interactive command
line by a human. In scripts and alike, doing so risks colliding with
later option additions, as is about to occur for gas: Shortly there'll
be --emit-local-absolute.
Simon Marchi [Thu, 3 Jul 2025 17:37:41 +0000 (13:37 -0400)]
gdb/linux-nat: initialize lwp_info::syscall_state
When running gdb.base/foll-fork-syscall.exp with a GDB built with UBSan,
I get:
/home/simark/src/binutils-gdb/gdb/linux-nat.c:1906:28: runtime error: load of value 3200171710, which is not a valid value for type 'target_waitkind'
ERROR: GDB process no longer exists
GDB process exited with wait status 3026417 exp9 0 1
UNRESOLVED: gdb.base/foll-fork-syscall.exp: follow-fork-mode=child: detach-on-fork=on: test_catch_syscall: continue to breakpoint after fork
The error happens here:
#0 __sanitizer::Die () at /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_termination.cpp:50
#1 0x00007ffff600d8dd in __ubsan::__ubsan_handle_load_invalid_value_abort (Data=<optimized out>, Val=<optimized out>) at /usr/src/debug/gcc/gcc/libsanitizer/ubsan/ubsan_handlers.cpp:551
#2 0x00005555636d37b6 in linux_handle_syscall_trap (lp=0x7cdff1eb1b00, stopping=0) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:1906
#3 0x00005555636e0991 in linux_nat_filter_event (lwpid=3030627, status=1407) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3044
#4 0x00005555636e407f in linux_nat_wait_1 (ptid=..., ourstatus=0x7bfff0d6cf18, target_options=...) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3381
#5 0x00005555636e7795 in linux_nat_target::wait (this=0x5555704d35e0 <the_amd64_linux_nat_target>, ptid=..., ourstatus=0x7bfff0d6cf18, target_options=...) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3607
#6 0x000055556378fad2 in thread_db_target::wait (this=0x55556af42980 <the_thread_db_target>, ptid=..., ourstatus=0x7bfff0d6cf18, options=...) at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1398
#7 0x0000555564811327 in target_wait (ptid=..., status=0x7bfff0d6cf18, options=...) at /home/simark/src/binutils-gdb/gdb/target.c:2593
I believe the problem is that lwp_info::syscall_state is never
initialized. Fix that by initializing it with TARGET_WAITKIND_IGNORE.
This is the value we use elsewhere when resetting this field to mean
"not stopped at a syscall".
Change-Id: I5b76c63d1466d6e63448fced03305fd5ca8294eb Approved-By: Tom Tromey <tom@tromey.com>
Yodel Eldar [Mon, 26 May 2025 15:12:19 +0000 (10:12 -0500)]
gdb/alpha: Redefine fpcr with fpcr_flags type
This commit adds fpcr_flags and dyn_rm_enum types to define the fpcr.
For details on the floating-point control register (fpcr), please see
the Alpha Architecture Reference Manual, 4th Ed. [1]; in brief, it
consists of a 64-bit bitfield with most bits reserved/unused. All but a
pair of the used bits are boolean flags; the exception, DYN_RM, is a
2-bit enum indicating the IEEE rounding mode and is defined as a
dyn_rm_enum type in the target description annex.
Yodel Eldar [Mon, 26 May 2025 15:12:18 +0000 (10:12 -0500)]
gdb/alpha: Add target description support
This commit adds target description support for Alpha.
The target description obviates the alpha_register_type and
alpha_register_name functions in alpha-tdep.c. Removal of
alpha_register_reggroup_p was considered but ultimately abandoned,
because the "info regs" command would no longer omit the zero, fpcr, and
unique registers from its output (they are neither vector nor float
types).
Register types in the target description annex match the types that the
alpha_register_type function returned.
The locally defined register_names array was moved out of
alpha_register_name and renamed to alpha_register_names as a static
global; calls to alpha_register_name have been replaced with direct
access of the array.
The patch follows the code pattern outlined in the following GDB
Internals Wiki entry:
Tom de Vries [Wed, 2 Jul 2025 16:05:11 +0000 (18:05 +0200)]
[gdb/testsuite] Use support_displaced_stepping in gdb.arch/amd64-disp-step-avx.exp
In commit 8e73fddeb0d ("[gdb/testsuite] Fix gdb.arch/amd64-disp-step-avx.exp
on x86_64-freebsd") I added a "require {istarget *-*-linux*}", but since then
I found support_displaced_stepping, which seems more appropriate and
descriptive.
Fix this by requiring support_displaced_stepping instead.
Tom de Vries [Wed, 2 Jul 2025 06:14:03 +0000 (08:14 +0200)]
[gdb/testsuite] Fix gdb.arch/amd64-disp-step-avx.exp on x86_64-freebsd
With test-case gdb.arch/amd64-disp-step-avx.exp on x86_64-freebsd I run into:
...
(gdb) continue
Continuing.
Breakpoint 3, test_rip_vex2_end () at amd64-disp-step-avx.S:35
35 nop
(gdb) FAIL: $exp: vex2: continue to test_rip_vex2_end
...
This happens while executing this bit of the test-case:
...
# Turn "debug displaced" on to make sure a displaced step is actually
# executed, not an inline step.
gdb_test_no_output "set debug displaced on"
Tom Tromey [Fri, 13 Jun 2025 18:54:16 +0000 (12:54 -0600)]
Fix handling of terminal escape sequences in TUI
A user noticed that if the remote sends terminal escape sequences from
the "monitor" command, then these will not be correctly displayed when
in TUI mode.
I tracked this down to remote.c emitting one character at a time --
something the TUI output functions did not handle correctly.
I decided in the end to fix in this in the ui-file layer, because the
same bug seems to affect logging and, as is evidenced by the test case
in this patch, Python output in TUI mode.
The idea is simple: buffer escape sequences until they are either
complete or cannot possibly be recognized by gdb.
Regression tested on x86-64 Fedora 40.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14126 Approved-By: Andrew Burgess <aburgess@redhat.com>
A SFrame NULL FRE template is used as NULL value in some but not all
instances to initialize unused elements of SFrame FRE pointer arrays of
fixed size. Additionally it is erroneously used as SFrame FRE template
for PLT GOT entries.
Define a separate SFrame FRE template for PLT GOT entries with the same
properties as the SFrame NULL FRE and use that for all PLT GOT entries.
Remove the SFrame NULL FRE template, as initialization of unused array
elements is not required, as demonstrated by the instances where it was
not done.
bfd/
* elf64-x86-64.c (elf_x86_64_sframe_null_fre): Remove.
(elf_x86_64_sframe_pltgot_fre1): New SFrame FRE template for
PLT GOT entries.
(elf_x86_64_sframe_non_lazy_plt,
elf_x86_64_sframe_non_lazy_ibt_plt): Do not initialize unused
FRE array elements with elf_x86_64_sframe_null_fre. Use
elf_x86_64_sframe_pltgot_fre1 for PLT GOT.
(elf_x86_64_sframe_plt, elf_x86_64_sframe_ibt_plt): Use
elf_x86_64_sframe_pltgot_fre1 for PLT GOT.
Bruce McCulloch [Fri, 27 Jun 2025 16:21:52 +0000 (09:21 -0700)]
libctf: doc: add __float128 and SIMD vector classification to spec.
This patch adds two additional distinct types (__float128 and the SIMD
vector type generated from the vector_size attribute) to the umbrella of
two existing types (long double and array, respectively). These types
were previously invalid, producing CTF_K_UNKNOWN in the case of
__float128 or a float in the case of the SIMD vector. This patch will
cleanly allow these types to be represented more accurately without
breaking back-compat.
Signed-off-by: Bruce McCulloch <bruce.mcculloch@oracle.com> Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
Nick Alcock [Thu, 26 Jun 2025 14:47:25 +0000 (15:47 +0100)]
libctf: create: check the right root-visible flag when adding enumerands
The root-visible flag we're dealing with here is directly out of the dict,
not a flag passed in to the API, so it does not have the values CTF_ADD_ROOT
or CTF_ADD_NONROOT: instead it's simply zero for non-root-visible, nonzero
otherwise. Fix the test.
Nick Alcock [Thu, 26 Jun 2025 14:45:31 +0000 (15:45 +0100)]
libctf: create: addition of non-root types should not return root types
If you add a non-root type to a dict, you should always get a new, unique
type ID back, even if a root-visible type with the same name already exists.
Unfortunately, if the root-visible type is a forward, and you're adding a
non-root-visible struct, union, or enum, the machinery to detect forwards
and promote them to the concrete type fires in this case and returns the
root-visible type! If this is an enum being inserted hidden because its
enumerands conflict with some other enum, this will lead to failure later
on: in any case, it's seriously counterintuitive to add a non-root- visible
type and get a root-visible one instead.
Fix this by checking the root-visible flag properly and only checking for
forwards if this type is root-visible. (This may lead to a certain degree
of proliferation of non-root-visible forwards: we can add a cleanup pass for
those later if needed.)
libctf/
* ctf-create.c (ctf_add_struct_sized): Check the root-visible flag when
doing forward promotion.
(ctf_add_union_sized): Likewise.
(ctf_add_enum): Likewise.
Reviewed-by: Bruce McCulloch <bruce.mcculloch@oracle.com>
Alan Modra [Tue, 1 Jul 2025 13:05:07 +0000 (14:05 +0100)]
MIPS: Fix addend handling with rela R_MIPS16_GOT16 and R_MICROMIPS_GOT16
In rela howtos these relocations should not be using
_bfd_mips_elf_got16_reloc. That special function is for extracting
addends from section contents, and only for that (ie. it doesn't
subtract gp). Make these rela howtos like the corresponding
R_MIPS_GOT16 rela howto.
WANG Xuerui [Mon, 16 Jun 2025 08:16:55 +0000 (16:16 +0800)]
RISC-V: [gprofng] Allow building gprofng without asm/hwprobe.h
The code is actually able to gracefully fallback if the syscall number
of riscv_hwprobe is not available at build time, but it still depended
on the <asm/hwprobe.h> header unconditionally. In certain environments
such as one of crosstool-NG's Canadian Cross build step (binutils for
host), or one with very outdated kernel headers, the header will not be
present, causing the build to fail.
While the relevant projects/environments should be fixed nevertheless,
a configure-time check for <asm/hwprobe.h> is helpful for fixing gprofng
builds with released versions of ct-ng etc.
Simon Marchi [Sat, 28 Jun 2025 12:08:33 +0000 (08:08 -0400)]
gdb/solib-target: move make_target_solib_ops out of HAVE_LIBEXPAT
When building without expat, we get a missing make_target_solib_ops
error:
/usr/bin/ld: arch-utils.o: in function `gdbarch::gdbarch()':
/home/simark/src/binutils-gdb/gdb/gdbarch-gen.c:30:(.text+0x15be): undefined reference to `make_target_solib_ops()'
Fix it by moving make_target_solib_ops out of HAVE_LIBEXPAT.
Tom de Vries [Sat, 28 Jun 2025 11:03:14 +0000 (13:03 +0200)]
[gdb/tdep] Add "maint set console-translation-mode <binary|text>" command
On MSYS2, say we record a brief gdb session using TERM=dumb script:
...
$ gdb -q
(gdb) print 1
$1 = 1
(gdb) q
...
When looking at the resulting typescript, we notice something odd:
...
$ gdb -q^M
(gdb) print 1^M
$1 = 1^M^M
(gdb) q^M
...
For some reason, we have "$1 = 1\r\r\n(gdb) ".
Looking at the documentation of _setmode [1], it mentions translation mode
_O_TEXT as a mode in which "\n" is translated into "\r\n" on output.
So, it looks like this translation happens twice.
Add a command "maint set console-translation-mode <binary|text>" command that
allows us to set the translation mode of stdout/stderr to binary, such that we
get instead:
...
$ gdb -q -ex "maint set console-translation-mode binary"^M
(gdb) print 1^M
$1 = 1^M
(gdb) q^M
...
Since we run into this in the testsuite, add
"maint set console-translation-mode binary" to INTERNAL_GDBFLAGS.
Based on "maint set testsuite-mode on/off" from these patches [2][3] by Pierre
Muller.
Compared to that proposal, I dropped the name testsuite-mode, because the
behaviour is not specific to the testsuite.
Also I chose values binary/text instead of on/off because eventually there may
be other translation mode values that we need [4].
Co-Authored-By: Pierre Muller <muller@sourceware.org> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
[1] https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setmode
[2] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00939.html
[3] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00940.html
[4] https://learn.microsoft.com/en-us/cpp/c-runtime-library/translation-mode-constants
While trying to build current trunk of GDB on FreeBSD 14.3 on aarch64,
I hit this warning converted to an error:
In file included from /home/bauermann/src/binutils-gdb/gdb/maint.c:37:
/home/bauermann/src/binutils-gdb/gdb/maint.h:64:8: error: private field 'm_start_space' is not used [-Werror,-Wunused-private-field]
64 | long m_start_space;
| ^
1 error generated.
gmake[2]: *** [Makefile:1973: maint.o] Error 1
I used the default compiler on this system:
$ c++ --version
FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2)
Target: aarch64-unknown-freebsd14.3
Thread model: posix
InstalledDir: /usr/bin
The problem is that the only two places that use m_start_space are
guarded by HAVE_USEFUL_SBRK, so also guard the member declaration with
it.
Build-tested on aarch64-unknown-freebsd14.3.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Thu, 26 Jun 2025 17:36:58 +0000 (13:36 -0400)]
gdb/solib: C++ify solib_ops
Convert solib_ops into an abstract base class (with abstract methods,
some of them with default implementations) and convert all the existing
solib_ops instances to solib_ops derived classes / implementations.
Prior to this patch, solib_ops is a structure holding function pointers,
of which there are only a handful of global instances (in the
`solib-*.c` files). When passing an `solib_ops *` around, it's a
pointer to one of these instances. After this patch, there are no more
global solib_ops instances. Instances are created as needed and stored
in struct program_space. These instances could eventually be made to
contain the program space-specific data, which is currently kept in
per-program space registries (I have some pending patches for that).
Prior to this patch, `gdbarch_so_ops` is a gdbarch method that returns a
pointer to the appropriate solib_ops implementation for the gdbarch.
This is replaced with the `gdbarch_make_solib_ops` method, which returns
a new instance of the appropriate solib_ops implementation for this
gdbarch. This requires introducing some factory functions for the
various solib_ops implementation, to be used as `gdbarch_make_solib_ops`
callbacks. For instance:
The previous code is full of cases of tdep files copying some base
solib_ops implementation, and overriding one or more function pointer
(see ppc_linux_init_abi, for instance). I tried to convert all of this
is a class hierarchy. I like that it's now possible to get a good
static view of all the existing solib_ops variants. The hierarchy looks
like this:
The solib-svr4 code has per-arch specialization to provide a
link_map_offsets, containing the offsets of the interesting fields in
`struct link_map` on that particular architecture. Prior to this patch,
arches would set a callback returning the appropriate link_map_offsets
by calling `set_solib_svr4_fetch_link_map_offsets`, which also happened
to set the gdbarch's so_ops to `&svr_so_ops`. I converted this to an
abstract virtual method of `struct svr4_solib_ops`, meaning that all
classes deriving from svr4_solib_ops must provide a method returning the
appropriate link_map_offsets for the architecture. I renamed
`set_solib_svr4_fetch_link_map_offsets` to `set_solib_svr4_ops`. This
function is still necessary because it also calls
set_gdbarch_iterate_over_objfiles_in_search_order, but if it was not for
that, we could get rid of it.
There is an instance of CRTP in mips-linux-tdep.c, because both
mips_linux_ilp32_svr4_solib_ops and mips_linux_lp64_svr4_solib_ops need
to derive from different SVR4 base classes (linux_ilp32_svr4_solib_ops
and linux_lp64_svr4_solib_ops), but they both want to override the
in_dynsym_resolve_code method with the same implementation.
The solib_ops::supports_namespaces method is new: the support for
namespaces was previously predicated by the presence or absence of a
find_solib_ns method. It now needs to be explicit.
There is a new progspace::release_solib_ops method, which is only needed
for rocm_solib_ops. For the moment, rocm_solib_ops replaces and wraps
the existing svr4_solib_ops instance, in order to combine the results of
the two. The plan is to have a subsequent patch to allow program spaces to have
multiple solib_ops, removing the need for release_solib_ops.
Speaking of rocm_solib_ops: it previously overrode only a few methods by
copying svr4_solib_ops and overwriting some function pointers. Now, it
needs to implement all the methods that svr4_solib_ops implements, in
order to forward the call. Otherwise, the default solib_ops method
would be called, hiding the svr4_solib_ops implementation. Again, this
can be removed once we have support for multiple solib_ops in a
program_space.
There is also a small change in how rocm_solib_ops is activated. Prior
to this patch, it's done at the end of rocm_update_solib_list. Since it
overrides the function pointer in the static svr4_solib_ops, and then
overwrites the host gdbarch, so_ops field, it's something that happens
only once. After the patch though, we need to set rocm_solib_ops in all
the program spaces that appear. We do this in
rocm_solib_target_inferior_created and in the new
rocm_solib_target_inferior_execd. After this, I will explore doing a
change where rocm_solib_ops is only set when we detect the ROCm runtime
is loaded.
Change-Id: I5896b5bcbf8bdb024d67980380feba1ffefaa4c9 Approved-By: Pedro Alves <pedro@palves.net>
Simon Marchi [Thu, 26 Jun 2025 17:36:06 +0000 (13:36 -0400)]
gdb/progspace: add solib_ops pointer in program_space
The subsequent C++ification patch in this series will allocate one
instance of solib_ops per program space. That instance will be held in
struct program_space. As a small step towards this, add an `solib_ops
*` field to `struct program_space`. This field represents the solib_ops
currently used to manage the solibs in that program space. Initialize
it with the result of `gdbarch_so_ops` in `post_create_inferior`, and
use it whenever we need to do some solib stuff, rather than using
`gdbarch_so_ops` directly.
The difficulty here is knowing when exactly to set and unset the solib
ops. What I have here passes the testsuite on Linux, but with more
testing we will probably discover more spots where it's needed.
The C++ification patch will turn this field into a unique pointer.
With this patch, the message we get when running "info
linker-namespaces" becomes always the same, so update the test in
gdb.base/dlmopen-ns-ids.exp.
Change-Id: Ide8ddc57328895720fcd645d46dc34491f84c656 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Simon Marchi [Mon, 16 Jun 2025 19:33:02 +0000 (15:33 -0400)]
gdb/solib: use solib::ops for operations that concern a single solib
For operations that concern a single solib, use the solib_ops backlink
added in the previous patch (solib::ops), instead of using the solib_ops
from the gdbarch. This is a small / easy step towards not using
gdbarch_so_ops, which is necessary for the C++ification patch later in
this series.
There is no change in behavior expected.
Change-Id: If80e9ea717a2788bada1cf0940cda3c73933bcff Approved-By: Pedro Alves <pedro@palves.net>
Simon Marchi [Mon, 16 Jun 2025 19:33:01 +0000 (15:33 -0400)]
gdb/solib: add solib -> solib_ops backlink
The subsequent C++ification commit makes it so that one struct solib_ops
is instantiated for each program space. For some operations, it will
then become necessary to be able to get the right solib_ops instance
from a given solib. Add an solib -> solib_ops backlink for that.
Change-Id: Ib95407b3fa5fcfba55cf874e0e9dcd2d43a402e4 Approved-By: Pedro Alves <pedro@palves.net>
Simon Marchi [Mon, 16 Jun 2025 19:32:59 +0000 (15:32 -0400)]
gdb/testsuite: check that "info shared" and "info linker-namespaces" before running don't crash
While writing my solib_ops C++ification series, I broke this, and it
didn't seem to be caught by the testsuite. Add a test for those.
The exact message for "info linker-namespaces" varies depending on the
solib_ops of the target architecture (whether ops->num_active_namespaces
is nullptr or not). For now, just accept any message (a crash will
still be caught). A later patch in this series will make the message
consistent and update this test.
Change-Id: I6bce2ff317447bbf321fc9cbd2d42c3dcea0c683 Approved-By: Pedro Alves <pedro@palves.net>
gdb: linux-namespaces: enter user namespace when appropriate
added a new test gdb.base/user-namespace-attach.exp. It has been
reported that this test will sometimes fail, like this:
(gdb) attach 184732
Attaching to process 184732
warning: process 184732 is a zombie - the process has already terminated
ptrace: Operation not permitted.
(gdb) FAIL: gdb.base/user-namespace-attach.exp: flags=--mount --map-root-user: attach to inferior
the test tries to run the 'unshare' application. Sometimes though,
the application is present, but the set of flags used is not
supported (maybe due to restrictions on the local machine), so we see
behaviour like this:
Handle this case by first running 'unshare' with the same flags, but
using '/bin/true', if this fails then assume the flags are not
supported, and skip the test.
Tom Tromey [Thu, 22 May 2025 17:54:16 +0000 (11:54 -0600)]
Change file initialization to use INIT_GDB_FILE macro
This patch introduces a new macro, INIT_GDB_FILE. This is used to
replace the current "_initialize_" idiom when introducing a per-file
initialization function. That is, rather than write:
The macro handles both the declaration and definition of the function.
The point of this approach is that it makes it harder to accidentally
cause an initializer to be omitted; see commit 2711e475 ("Ensure
cooked_index_entry self-tests are run"). Specifically, the regexp now
used by make-init-c seems harder to trick.
New in v2: un-did some erroneous changes made by the script.
The bulk of this patch was written by script.
Regression tested on x86-64 Fedora 41.
aarch64: Add supports for FEAT_PoPS feature and DC instructions.
This patch add support for FEAT_PoPS feature which can be enabled
through +pops command line flag.
This patch also adds support for following DC instructions and the
spec can be found here [1].
1. "dc cigdvaps" enabled on passing +memtag+pops command line flags.
2. "dc civaps" enabled on passing +pops command line flag.
Andrew Burgess [Tue, 17 Jun 2025 16:39:36 +0000 (17:39 +0100)]
gdb: remove final m_stream->emit_style_escape calls from pager_file
After the last commit there were still a couple of calls to
m_stream->emit_style_escape in the pager_file class. As discussed in
the last commit, these are likely wrong, but I'd not been able to
produce any bugs because of them.
The reason why there are no bugs is that these calls are, I think,
entirely redundant. Consider this block:
if (m_wrap_column)
{
/* We are about to insert a newline at an historic
location in the WRAP_BUFFER. Before we do we want to
restore the default style. To know if we actually
need to insert an escape sequence we must restore the
current applied style to how it was at the WRAP_COLUMN
location. */
m_applied_style = m_wrap_style;
m_stream->emit_style_escape (ui_file_style ());
/* If we aren't actually wrapping, don't output
newline -- if chars_per_line is right, we
probably just overflowed anyway; if it's wrong,
let us keep going. */
m_stream->puts ("\n");
}
What we know (see previous commit) is that the call:
m_stream->emit_style_escape (ui_file_style ());
is dangerous as m_stream->m_applied_style is going to be out of sync
with its current state. Actually, m_stream->m_applied_style is likely
to be the default style as it is not updated elsewhere. So why does
this not cause problems?
Well, GDB's style output is always done in tightly scoped regions.
That means if we want to print some styled output, and then apply a
wrap point the code might look like this:
But, after printing 'some text', the style of gdb_stdout will have
returned to the default style.
My claim is that, whenever we encounter a wrap_here call, the stream
in question will _always_ have been returned to the default style.
This means that, in the block above, the call:
m_stream->emit_style_escape (ui_file_style ());
will never emit anything because it depends on a check against
m_stream->m_applied_style, which will always mean that the above call
does nothing. But that's OK. By chance, we'll have always placed the
stream into a default style state anyway, so no harm done.
Similarly, the other call:
/* Having finished inserting the wrapping we should
restore the style as it was at the WRAP_COLUMN. */
m_stream->emit_style_escape (m_wrap_style);
Tries to return m_stream to the state it was in at the point of the
wrap_here call. But, as described above, this will always be the
default style, so the above call will do nothing, but that just
happens to be exactly what we want!
So what does this commit do?
Well, I "fix" the above code by removing the
m_stream->emit_style_escape calls and replacing them with calls to
puts, passing in the escape sequence for the required style, but only
if the m_stream style as tracked by pager_file::m_stream_style
indicates this is needed.
Got the reasons given above, this should mean there is no change after
this patch. We still shouldn't be emitting any extra escape
sequences. But, should we ever manage to get into a state where we
call wrap_here with a stream in a style other than the default, then
this should mean things work as expected.
There should be no user visible changes after this commit.
Andrew Burgess [Mon, 16 Jun 2025 16:20:57 +0000 (17:20 +0100)]
gdb: styling fixes around and for the pagination prompt
This commit fixes a couple of issues relating to the pagination
prompt and styling. The pagination prompt is this one:
--Type <RET> for more, q to quit, c to continue without paging--
I did try to split this into multiple patches, based on the three
issues I describe below, but in the end, the fixes were all too
interconnected, so it ended up as one patch that makes two related,
but slightly different changes:
1. Within the pager_file class, relying on the m_applied_style
attribute of the wrapped m_stream, as is done when calling
m_stream->emit_style_escape, is not correct, so stop doing that, and
2. Failing to update m_applied_style within the pager_file class can
leave that attribute out of date, which can then lead to styling
errors later on, so ensure m_applied_style is always updated.
The problems I have seen are:
1. After quitting from a pagination prompt, the next command can
incorrectly style its output. This was reported as bug PR
gdb/31033, and is fixed by this commit.
2. The pagination prompt itself could be styled. The pagination
prompt should always be shown in the default style.
3. After continuing the output at a pagination prompt, GDB can fail
to restore the default style the next time the output (within the
same command) switches back to the default style.
There are tests for all these issues as part of this patch.
The pager_file class is a sub-class of wrapped_file, this means that a
pager_file is itself a ui_file, while it also manages a pointer to a
ui_file object (called m_stream). An instance of pager_file can be
installed as the gdb_stdout ui_file object.
Output sent to a pager_file is stored within an internal
buffer (called m_wrap_buffer) until we have a complete line, when the
content is flushed to the wrapped m_stream. If sufficient lines have
been written out then the pager_file will present the pagination
prompt and allow the user to continue viewing output, or quit the
current command.
As a pager_file is a ui_file, it has an m_applied_style member
variable.
The managed stream (m_stream) is also a ui_file, and so also has an
m_applied_style member variable.
In some places within the pager_file class we attempt to change the
current style of the m_stream using calls like this:
m_stream->emit_style_escape (style);
See pager_file::emit_style_escape, pager_file::prompt_for_continue,
and pager_file::puts. These calls will end up in
ui_file::emit_style_escape, which tries to skip emitting unnecessary
style escapes by checking if the requested style matches the current
m_applied_style value.
The m_applied_style value is updated by calls to the emit_style_escape
function.
The problem here is that most of the time pager_file doesn't change
the style of m_stream by calling m_stream->emit_style_escape. Most of
the time, style changes are performed by pager_file writing the escape
sequence into m_wrap_buffer, and then later flushing this buffer to
m_stream by calling m_stream->puts.
It has to be done this way. Calling m_stream->emit_style_escape
would, if it actually changed the style, immediately change the style
by emitting an escape sequence. But pager_file doesn't want that, it
wants the style change to happen later, when m_wrap_buffer is
flushed.
To avoid excessive style escape sequences being written into
m_wrap_buffer, the pager_file::m_applied_style performs a function
similar to the m_applied_style within m_stream, it tracks the current
style for the end of m_wrap_buffer, and only allows style escape
sequences to be emitted if the style is actually changing.
However, a consequence of this is the m_applied_style within m_stream,
is not updated, which means it will be out of sync with the actual
current style of m_stream. If we then try to make a call to
m_stream->emit_style_escape, if the style we are changing too happens
to match the out of date style in m_stream->m_applied_style, then the
style change will be ignored.
And this is indeed what we see in pager_file::prompt_for_continue with
the call:
m_stream->emit_style_escape (ui_file_style ());
As m_stream->m_applied_style is not being updated, it will always be
the default style, however m_stream itself might not actually be in
the default style. This call then will not emit an escape sequence as
the desired style matches the out of date m_applied_style.
The fix in this case is to call m_stream->puts directly, passing in
the escape sequence for the desired style. This will result in an
immediate change of style for m_stream, which fixes some of the
problems described above.
In fact, given that m_stream's m_applied_style is always going to be
out of sync, I think we should change all of the
m_stream->emit_style_escape calls to instead call m_stream->puts.
However, just changing to use puts doesn't fix all the problems.
I found that, if I run 'apropos time', then quit at the first
pagination prompt. If for the next command I run 'maintenance time' I
see the expected output:
"maintenance time" takes a numeric argument.
However, everything after the first double quote is given the command
name style rather than only styling the text between the double
quotes.
Here is GDB's stack while printing the above output:
#2 0x0000000001050d56 in ui_out::vmessage (this=0x7fff1238a150, in_style=..., format=0x1c05af0 "", args=0x7fff1238a288) at ../../src/gdb/ui-out.c:754
#3 0x000000000104db88 in ui_file::vprintf (this=0x3f9edb0, format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n", args=0x7fff1238a288) at ../../src/gdb/ui-file.c:73
#4 0x00000000010bc754 in gdb_vprintf (stream=0x3f9edb0, format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n", args=0x7fff1238a288) at ../../src/gdb/utils.c:1905
#5 0x00000000010bca20 in gdb_printf (format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n") at ../../src/gdb/utils.c:1945
#6 0x0000000000b6b29e in maintenance_time_display (args=0x0, from_tty=1) at ../../src/gdb/maint.c:128
The interesting frames here are #3, in here `this` is the pager_file
for GDB's stdout, and this passes its m_applied_style to frame #2 as
the `in_style` argument.
If the m_applied_style is wrong, then frame #2 will believe that the
wrong style is currently in use as the default style, and so, after
printing 'maintenance time' GDB will switch back to the wrong style.
So the question is, why is pager_file::m_applied_style wrong?
In pager_file::prompt_for_continue, there is an attempt to switch back
to the default style using:
m_stream->emit_style_escape (ui_file_style ());
If this is changed to a puts call (see above) then this still leaves
pager_file::m_applied_style out of date.
The right fix in this case is, I think, to instead do this:
this->emit_style_escape (ui_file_style ());
this will update pager_file::m_applied_style, and also send the
default style to m_stream using a puts call.
While writing the tests I noticed that I was getting unnecessary style
reset sequences emitted.
The problem is that, around pagination, we don't really know what
style is currently applied to m_stream. The
pager_file::m_applied_style tracks the style at the end of
m_wrap_buffer, but this can run ahead of the current m_stream style.
For example, if the screen is currently full, such that the next
character of output will trigger the pagination prompt, if the next
call is actually to pager_file::emit_style_escape, then
pager_file::m_applied_style will be updated, but the style of m_stream
will remain unchanged. When the next character is written to
pager_file::puts then the pagination prompt will be presented, and GDB
will try to switch m_stream back to the default style. Whether an
escape is emitted or not will depend on the m_applied_style value,
which we know is different than the actual style of m_stream.
It is, after all, only when m_wrap_buffer is flushed to m_stream that
the style of m_stream actually change.
And so, this commit also adds pager_file::m_stream_style. This new
variable tracks the current style of m_stream. This really is a
replacement for m_stream's ui_file::m_applied_style, which is not
accessible from pager_file.
When content is flushed from m_wrap_buffer to m_stream then the
current value of pager_file::m_applied_style becomes the current style
of m_stream. But, when m_wrap_buffer is filling up, but before it is
flushed, then pager_file::m_applied_style can change, but
m_stream_style will remain unchanged.
Now in pager_file::emit_style_escape we are able to skip some of the
direct calls to m_stream->puts() used to emit style escapes.
After all this there are still a few calls to
m_stream->emit_style_escape(). These are all in the wrap_here support
code. I think that these calls are technically broken, but don't
actually cause any issues due to the way styling works in GDB. I
certainly haven't been able to trigger any bugs from these calls yet.
I plan to "fix" these in the next commit just for completeness.
Matthieu Longo [Thu, 17 Apr 2025 08:11:24 +0000 (09:11 +0100)]
readelf: invalid error message triggered when last tag is an empty string
Disclaimer: this issue cannot occur with Object Attributes v1 (OAv1) while
using the GNU binutils because a value of '\0' (empty string) for a tag
with a string value is considered as the default value for the attribute,
and consequently is eliminated by gas from the output object file during
the serialization.
An empty string is a valid value for a NTBS tag in both OAv1 and OAv2 [1]
cases. However, contrarily to OAv1, a OAv2 subsection can be required and
so, tags in this subsection might have to be present even if the value is
the default. To comply with this requirement, the OAv2 serializer won't
drop the default values.
In the case where a NTBS tag has the value '\0' and is last in the object
attributes section, the current code in readelf used for dumping the object
attributes incorrectly detects an overflow, and prints out an error message
for a corrupted string tag.
This patch fixes the detection of the overflow so that it now accept an
empty string in the last tag of the object attributes section.
It also fixes the previous tests for the empty NTBS case and the non-null
terminated string one. The fix was also tested in the context of OAv2's
patch series [1] where the issue was originally detected. No regression
was found.
Matthieu Longo [Fri, 20 Jun 2025 11:24:58 +0000 (12:24 +0100)]
arm testsuite: add two corner cases for EABI string attributes
The current testsuite for gas/readelf lacked two tests for EABI build
attributes:
- one when the final attribute is an empty string.
- one when the final attribute is a string missing the NULL terminator.
Those two issues cannot occur with Object Attributes v1 (OAv1) sections
created by the GNU binutils. Indeed a value of '\0' (empty string) for a
tag with a string value is considered as the default value for the
attribute, and consequently is eliminated by Gas from the output object
file during the serialization.
However, readelf should be able to process correctly files of an unknown
origin that could contain those two use cases.
This patch adds the two tests mentioned above. The first one is marked
as XFAIL because the empty string is not processed correctly by readelf
when it is in the last position. The second one passes, but simply print
out "[...]" without mentioning that the NTBS is corrupted.
A following patch will fix the bug in readelf, and will amend the newly
introduced tests.
Tom de Vries [Wed, 25 Jun 2025 07:39:30 +0000 (09:39 +0200)]
[gdb/testsuite] Fix gdb.base/infcall-failure.exp on freebsd
On x86_64-freebsd with test-case gdb.base/infcall-failure.exp I get:
...
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
Address not mapped to object.
0x0000000000400522 in func_segfault () at infcall-failure.c:24
24 return *p; /* Segfault here. */
Error in testing condition for breakpoint 2:
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwind-on-signal on".
Evaluation of the expression containing the function
(func_segfault) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) FAIL: $exp: target_async=on: target_non_stop=on: \
run_cond_hits_segfault_test: continue
...
The problem is that the regexp in the test-case doesn't expect the
"Address not mapped to object." bit.
Fix this by updating the regexp.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Tested on x86_64-freebsd and x86_64-linux.
Tom de Vries [Tue, 24 Jun 2025 15:17:38 +0000 (17:17 +0200)]
[gdb/testsuite] Make gdb.dap/log-message.exp more robust
PR testsuite/31831 reports the following failure in the
gdb.dap/log-message.exp test-case (formatted for readability):
...
{ "type": "event",
"event": "output",
"body": {
"category": "stdout",
"output": "Breakpoint 1 at 0x681: file log-message.c, line 23.\n"
},
"seq": 13
}
FAIL: $exp: logging output (checking body category)
...
for a gdb 14.2 based package.
The output event listed above is a result from the setBreakpoints request.
The test-case issues the setBreakpoints request and waits for the
corresponding response, but doesn't wait for the output event, and
consequently the output event is read by:
...
dap_wait_for_event_and_check "logging output" output \
{body category} console \
{body output} "got 23 - 23 = 0"
...
which triggers the failure.
I'm not able to reproduce this, but it looks worth fixing regardless.
We're fixing this on trunk though, and the output event looks different, and
there's one more output event:
...
{ "type": "event",
"event": "output",
"body": {
"category": "stdout",
"output": "No source file named log-message.c.\n"
},
"seq": 4
}
{ "type": "event",
"event": "output",
"body": {
"category": "stdout",
"output": "Breakpoint 1 (-source log-message.c -line 23) pending.\n"
},
"seq": 5
}
...
Fix this by waiting for these two output events, making the test-case a bit
more robust.
It is possible that one or both of these output events will be read by
dap_check_request_and_response "set breakpoint", and in that case restashing
them (for which there's currently no infrastructure) would be an easy way of
handling this. But I haven't been able to trigger that, so I'm leaving that
for if and when it does.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31831
Tom Tromey [Thu, 12 Jun 2025 16:48:25 +0000 (10:48 -0600)]
Allow DAP "threads" request when inferior is running
A user pointed out that DAP allows the "threads" request to work when
the inferior is running. This is documented in the overview, not the
specification.
While looking into this, I found a few other issues:
* The _thread_name function was not marked @in_gdb_thread.
This isn't very important but is still an oversight.
* DAP requires all threads to have a name -- the field is not optional
in the "Thread" type.
* There was no test examining events resulting from the inferior
printing to stdout.
Tom Tromey [Fri, 23 May 2025 23:48:30 +0000 (17:48 -0600)]
Use "MS" for .debug_str
I changed my system linker to 'mold', but then I saw some gdb test
failures. This patch fixes a subset of the failures.
dw2-strp.exp was failing, and investigating showed that there were two
.debug_str sections. I tracked this down to the .S file not using the
correct section flags.
This patch fixes this problem, plus the other instances I could find.
(Strangely, these did not all cause problems, however.) I also
changed the DWARF assembler to always use these flags for .debug_str.
Kito Cheng [Wed, 11 Jun 2025 08:33:49 +0000 (16:33 +0800)]
RISC-V: Support for unlabeled landing pad PLT generation
This patch adds support for generating unlabeled landing pad PLT entries
for the RISC-V architecture. Unlabeled landing pad will place a LPAD
instruction at the PLT entry and PLT header, also PLT header will have
few changes due to the offset is different from the original one.
projects / thirdparty / binutils-gdb.git / log
