Xi Ruoyao [Sun, 30 Jun 2024 07:18:24 +0000 (15:18 +0800)]
LoongArch: Add DT_RELR support
The logic is same as a71d87680110 ("aarch64: Add DT_RELR support").
As LoongArch does not have -z dynamic-undefined-weak, we don't need to
consider UNDEFWEAK_NO_DYNAMIC_RELOC.
The linker relaxation adds another layer of complexity. When we delete
bytes in a section during relaxation, we need to fix up the offset in
the to-be-packed relative relocations against this section.
Xi Ruoyao [Sun, 30 Jun 2024 07:18:23 +0000 (15:18 +0800)]
LoongArch: Make protected function symbols local for -shared
On LoongArch there is no reason to treat STV_PROTECTED STT_FUNC symbols
as preemptible. See the comment above LARCH_REF_LOCAL for detailed
explanation.
"ld -shared" produces a shared object with one R_LARCH_NONE (instead of
R_LARCH_JUMP_SLOT as we expect) to relocate the GOT entry of "ifunc".
It's because the indices in .plt and .rela.plt mismatches for
STV_DEFAULT STT_IFUNC symbols when another PLT entry exists for a
STV_HIDDEN STT_IFUNC symbol, and such a mismatch breaks the logic of
loongarch_elf_finish_dynamic_symbol. Fix the issue by reordering .plt
so the indices no longer mismatch.
DYNAMIC RELOCATION RECORDS
OFFSET TYPE VALUE 00000000000001a8 R_LARCH_RELATIVE *ABS*+0x00000000000001a8
But this is just wrong: at runtime the dynamic linker will run
*(uintptr *)&x += load_address, clobbering the next 4 bytes of data
("0xdeadbeef" in the example).
If we keep the R_LARCH_32 reloc as-is in ELFCLASS64, it'll be rejected
by the Glibc dynamic linker anyway. And it does not make too much sense
to modify Glibc to support it. So we can just reject it like x86_64:
relocation R_X86_64_32 against `.data' can not be used when making a
shared object; recompile with -fPIC
or RISC-V:
relocation R_RISCV_32 against non-absolute symbol `a local symbol'
can not be used in RV64 when making a shared object
In commit dff565fcca8137954d6ad571ef39f6aec5c0429c, the fixups
for PCREL_LO12_I and PCREL_LO12_S were mixed, so the "IMM"
field were applied to incorrect position, this caused incorrect
src registers to be encoded.
RISC-V: hash with segment id and pcrel_hi address while recording pcrel_hi
When the same address across different segments (sections) needs to be
recorded, it will overwrite the slot, leading to a memory leak. To ensure
uniqueness, the segment (section) ID needs to be included in the hash key
calculation.
gas/
* config/tc-riscv.c (riscv_pcrel_hi_fixup): New "const asection *sec".
(riscv_pcrel_fixup_hash): make sec->id and e->adrsess as the
hash key.
(riscv_pcrel_fixup_eq): Check sec->id at first.
(riscv_record_pcrel_fixup): New member "sec".
(md_apply_fix) <case BFD_RELOC_RISCV_PCREL_HI20>: Likewise.
(md_apply_fix) <case BFD_RELOC_RISCV_PCREL_LO12_I>: Likewise.
Andre Vieira [Thu, 4 Jul 2024 12:45:53 +0000 (13:45 +0100)]
mve: Fix encoding for vcvt[bt] single-half float conversion instructions
The encoding was previously not taking into account that the Quad vector
registers were being encoded using their Q-register numbers rather than their
D-register equivalent (multiply by 2).
gas/
* config/tc-arm.c (do_neon_cvttb_1): Use Q-register vector number
rather than their D-register equivalent.
gas/testsuite/
* gas/arm/mve-vcvt-3.d: Correct expected values in test.
gas: Validate SFrame RA tracking and fixed RA offset
Verify all architectures participating in SFrame generation do define
the mandatory SFrame return address (RA) tracking predicate function
sframe_ra_tracking_p. Do so by explicitly not testing for the macro
SFRAME_FRE_RA_TRACKING as otherwise required.
Verify that architectures not using SFrame RA tracking specify a valid
fixed RA offset.
gas/
* gen-sframe.c (output_sframe_internal): Validate SFrame
RA tracking and fixed RA offset.
gas: Test predicate whether SFrame RA tracking is used
The existence of the macro SFRAME_FRE_RA_TRACKING only ensures the
existence of the macro SFRAME_CFA_RA_REG and the predicate function
sframe_ra_tracking_p. It does not indicate whether SFrame RA tracking
is actually used.
Test the return value of the SFrame RA tracking predicate function
sframe_ra_tracking_p to determine whether RA tracking is used.
This aligns the logic in functions get_fre_num_offsets and
output_sframe_row_entry to the one used in all other places.
gas/
* gen-sframe.c (get_fre_num_offsets, output_sframe_row_entry):
Test predicate to determine whether SFrame RA tracking is used.
gas: Don't skip SFrame FDE if .cfi_register specifies SP register
Neither ".cfi_offset SP, <offset>", ".cfi_register SP, <regno>", nor
".cfi_val_offset SP, <offset>" alter the tracking information to recover
the stack pointer (SP). Doing so would need an explicit .cfi_def_cfa,
which SFrame tracks.
The stack pointer (SP) register contents on entry can be reconstructed
from the SFrame CFA tracking information using information from the
current and initial SFrame FREs of the SFrame FDE:
1. Compute CFA from the current CFA base register (SP or FP) and CFA
offset from the SFrame CFA tracking information from the SFrame FRE
for the current instruction address:
CFA = <current_base_reg> + <current_cfa_offset>
2. Compute SP from the current CFA and the CFA offset from the SFrame
CFA tracking information from the initial SFrame FRE of the FDE:
SP = CFA - <initial_cfa_offset>
While at it add comments to the processing of .cfi_offset and
.cfi_val_offset that the SP can be reconstructed from the CFA tracking
information.
gas/
* gen-sframe.c (sframe_xlate_do_register): Do not skip SFrame
FDE if .cfi_register specifies SP register.
(sframe_xlate_do_offset,sframe_xlate_do_val_offset): Add comment
that this is likewise.
gas: Don't skip SFrame FDE if .cfi_register specifies RA w/o tracking
Do not skip SFrame FDE if .cfi_register specifies RA register without
RA tracking being actually used. Without RA tracking the register
contents can always be restored from the stack using the fixed
RA offset from CFA.
gas/
* gen-sframe.c (sframe_xlate_do_register): Do not skip SFrame
FDE if .cfi_register specifies RA register without RA tracking
being used.
CFI opcode DW_CFA_AARCH64_negate_ra_state is multiplexed with
DW_CFA_GNU_window_save. Process DW_CFA_AARCH64_negate_ra_state on
AArch64. Skip generation of SFrame FDE otherwise with the following
warning message:
skipping SFrame FDE; .cfi_window_save
gas/
* gen-sframe.c: Skip SFrame FDE if .cfi_window_save.
The SFrame format cannot represent the frame pointer (FP) being saved
on the stack without the return address (RA) also being saved on the
stack, if RA tracking is used.
A SFrame FDE is followed by 1-3 offsets with the following information:
Without RA tracking:
1. Offset from base pointer (SP or FP) to locate the CFA
2. Optional: Offset to CFA to restore the frame pointer (FP)
With RA tracking:
1. Offset from base pointer (SP or FP) to locate the CFA
2. Optional: Offset to CFA to restore the return address (RA)
3. Optional: Offset to CFA to restore the frame pointer (FP)
When RA tracking is used and a FDE is followed by two offsets the
SFrame format does not provide any information to distinguish whether
the second offset is the RA or FP offset. SFrame assumes the offset to
be the RA offset, which may be wrong.
Therefore skip generation of SFrame FDE information and print the
following warning, if RA tracking is used and the FP is saved on the
stack without the RA being saved as well:
skipping SFrame FDE; FP without RA on stack
gas/
* gen-sframe.c (sframe_do_fde): Skip SFrame FDE if FP without RA
on stack, as the SFrame format cannot represent this case.
gas: User readable warnings if SFrame FDE is not generated
The following generic warning message, which is printed whenever the
assembler skips generation of SFrame FDE, is not very helpful for the
user:
skipping SFrame FDE; CFI insn <name> (0x<hexval>)
Whenever possible print meaningful warning messages, when the assembler
skips generation of SFrame FDE:
- skipping SFrame FDE; non-SP/FP register <regno> in .cfi_def_cfa
- skipping SFrame FDE; non-SP/FP register <regno> in
.cfi_def_cfa_register
- skipping SFrame FDE; .cfi_def_cfa_offset without CFA base register
in effect
- skipping SFrame FDE; {FP|RA} register <regno> in .cfi_val_offset
- skipping SFrame FDE; {SP|FP|RA} register <regno> in in .cfi_register
- skipping SFrame FDE; .cfi_remember_state without prior SFrame FRE
state
- skipping SFrame FDE; non-default RA register <regno>
gas/
* gen-sframe.h (SFRAME_FRE_BASE_REG_INVAL): New macro for
invalid SFrame FRE CFA base register value of -1.
* gen-sframe.c: User readable warnings if SFrame FDE is not
generated.
gas/testsuite/
* gas/cfi-sframe/common-empty-1.d: Update generic SFrame test
case to updated warning message texts.
* gas/cfi-sframe/common-empty-2.d: Likewise.
* gas/cfi-sframe/common-empty-3.d: Likewise.
gas: Warn if SFrame FDE is skipped due to non-default return column
Print a warning message if SFrame FDE is skipped due to a non-default
DWARF return column (i.e. return address (RA) register number). This
may be caused by the use of CFI directive .cfi_return_column with a
non-default return address (RA) register number in the processed
assembler source code.
Warning: skipping SFrame FDE due to non-default DWARF return column
gas/
* gen-sframe.c: Warn if SFrame FDE is skipped due to non-default
DWARF return column.
gas/testsuite/
* gas/cfi-sframe/common-empty-3.d: Update test case to expect
for new warning message when SFrame FDE is skipped due to
a non-default DWARF return column.
gas: Skip SFrame FDE if CFI specifies non-FP/SP base register
Do not generate SFrame FDE if DWARF CFI directives .cfi_def_cfa or
.cfi_def_cfa_register specify a CFA base register number other than
the architecture-specific stack-pointer (SP) or frame-pointer (FP)
register numbers.
This also causes the assembler to print a warning message, so that
skipping of the SFrame FDE does not occur silently.
Update the generic ld SFrame test case to be architecture independent.
Do not use CFI directive .cfi_def_cfa, as the specified CFA base
register number is not a valid SP/FP register number on all
architectures. An invalid SP/FP register number will now cause the
assembler to print a warning message and skip SFrame FDE generation.
Remove the offending CFI directive, that cannot be coded architecture-
independent, as the test case requires SFrame information to be
generated. This was reported by the Linaro-TCWG-CI for AArch64.
gas/
* gen-sframe.c: Skip SFrame generation if CFI specifies
non-FP/SP base register.
ld/testsuite/
* ld-sframe/discard.s: Update generic SFrame test case to be
architecture independent.
gas: Print DWARF call frame insn name in SFrame warning message
SFrame generation prints the DWARF call frame instruction opcode in
hexadecimal. Leverage get_DW_CFA_name to additionally print the
DWARF call frame instruction name in human readable form, while also
respecting fake CFI types. Use "(unknown)", if the DWARF call frame
instruction name is not known.
While at it use the terminology "instruction" for these DW_CFA_*, as
suggested by Indu.
This changes the following assembler SFrame generation warning message
as follows:
Old:
Warning: skipping SFrame FDE due to DWARF CFI op 0x<hexval>
gas/
* gen-sframe.c (sframe_get_cfi_name): New function to get the
DWARF call frame instruction name for a DWARF call frame
instruction opcode.
(sframe_do_cfi_insn): Use sframe_get_cfi_name to print the
DWARF call frame instruction name for the DWARF call frame
instruction opcode in the warning message.
gas/testsuite/
* gas/cfi-sframe/common-empty-1.d: Update expected SFrame
warning message text for DWARF call frame insn name.
* gas/cfi-sframe/common-empty-2.d: Likewise.
readelf/objdump: Display SFrame fixed RA offset as 'f' in dump
For the SFrame FRE frame-pointer (FP) offset from CFA a 'u' is displayed
if it is unavailable.
For the SFrame FRE return-address (RA) offset from CFA a 'u' was
displayed if the ABI uses a fixed RA offset from CFA. By chance a
'u' was also displayed if the RA offset is unavailable, as the string
buffer was not initialized after formatting the FP offset. Note that it
could not occur that the FP offset was erroneously displayed as RA
offset, as the SFrame format cannot have a FRE with FP offset without
RA offset.
For the FRE RA offset display 'f' if the ABI uses a fixed RA offset
from CFA. Display a 'u' if it is unavailable.
libsframe/
* sframe-dump.c: Display SFrame fixed RA offset as 'f' in dump.
gas/testsuite/
* gas/cfi-sframe/cfi-sframe-common-4.d: Test for RA displayed
either as 'u' (if RA tracking) or as 'f' (fixed RA offset if no
RA tracking).
* gas/cfi-sframe/cfi-sframe-common-5.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-6.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-7.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-8.d: Likewise.
* gas/cfi-sframe/cfi-sframe-x86_64-1.d: Test for RA displayed
as 'f' (fixed RA offset), as x86-64 does not use RA tracking.
* gas/scfi/x86_64/scfi-cfi-sections-1.d: Likewise.
* gas/scfi/x86_64/scfi-dyn-stack-1.d: Likewise.
ld/testsuite/
* ld-x86-64/sframe-plt-1.d: Test for RA displayed as 'f' (fixed
RA offset), as x86-64 does not use RA tracking.
* ld-x86-64/sframe-simple-1.d: Likewise.
readelf/objdump: Dump SFrame CFA fixed FP and RA offsets
The SFrame format allows architectures to specify fixed offsets from the
CFA, if any, from which the frame pointer (FP) and/or return address
(RA) may be recovered. These offsets are stored in the SFrame header.
For instance the SFrame generation in the assembler for x86 AMD64
specifies a fixed offset from the CFA, from which the return address
(RA) may be recovered.
When dumping the SFrame header, for instance in readelf/objdump with
option --sframe, do also dump the specified fixed offsets from the CFA,
if any, from which the frame pointer (FP) and return address (RA) may
be recovered.
Update the common SFrame test case verification patterns to allow for
the optional dumping of the CFA fixed FP/RA offsets. Update the x86-
specific SFrame and SCFI test case verification patterns to require a
CFA fixed RA offset of -8.
libsframe/
* sframe-dump.c: Dump CFA fixed FP and RA offsets.
gas/testsuite/
* gas/cfi-sframe/cfi-sframe-common-1.d: Test for optional fixed
FP and RA offsets.
* gas/cfi-sframe/cfi-sframe-common-2.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-3.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-4.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-5.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-6.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-7.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-8.d: Likewise.
* gas/cfi-sframe/cfi-sframe-x86_64-1.d: Test for fixed
RA offset.
* gas/cfi-sframe/common-empty-1.d: Test for optional fixed
FP and RA offsets.
* gas/cfi-sframe/common-empty-2.d: Likewise.
* gas/cfi-sframe/common-empty-3.d: Likewise.
* gas/scfi/x86_64/scfi-cfi-sections-1.d: Test for SFrame fixed
RA offset.
* gas/scfi/x86_64/scfi-dyn-stack-1.d: Likewise.
ld/testsuite/
* ld-x86-64/sframe-plt-1.d: Test for SFrame fixed RA offset.
* ld-x86-64/sframe-simple-1.d: Likewise.
Explicitly mention "SFrame" in the descriptions for the architecture-
specific SFrame configuration macros, variables, and functions.
Use the term "frame pointer" (FP) instead of "base pointer". This aligns
with the terminology used in the SFrame specification. Additionally it
helps not to confuse "base-pointer register" with the term "BASE_REG"
used in the specification to denote either the SP or FP register.
Specify what the SFRAME_CFA_*_REG register numbers are used for:
- SP (stack pointer): CFA tracking
- FP (frame pointer): CFA and FP tracking
- RA (return address): RA tracking
Align the descriptions for definitions in the source files to the
declarations in the header files.
Tom Tromey [Tue, 2 Jul 2024 14:32:36 +0000 (08:32 -0600)]
Accept unnamed array in gdb.ada/limited-length.exp
Some compiler changes I'm working on cause a regression in
gdb.ada/limited-length.exp -- with the changes, the array type is
nameless and so is not mentioned in the max-value-size error message.
Because the array type is nameless in the source code, this seems like
an improvement to me, and so this patch changes the test to accept
either form.
Alan Modra [Sun, 30 Jun 2024 23:32:10 +0000 (09:02 +0930)]
PR31941 objcopy --globalize-symbol
I think FILE symbols are special, and I can't see why anyone would
want them to be made global. The fact that no one has reported this
bug since commit 7b4a0685e80a in 2005 supports that claim.
PR 31941
* objcopy.c (filter_symbols): Don't allow BSF_FILE symbols to
be made global.
Avoid folding new and delete pairs by adding a function call between new
and delete.
* testsuite/ld-elf/dl5.cc: Include "dl5.h".
(A): Removed.
Call foo between new and delete.
* testsuite/ld-elf/dl5.h: New file.
* testsuite/ld-elf/new.cc: Include "dl5.h".
(foo): New function.
Marcus Nilsson [Sat, 29 Jun 2024 21:01:56 +0000 (23:01 +0200)]
objcopy: Allow making symbol global and weak on same invocation
Previously objcopy had to be run twice in order to make a local symbol
weak, first once to globalize it, and once again to mark it as weak.
* objcopy.c (filter_symbols): Weaken symbols after making
local/global changes.
* testsuite/binutils-all/symbols-5.d,
* testsuite/binutils-all/symbols-5.s: New test.
The new -march=armv9.5-a flag enables access to the
mandatory cpa, lut and faminmax extensions.
Existing test cases for features are extended to verify they
work without additional flags.
Lulu Cai [Wed, 19 Jun 2024 03:00:36 +0000 (11:00 +0800)]
LoongArch: Do not check R_LARCH_SOP_PUSH_ABSOLUTE to avoid broken links to old object files
R_LARCH_SOP_PUSH_ABSOLUTE with -fPIC was heavily used in the era of gas-2.38.
We do not check this relocation to prevent broken links with old object
files.
Jan Beulich [Fri, 28 Jun 2024 06:22:39 +0000 (08:22 +0200)]
x86/APX: optimize {nf}-form IMUL-by-power-of-2 to SHL
..., for differing only in the resulting EFLAGS, which are left
untouched anyway. That's a shorter encoding, available as long as
certain constraints on operands are met; see code comments. (SHL-by-1
forms may then be subject to further optimization that was introduced
earlier.)
Note that kind of as a side effect this also converts multiplication by
1 to shift by 0, which is a plain move or even no-op anyway. That could
be further shrunk (as could be presence of shifts/rotates by 0 in the
original code as well as a fair set of other {nf}-form insns), yet the
expectation (for now) is that people won't write such code in the first
place.
Jan Beulich [Fri, 28 Jun 2024 06:21:48 +0000 (08:21 +0200)]
x86-64: restrict by-imm31 optimization
Avoid changing the encoding when there's no size gain: If there's a REX
or REX2 prefix anyway and the base opcode wouldn't be changed, dropping
just REX.W / REX2.W has no (size) effect. (Same for the AND-by-imm7 case
in the same big conditional.)
While there also pull out the .qword check: For the 2-register-operands
case whether that's done on the 1st or 2nd operand doesn't matter. Due
to reduction in necessary parentheses this improves readability a tiny
bit.
Jan Beulich [Fri, 28 Jun 2024 06:19:59 +0000 (08:19 +0200)]
x86/APX: optimize certain {nf}-form insns to LEA
..., as that leaves EFLAGS untouched anyway. That's a shorter encoding,
available as long as certain constraints on operand size and registers
are met; see code comments.
Note that this requires deferring to derive encoding_evex from {nf}
presence, as in optimize_encoding() we want to avoid touching the insns
when {evex} was also used.
Note further that this requires want_disp32() to now also consider the
opcode: We don't want to replace i.tm.mnem_off, for diagnostics to still
report the original mnemonic (or else things can get confusing). While
there, correct adjacent mis-indentation.
Unlike for the legacy forms, where there's a difference in the resulting
EFLAGS.CF, for the NF variants the immediate can be got rid of in that
case by switching to a 1-bit rotate in the opposite direction.
Jan Beulich [Fri, 28 Jun 2024 06:18:40 +0000 (08:18 +0200)]
x86/APX: optimize {nf} forms of ADD/SUB with specific immediates
Unlike for the legacy forms, where there's a difference in the resulting
EFLAGS, for the NF variants we can safely replace ones using 0x80 by the
respectively other insn while negating the immediate, saving 3 immediate
bytes (just 1 though for 16-bit operand size). Similarly we can replace
ones using 1 / -1 by INC/DEC (eliminating the immediate).
Jan Beulich [Fri, 28 Jun 2024 06:17:41 +0000 (08:17 +0200)]
gas: .irp/.irpc are macro-like
... for the purposes of get_line_sb() and _find_end_of_line(): They
support \@ just like macros do, and hence the special casing there also
needs applying.
Nelson Chu [Thu, 27 Jun 2024 04:27:33 +0000 (12:27 +0800)]
RISC-V: Shrink the riscv_implicit_subsets table.
Allow to add implicit extensions by using the syntax of `.option arch, +-', so
that the table is shrinked and more readable.
bfd/
* elfxx-riscv.c (check_implicit_always): Removed the unused IMPLICIT
parameter.
(check_implicit_for_i): Likewise.
(riscv_implicit_subsets): Shrink the table by allowing the syntax of
`.option arch, +-' for implicit extensions.
(riscv_update_subset1): New function, called from riscv_update_subset
or riscv_parse_add_implicit_subsets. It basically does the same thing
as riscv_update_subset function before.
(riscv_parse_add_implicit_subsets): Updated.
(riscv_update_subset): Updated.
Nelson Chu [Tue, 11 Jun 2024 08:35:58 +0000 (16:35 +0800)]
RISC-V: PR27180, Update relocation for riscv_zero_pcrel_hi_reloc.
When pcrel access overflow, the riscv_zero_pcrel_hi_reloc may convert pcrel
relocation to absolutly access if possible at the relocate stage. We used to
encode the target address into r_sym of R_RISCV_HI20 if it is converted from
R_RISCV_PCREL_HI20. But that may cause segfault if --emit-relocs is set,
since r_sym becomes an address rather than a symbol index. Although the
relocate result is correct, it does not meet the definition, so may cause
unexpected behaviors.
This patch encodes the target address into r_addend, rather than r_sym, if
riscv_zero_pcrel_hi_reloc converts the relocation. Besdies, since the
corresponding pcrel_lo relocation are also changed to absolutly access,
we should also update them to R_RISCV_LO12_I/S.
bfd/
PR 27180
* elfnn-riscv.c (riscv_pcrel_hi_reloc): New boolean `absolute', to
inform corresponding pcrel_lo that the pcrel_hi relocation was already
converted to hi20 relocation.
(riscv_record_pcrel_hi_reloc): Likewise, record `absolute'.
(riscv_pcrel_lo_reloc): Removed `const' for Elf_Internal_Rela *reloc,
since we may need to convert it from pcrel_lo to lo relocation.
(riscv_record_pcrel_lo_reloc): Likewise. Convert pcrel_lo to lo
relocation if corresponding pcrel_hi was converted to hi relocation.
(riscv_zero_pcrel_hi_reloc): Encode target absolute address into
r_addend rather than r_sym. Clear the `addr' to avoid duplicate
relocate in the perform_relocation.
(riscv_elf_relocate_section): Updated.
ld/
PR 27180
* testsuite/ld-riscv-elf/pcrel-lo-addend-3a-emit-relocs.d: New testcase.
Segfault without applying this patch.
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
H.J. Lu [Tue, 25 Jun 2024 07:45:22 +0000 (00:45 -0700)]
Set BFD_DECOMPRESS when reading build-id debuglink
We should set BFD_DECOMPRESS to decompress sections unless dumping the
section contents when reading build-id debuglink.
PR binutils/31925
* objdump.c (open_debug_file): Set BFD_DECOMPRESS to decompress
sections unless dumping the section contents.
* testsuite/binutils-all/objdump.exp (test_build_id_debuglink):
Add a compress option.
Run test_build_id_debuglink with none and zlib.
Andrew Burgess [Wed, 19 Jun 2024 10:13:14 +0000 (11:13 +0100)]
gdb: add overloads of gdb_tilde_expand
Like the previous commit, add two overloads of gdb_tilde_expand, one
takes std::string and other takes gdb::unique_xmalloc_ptr<char>. Make
use of these overloads throughout GDB and gdbserver.
There should be no user visible changes after this commit.
Andrew Burgess [Wed, 19 Jun 2024 10:12:28 +0000 (11:12 +0100)]
gdb: add overloads of gdb_abspath
Add two overloads of gdb_abspath, one which takes std::string and one
which takes gdb::unique_xmalloc_ptr<char>, then make use of these
overloads throughout GDB and gdbserver.
There should be no user visible changes after this commit.
Alan Modra [Thu, 27 Jun 2024 03:01:46 +0000 (12:31 +0930)]
Re: Rewrite SHT_GROUP handling
There is no need to loop over the headers twice. Remove that leftover
from the previous scheme. Also, the previous scheme silently ignored
a section being mentioned in two or more SHT_GROUP sections.
* elf.c (process_sht_group_entries): Prevent sections from
belonging to two groups.
(_bfd_elf_setup_sections): Process groups in a single loop
over headers.
Alan Modra [Wed, 26 Jun 2024 08:17:21 +0000 (17:47 +0930)]
Rewrite SHT_GROUP handling
This patch delays setting up elf_next_in_group, elf_sec_group and
elf_group_name when reading ELF object files until after all ELF
sections have been processed by bfd_section_from_shdr. This is simpler
and more robust than the current scheme of driving the whole process
on detecting a section with SHF_GROUP set.
* elf-bfd.h (struct elf_obj_tdata): Delete group_sect_ptr,
num_group and group_search_offset.
* elf.c (Elf_Internal_Group): Delete.
(setup_group): Delete function.
(IS_VALID_GROUP_SECTION_HEADER): Delete macro.
(is_valid_group_section_header),
(process_sht_group_entries): New functions.
(_bfd_elf_setup_sections): Handle group sections here..
(_bfd_elf_make_section_from_shdr): ..rather than here.
(bfd_section_from_shdr): Don't check SHT_GROUP validity here.
Tom de Vries [Wed, 26 Jun 2024 06:49:40 +0000 (08:49 +0200)]
[gdb/testsuite] Fix timeout in gdb.base/bg-execution-repeat.exp
I ran into the following test failure with test-case
gdb.base/bg-execution-repeat.exp:
...
(gdb) PASS: gdb.base/bg-execution-repeat.exp: c&: repeat bg command
^M
Breakpoint 2, foo () at bg-execution-repeat.c:23^M
23 return 0; /* set break here */^M
print 1^M
$1 = 1^M
(gdb) PASS: gdb.base/bg-execution-repeat.exp: c&: input still accepted
FAIL: gdb.base/bg-execution-repeat.exp: c&: breakpoint hit 2 (timeout)
...
The failure can be easily reproduced by adding a sleep 5 here:
...
+ sleep 5
gdb_test "print 1" " = 1" "input still accepted"
...
There's a race in the test-case, between:
- the command handled in the foreground: the "print 1" command, and
- the command handled in the background: the continue command.
The current way of dealing with this is by putting the inferior to sleep for 5
seconds:
...
foo ();
sleep (5);
foo ();
...
with the aim that the "print 1" command will win the race.
This method is both slow and unreliable.
Fix this by making the inferior wait till the "print 1" command is done.
This reduces running time from ~11s to ~1s.
I also verified that the test-case still triggers on the original problem by
applying this gdb/infcmd.c patch:
...
-strip_bg_char (const char *args, int *bg_char_p)
+strip_bg_char (const char *_args, int *bg_char_p)
{
- const char *p;
+ char *args = const_cast<char *>(_args);
+ char *p;
Indu Bhagat [Wed, 26 Jun 2024 05:27:12 +0000 (22:27 -0700)]
doc: sframe: small improvements for readability
Update some of the content to make the specification document hopefully
clearer:
- Fix some typos.
- Use Title case consistently for headings.
- Update text around detection of foreign endianness.
- Split the structure field "Name" in each table to two separate
colunms for additional attention: "Type" and "Name".
- Rename "SFrame endianness" section to "SFrame magic number and
endianness"
- Update text around provisions for extending SFrame for future
ABIs/architectures. Make it clear by tagging all provisions with an
explicit index item "Provisions for future ABIs".
- Add a paragraph on sort order of SFrame FDEs.
- Add a statement for SFRAME_F_FRAME_POINTER flag.
- Add a statement to assert that SFrame version 1 is now obsolete and
should not be used.
libsframe/
* doc/sframe-spec.texi: Small improvements for readability.
aarch64: FP8 scale and convert - Implement minor improvements
Following feedback received shortly after the initial commit of the
aarch64 instructions for scaling and converting fp8 instructions, this
patch addresses the issues raised in the relevant feedback.
This includes the following changes:
* Standardize all FP8 qualifier-set names. This has resulted in the
renaming of QL_V2FP8B8H to QL_V2_HB_LOWER and, likewise, QL_V28H16B
to QL_V2_HB_FULL.
* Update `FP8_INSN' aarch64_opcode_table[] entries to reflect the new
standardized qualifier-set names mentioned above and, in the case of
the "fcvtn" entries, also add a leading 0 to their opcode values so
they are given as 8 hexadecimal digits in length to ensure
consistency in formatting relative to other entries in the table.
* Revise the added test-cases so that when checking operand fields in
the disassembled binaries, all bits for these fields get tested to
ensure they can be toggled on/off by the relevant operand arguments.
Flavio Cruz [Wed, 7 Feb 2024 06:53:40 +0000 (01:53 -0500)]
Hurd port: update interface to match upstream and fix warnings.
We have recently updated the interface for raising exceptions to use
long [1] and updated mach_port_t to be "unsigned int". This patches fixes
those problems and will help us port GDB to Hurd x86_64.
Jens Remus [Tue, 25 Jun 2024 15:25:55 +0000 (17:25 +0200)]
aarch64: Treat operand ADDR_SIMPLE as address with base register
The AArch64 instruction table (aarch64-tbl.h) defines the operand
ADDR_SIMPLE as "address with base register (no offset)". During assembly
it is correctly encoded as address with base register (addr.base_regno)
in parse_operands. In warn_unpredictable_ldst it is erroneously treated
as register number (reg.regno).
This resolves the assembler test case "Diagnostics Quality" to
erroneously fail when changing the union in struct aarch64_opnd_info
from union to struct for debugging purposes.
gas/
* config/tc-aarch64.c: Treat operand ADDR_SIMPLE as address with
base register.
Jens Remus [Tue, 25 Jun 2024 15:25:55 +0000 (17:25 +0200)]
aarch64: Treat operand Rt_IN_SYS_ALIASES as register number (PR 31919)
The AArch64 instruction table (aarch64-tbl.h) defines the operand
Rt_IN_SYS_ALIASES as register number. During assembly it is correctly
encoded as register number (reg.regno) in parse_operands. During
disassembly it is first correctly decoded as register number (reg.regno)
in aarch64_ext_regno called by aarch64_extract_operand, but then
erroneously treated as immediate value (imm.value) in
aarch64_print_operand.
This resolves the assembler test case "gas/aarch64/brbe-brb-inst" to
erroneously fail on s390. On AArch64 - being little-endian - the struct
aarch64_opnd_info union fields reg.regno and imm.value share their
least-significant bits. On s390 - being big-endian - they do not.
Andrew Burgess [Mon, 24 Jun 2024 11:22:26 +0000 (12:22 +0100)]
gdb/doc: the all-doc build target should build .... all docs
I noticed that the 'all-doc' build target doesn't build all the doc
formats, 'man' and 'html' are missing.
This commit updates 'all-doc' so that all formats are built.
This doesn't change the default 'all' target, which is the default
target used when building GDB itself, the 'all' target continues to
just build the 'info' docs.
There should be no difference in the actual generated output after
this commit, I'm just changing what gets built.
When building the dvi or pdf targets you'd get errors like this:
mkdir: cannot create directory ‘texi2dvi_tmpdir/gdb_dvi’: No such file or directory
mkdir: cannot create directory ‘texi2dvi_tmpdir/gdb_pdf’: No such file or directory
fixed by ensuring the directory is created before calling texi2dvi.
This patch adds missing contraints to FEAT_B16B16 sve2 instructions
bfclamp, bfmla and bfmls and add negative tests for all the bfloat
instructions.
The bfloat16-invalid.* testcases are renamed to bfloat16-1-invalid.*
to maintain consistency in the testsuite.
The bfloat16-1-invalid.* tests are modified so that "selected
processor does not support" is generated by the assembler, since
+b16b16 is not passed in the command line.
The bfloat16-2-invalid.* testcase includes the wrong operands
bfloat16 tests.
aarch64: Add extra tests for sve2p1 min max instructions.
This patch adds some extra tests for the sve2p1 "addqv, andqv, smaxqv,
sminqv, umaxqv, uminqv, eorqv, faddqv, fmaxnmqv, fmaxqv, fminnmqv and
fminqv" instructions.
The patch also adds couple of negative testcases, sve2p1-1-bad.d testcase
without "+sve2p1" option and sve2p1-2-bad.d testcase with wrong operands
for sve2p1 instructions.
arch64: Fix the wrong constraint used for sve2p1 instructions.
The current implementation for the following SVE2p1 instructions add a
constraint in aarch64_opcode_table[] array, so that these instruction
might be immediately preceded in program order by a MOVPRFX instruction.
As per the spec these instruction does not immediately preceded in
program order by a MOVPRFX instruction and to fix this issue, SVE2p1_INSNC
macro is replaced with SVE2p1_INSN macro for the entries of these
instructions in aarch64_opcode_table[] array.
List of instructions updated: addqv, andqv, smaxqv, sminqv, umaxqv, uminqv,
eorqv, faddqv, fmaxnmqv, fmaxqv, fminnmqv and fminqv.
This patch fixes encoding and syntax for sve2p1 instructions ld[1-4]q/st[1-4]q
as mentioned below, for the issues reported here.
https://sourceware.org/pipermail/binutils/2024-February/132408.html
1) Previously all the ld[1-4]q/st[1-4]q instructions are wrongly added as
predicated instructions and this issue is fixed in this patch by replacing
"SVE2p1_INSNC" with "SVE2p1_INSN" macro.
2) Wrong first operand in all the ld[1-4]q/st[1-4]q instructions is fixed
by replacing "SVE_Zt" with "SVE_ZtxN".
3) Wrong operand qualifiers in ld1q and st1q instructions are also fixed in
this patch.
4) In ld1q/st1q the index in the second argument is optional and if index
is xzr and is skipped in the assembly, the index field is ignored by the
disassembler.
Fixing above mentioned issues helps with following:
1) ld1q and st1q first register operand accepts enclosed figure braces.
2) ld2q, ld3q, ld4q, st2q, st3q, and st4q instructions accepts wrapping
sequence of vector registers.
For the instructions ld[2-4]q/st[2-4]q, tests for wrapping sequence of vector
registers are added along with short-form of operands for non-wrapping sequence.
I have added test using following logic:
ld2q {Z0.Q, Z1.Q}, p0/Z, [x0, #0, MUL VL] //raw insn encoding (all zeroes)
ld2q {Z31.Q, Z0.Q}, p0/Z, [x0, #0, MUL VL] // encoding of <Zt1>
ld2q {Z0.Q, Z1.Q}, p7/Z, [x0, #0, MUL VL] // encoding of <Pg>
ld2q {Z0.Q, Z1.Q}, p0/Z, [x30, #0, MUL VL] // encoding of <Xm>
ld2q {Z0.Q, Z1.Q}, p0/Z, [x0, #-16, MUL VL] // encoding of <imm> (low value)
ld2q {Z0.Q, Z1.Q}, p0/Z, [x0, #14, MUL VL] // encoding of <imm> (high value)
ld2q {Z31.Q, Z0.Q}, p7/Z, [x30, #-16, MUL VL] // encoding of all fields (all ones)
ld2q {Z30.Q, Z31.Q}, p1/Z, [x3, #-2, MUL VL] // random encoding.
For all the above form of instructions the hyphenated form is preferred for
disassembly if there are more than two registers in the list, and the register
numbers are monotonically increasing in increments of one.
This patch fixes the syntax of sve2p1 "extq" instruction by modifying the operands
count to 4. A new operand AARCH64_OPND_SVE_UIMM4 is defined to handle the 4th
argument an 4-bit unsigned immediate of extq instruction. The instruction encoding
is updated to use constraint C_SCAN_MOVPRFX, to enable "extq" instruction to immediately
precede in program order by a MOVPRFX instruction. Also removed the unused operand
AARCH64_OPND_SVE_Zm_imm4.
This issues was reported here:
https://sourceware.org/pipermail/binutils/2024-February/132408.html
This patch fixes the syntax of sve2p1 "dupq" instruction by modifying the way
2nd operand does the encoding and decoding using the [<imm>] value.
dupq makes use of already existing aarch64_ins_sve_index and aarch64_ext_sve_index
inserter and extractor functions. The definitions of aarch64_ins_sve_index_imm (inserter)
and aarch64_ext_sve_index_imm (extractor) is removed in this patch.
This issues was reported here:
https://sourceware.org/pipermail/binutils/2024-February/132408.html
gdb: use alternative for demangled name for non-demangeable linkage names
In case a DIE contains a linkage name which cannot be demangled and
a source language name (DW_AT_NAME) exists then we want to display this name
instead of the non-demangeable linkage name.
dwarf2_physname returns the linkage name in case the linkage name
cannot be demangled. Before this patch we always set the returned physname
as demangled name. This patch changes this by comparing the value
of physname with the linkage name. Now after this change in case it is equals
to the linkage name and if DW_AT_NAME exists then this is set as the demangled
name otherwise like before still linkage name is used.
For the reproducer, using the test source file added in this change:
"gdb/testsuite/gdb.dwarf2/dw2-wrong-mangled-name.c"
Here is an example of the DWARF where wrong linkage name is emitted by the
compiler for the "func_demangled_test" function:
Before this change for a function having both DIEs DW_AT_name and
DW_AT_LINKAGENAME but with the wrong linkage name info, the backtrace
command shows following:
(gdb) b func_demangled_test
(gdb) r
Breakpoint 1, 0x0000555555555131 in _FUNC_WRONG_MANGLED__ ()
(gdb) backtrace
\#0 0x0000555555555131 in _FUNC_WRONG_MANGLED__ ()
\#1 0x000055555555514a in main ()
After the change now GDB shows the name emitted by DW_AT_NAME:
(gdb) b func_demangled_test
(gdb) r
Breakpoint 1, 0x0000555555555131 in func_demangled_test ()
(gdb) backtrace
\#0 0x0000555555555131 in func_demangled_test ()
\#1 0x000055555555514a in main ()
Hui Li [Tue, 11 Jun 2024 11:21:26 +0000 (19:21 +0800)]
gdb: LoongArch: Add support for hardware breakpoint
LoongArch defines hardware watchpoint functions for fetch operations.
After the software configures the watchpoints for fetch, the processor
hardware will monitor the access addresses of the fetch operations and
trigger a watchpoint exception when the watchpoint setting conditions
are met.
Hardware watchpoints for fetch operations is used to implement hardware
breakpoint function on LoongArch. Refer to the following document for
hardware breakpoint.
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints
A simple test is as follows:
lihui@bogon:~$ cat test.c
#include <stdio.h>
int a = 0;
int main()
{
printf("start test\n");
a = 1;
printf("a = %d\n", a);
printf("end test\n");
return 0;
}
lihui@bogon:~$ gcc -g test.c -o test
without this patch:
lihui@bogon:~$ gdb test
...
(gdb) start
...
Temporary breakpoint 1, main () at test.c:5
5 printf("start test\n");
(gdb) hbreak 8
No hardware breakpoint support in the target.
with this patch:
lihui@bogon:~$ gdb test
...
(gdb) start
...
Temporary breakpoint 1, main () at test.c:5
5 printf("start test\n");
(gdb) hbreak 8
Hardware assisted breakpoint 2 at 0x1200006ec: file test.c, line 8.
(gdb) c
Continuing.
start test
a = 1
Breakpoint 2, main () at test.c:8
8 printf("end test\n");
(gdb) c
Continuing.
end test
[Inferior 1 (process 25378) exited normally]
Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
projects / thirdparty / binutils-gdb.git / log
