I noticed a typo in the testsuite, twice: gdbsever. Fix these.
Codespell doesn't detect it, so add a new file
gdb/contrib/codespell-dictionary.txt that contains a gdbsever->gdbserver
entry, and update gdb/contrib/setup.cfg to use it.
Approved-By: Tom Tromey <tom@tromey.com>
The following gdb/testsuite subdirs are codespell-clean:
...
$ for d in gdb/testsuite/gdb.*; do \
echo -n "$d:"; \
codespell --config ./gdb/contrib/setup.cfg $d \
| wc -l; \
done 2>&1 \
| grep :0
gdb/testsuite/gdb.ctf:0
gdb/testsuite/gdb.dap:0
gdb/testsuite/gdb.gdb:0
gdb/testsuite/gdb.go:0
gdb/testsuite/gdb.modula2:0
gdb/testsuite/gdb.objc:0
gdb/testsuite/gdb.opencl:0
gdb/testsuite/gdb.perf:0
gdb/testsuite/gdb.replay:0
gdb/testsuite/gdb.server:0
gdb/testsuite/gdb.testsuite:0
...
Add them to the pre-commit configuration.
Approved-By: Tom Tromey <tom@tromey.com>
Import the following commits from GCC as of r16-614-g9d039eff453f77:
31dd621796f libiberty: add ldirname function
f3d07779fdb libiberty: Append <libgen.h> to AC_CHECK_DECLS [PR119218].
90183362524 libiberty, gcc: Add memrchr to libiberty and use it [PR119283].
43717ee9064 libiberty: Fix off-by-one when collecting range expression
An oss-fuzz testcase found:
runtime error: shift exponent 140 is too large for 32-bit type 'int'
OK, that's just a completely silly uleb, but we ought to be able to
handle 64 bits here.
* elfxx-loongarch.c (loongarch_elf_add_sub_reloc_uleb128): Formatting.
Don't left shift int. Avoid shifts larger than bits in a bfd_vma.
Simulator testsuite build started failing with host GCC-15:
bits-tst.c:323:1: error: function declaration isn’t a prototype [-Werror=strict-prototypes]
bits-tst.c: In function ‘main’:
bits-tst.c:323:1: error: old-style function definition [-Werror=old-style-definition]
Fix by including string.h to get the required prototypes, and changing
main's declaration to modern C.
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
Approved-By: Tom Tromey <tom@tromey.com>
Silence ubsan warning. We don't worry about wrap-around in most
places that adjust abs_section_offset, so don't fuss over an overflow
in the multiplication here.
* read.c (s_fill): Replace "long" vars with offsetT and valueT.
Avoid signed overflow calculating abs_section_offset.
T-Head/XuanTie's vector extension documentation states that their vector
extensions are based on the standard vector extension draft,
version 0.7.1.
In that draft, it is rare to see dependencies between extensions as
in the ratified version ... except: "Zvamo" -> "Zaamo".
cf. <https://github.com/riscvarchive/riscv-v-spec/releases/tag/0.7.1>
> If vector AMO instructions are supported, then the scalar Zaamo
> instructions (atomic operations from the standard A extension)
> must be present.
Note that using the words like "imply" or "depend" for extensions
weren't a common practice to represent dependencies between extensions
at the time the documentation was created.
The "Zaamo" was not ratified as an extension at the time but this is a
subset of the "A" extension and defines scalar AMO operations (while
"Zvamo" -- NOT in the ratified specification -- defines vector AMO ops).
The important part is that the T-Head/XuanTie's documentation just
states that the "Zvamo" (draft) extension is renamed to "XTheadZvamo".
It means, this implication should have been preserved in some way.
> The extension Zvamo is renamed to XTheadZvamo.
cf. <https://github.com/XUANTIE-RV/thead-extension-spec/blob/2.3.0/xtheadvector.adoc>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_implicit_subsets): Add implication
"XTheadZvamo" -> "Zaamo".
gas/ChangeLog:
* testsuite/gas/riscv/imply.s: Add "XTheadZvamo" implication.
* testsuite/gas/riscv/imply.d: Ditto.
While this dependency is not directly stated in the documentation,
the XTheadVector extension cannot work without the Zicsr extension
(the documentation does not specify CSR access instruction subset
either as in the Zkr extension or the seed CSR section in the manual).
Also, making an implication to the Zicsr extension is in parity with
the ratified vector extensions (in GNU Binutils, the Zve32x extension --
a dependency of V -- depends on the Zvl32b and Zicsr extensions).
This commit adds this implicit dependency.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_implicit_subsets): Add implicit
dependency "XTheadVector" -> "Zicsr".
gas/ChangeLog:
* testsuite/gas/riscv/imply.s: Add implicit "XTheadVector"
dependency to the "Zicsr" extension.
* testsuite/gas/riscv/imply.d: Ditto.
T-Head/XuanTie's "XTheadVector" is based on a draft version of the now
standard vector extensions and it conflicts with not just the "V"
extension but all of its subsets.
This commit makes "XTheadVector" conflict with the "Zve32x" extension,
which is the smallest subset of the standard vector extensions. Still,
a reference to "V" is preserved in the error message
as the documentation suggests:
> Therefore, the XTheadVector extension and the V extension are
> in conflict.
cf. <https://github.com/XUANTIE-RV/thead-extension-spec/blob/2.3.0/xtheadvector.adoc>
Note that, instructions in the "XTHeadZvamo" extension currently has
no conflicts with other extensions, even after addition of the "Zabha"
extension.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_parse_check_conflicts):
Make "XTheadVector" conflict with not just "V" but its subsets.
gas/ChangeLog:
* testsuite/gas/riscv/x-thead-vector-fail.d: Test a vector
subset "Zve32x" to test failures.
* testsuite/gas/riscv/x-thead-vector-fail.l: Reflect change
in the error message.
Simplify the test whether a symbol is absolute, by using the helper
bfd_is_abs_symbol.
bfd/
* elf64-s390.c (elf_s390_relocate_section): Use
bfd_is_abs_symbol to test whether symbol is absolute.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Dereferences of GOT slots with lgrl or lg for global symbols are
rewritten to larl to get get rid of the extra memory access. However
this is invalid for:
- symbols marked for absolute addressing
- symbols at odd addresses (larl can handle only even addresses)
Commit e6213e09ed ("S/390: Prevent GOT access rewrite for certain
symbols") added checks for the above. But instead of checking the
address of a symbol for being halfword aligned, it tries to deduce
this from whether the symbol value and section the symbol is defined
in are halfword aligned. The way it is done has two issues:
1. The use of bfd_section_from_elf_index to obtain the section the
symbol is defined in may not return the one that remains in the
output. For instance for COMDAT sections getting deduplicated
the section retrieved using bfd_section_from_elf_index may not be
the same as h->root.u.def.section. If COMDAT sections of same
group signature have different alignment properties the wrong
one may be checked. This may then lead to an erroneous rewrite
of lgrl %rX, sym@GOTENT to larl %rX, sym, although the symbol in
the remaining section is not properly aligned, triggering an
"relocation for misaligned symbol" error at link-time.
This may for instance occur when mixing C++ modules compiled with
GCC and Clang, as GCC emits a 2-byte alignment and Clang a 1-byte
alignment for COMDAT sections containing type information:
$ cat sample.cpp
#include <typeinfo>
struct A {};
const std::type_info &q() { return typeid(A); }
$ g++ -c sample.cpp -o sample_gcc.o
$ clang++ -c sample.cpp -o sample_clang.o
$ readelf -WS sample_gcc.o sample_clang.o
Produces (reformatted and reduced):
File Name Off Size ES Flg Lk Inf Al
sample_gcc.o .rodata._ZTS1A 000080 000004 00 AG 0 0 2
sample_clang.o .rodata._ZTS1A 000058 000003 00 AG 0 0 1
2. The symbol may end up at an even address, if both the symbol value
and the section defining the symbol are 1-byte aligned. While this
does not trigger an error, it fails an opportunity to rewrite a GOT
access.
In a Linux Kernel build this causes ~15k GOT accesses using lgrl to
be skipped to be rewritten to larl.
Resolve both issues by simply checking whether the symbol address is
halfword aligned. Do not check the symbol value nor section defining
the symbol for halfword alignment.
bfd/
PR ld/32969
* elf64-s390.c (elf_s390_relocate_section): Only rewrite
lgrl/lg from GOT to larl if symbol address is halfword aligned.
ld/testsuite/
PR ld/32969
* ld-s390/s390.exp (pr32969_64-1, pr32969_64-2): Add tests for
rewrite of GOT access when COMDAT section deduplication is
involved.
* ld-s390/pr32969_64-1.dd: New test for rewrite of GOT access
when COMDAT section deduplication is involved.
* ld-s390/pr32969_64-2.dd: Likewise.
* ld-s390/pr32969a.s: Likewise.
* ld-s390/pr32969b.s: Likewise.
* ld-s390/pr32969c.s: Likewise.
Bug: https://sourceware.org/PR32969
Fixes: e6213e09ed ("S/390: Prevent GOT access rewrite for certain symbols")
Reported-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Report the BFD in which a misaligned symbol is defined in the error
message. This complements commit 906f69cf65 ("IBM zSystems: Issue
error for *DBL relocs on misaligned symbols"). While at it reword
the error message.
Old error message text (re-wrapped):
<sec-bfd>(<sec>+<off>): misaligned symbol `<sym>' (<addr>) for
relocation <rel>
New error message text (re-wrapped):
<sec-bfd>(<sec>+<off>): relocation <rel> against misaligned symbol
`<sym>' (<addr>) in <sym-bfd>
Note that the linker tests do not require to be updated, as they match
against the pattern ".*misaligned symbol.*", which has not changed in
the error message.
bfd/
PR ld/32969
* elf64-s390.c (elf_s390_relocate_section): Report BFD
in which a misaligned symbol is defined in error message.
Bug: https://sourceware.org/PR32969
Suggested-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Fix PR gas/32952 - sframe: incorrect handling of .cfi_undefined in gas
In context of SFrame generation, it is incorrect to simply ignore all
.cfi_undefined. We may ignore only those .cfi_undefined which are for
registers of no interest (similar to whats done for other CFI
directives).
gas/
* gen-sframe.c (sframe_xlate_do_cfi_undefined): New definition.
(sframe_do_cfi_insn): Handle .cfi_undefined.
gas/testsuite/
* gas/cfi-sframe/cfi-sframe.exp: Add new tests.
* gas/cfi-sframe/cfi-sframe-common-10.d: New test.
* gas/cfi-sframe/cfi-sframe-common-10.s: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-4.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-4.s: New test.
The current warning text of "skipping SFrame FDE" does not unabiguously
indicate that the SFrame FDE is not generated in the output section.
Reword the diagnostic to say "no SFrame FDE emitted" as requested.
Adjust the testcases for the updated warning.
To process some CFI directives like .cfi_undefined and .cfi_same_value,
it is necessary for correctness to detect all cases when the register
used is one of SP, FP or RA.
Currently, the backends needed to specify the SFRAME_CFA_RA_REG only in
the case of those ABIs where RA tracking was necessary, e.g. AArch64.
For AMD64, since the return address is always at a fixed offset from the
CFA, RA tracking was disabled.
The backends must now specify the applicable return address register via
SFRAME_CFA_RA_REG. This is necessary so that SFrame generation code can
then properly handle the cases when RA is used like so:
.cfi_undefined <RA>
or,
.cfi_same_value <RA>
Detecting these cases is necessary for correctness. E.g., on AMD64, we
need to skip FDE generation as the above constructs cannot be
represented in SFrame yet.
This change is a prerequisite to fixing the two PRs:
PR gas/32952 - sframe: incorrect handling of .cfi_undefined in gas
PR gas/32953 - sframe: incorrect handling of .cfi_same_value in gas
In the SFrame generation code in gen-sframe.c, instead of using
SFRAME_FRE_RA_TRACKING ifdef's, we now simply rely on the API
sframe_ra_tracking_p () to detect if RA-tracking is enabled for the
target.
While at it, use const variables for x86 backend.
ChangeLog:
* gas/config/tc-i386.c (x86_sframe_cfa_ra_reg): New definition.
* gas/config/tc-i386.h (REG_RA): New definition.
(SFRAME_CFA_RA_REG): New declaration.
* gas/gen-sframe.c (SFRAME_FRE_RA_TRACKING): Remove.
At the moment we allow alignment of up to half the address space,
which is stupidly large and results in OOM on x86_64. Change that to
1G alignment in text sections. Also fix the warning message on
exceeding max allowed alignment.
* read.c (TC_ALIGN_LIMIT): Limit to 30 in text sections.
(s_align): Correct "alignment too large" value.
In 344b1e0f5f ("gas: range-check 3rd argument of .align et al") I
neglected to consider compilers which warn about signed/unsigned
mismatches in comparisons (which is somewhat odd when the signed value is
already known to be non-negative).
Negative values would have been silently converted to large positive
ones, which may not be the user's intention. Similarly overly large
values would have been silently truncated. Warn them instead, and zap
such values.
Texinfo 7.2 began showing warnings like:
ld.texi:1026: warning: do not set .info suffix in reference for manual `gcc.info'
ld.texi:9689: warning: do not set .info suffix in reference for manual `binutils.info'
The Texinfo developers plan to stop removing the '.info' suffix
internally in a future release so without this patch the references will
break in the future.
Signed-off-by: Collin Funk <collin.funk1@gmail.com>
Texinfo 7.2 began showing warnings like:
binutils.texi:882: warning: do not set .info suffix in reference for manual `ld.info'
binutils.texi:1365: warning: do not set .info suffix in reference for manual `ld.info'
The Texinfo developers plan to stop removing the '.info' suffix
internally in a future release so without this patch the references will
break in the future.
Signed-off-by: Collin Funk <collin.funk1@gmail.com>
Diagnosing operand size vs operand type mismatches doesn't work very
well when GPRs and FPRs are in the same register class, distinguished
just by size. Introduce a separate RegFP class.
Anysize is applicable to memory operands only. Move the check to where
memory operands are handled. (The RegSIMD part there was questionable
altogether.)
In templates, the expectation of an "accumulator" register to be used is
expressed solely by operand size; there's no "class" specifier there.
Hence operand_size_match() is too eager in invoking
match_{operand,simd}_size(), resulting in "operand size mismatch" errors
when it's the type (of register), not the size that's wrong.
Interestingly adjustments there alone lead to no error at all then: To
"compensate", operand_type_match() needs to disambiguate register types
when register instances are specified in the template (matching the
actual operand), by checking a match (overlap) in operand sizes.
There's little point invoking match_{operand,simd}_size() twice per
loop; in fact the SIMD case with D set simply doesn't exist. Amend the
checks by one looking at the given operand, just like we already have
been doing for memory ones.
Many times in the past I was puzzled by seeing "operand size mismatch"
when really "operand type mismatch" would be far more appropriate. As it
turns out, there were at least two flaws: In the single operand case we
didn't propagate i.error to match_template()'s local specific_error when
noticing a type mismatch. And then operand_size_match() was too eager in
invoking match_mem_size(): Especially the Unspecified attribute can get
in the way there when the expected operand isn't a memory one (and hence
Unspecified would not be set in the operand template, whereas it's
uniformly set for memory operands in AT&T syntax).
(In the x86-64-lkgs-inval testcase the particular error for the two
bogus Intel syntax forms doesn't really matter; all we ought to care
about there isthat there is _some_ error.)
Accum is an "instance", not a "class". With present enumerator values of
Reg and Accum, the 2nd check simply did the same as the first. In fact
checking for the accumulator (%rax) isn't necessary here at all, because
there's no case where an individual template would permit alternatively
a memory operand or the (qword) accumulator; only "any GPR" is ever
being paired with "memory".
The assembler partially relied on the linker to check whether the
offset is valid. However, some optimization logic (added later)
removes relocations relative to local symbols without checking offsets.
For instance, it caused following code to silently emit wrong jumps
(to the jump instruction "." itself) without relocations:
> .option norelax
> j .+0x200000 # J (or JAL) instruction cannot encode this offset.
> j .+1 # Jump to odd address is not valid.
This commit adds offset checks where necessary.
gas/ChangeLog:
* config/tc-riscv.c (md_apply_fix): Check offsets when the
relocation relative to a local symbol is being optimized out.
* testsuite/gas/riscv/no-relax-branch-offset-fail.s: Failure
case where the branch offset is invalid.
* testsuite/gas/riscv/no-relax-branch-offset-fail.d: Ditto.
* testsuite/gas/riscv/no-relax-branch-offset-fail.l: Ditto.
* testsuite/gas/riscv/no-relax-branch-offset-ok.s: Border case.
* testsuite/gas/riscv/no-relax-branch-offset-ok.d: Ditto.
* testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.s: Failure
case only on RV64 where the PC-relative offset exceed limits.
* testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.d: Ditto.
* testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.l: Ditto.
* testsuite/gas/riscv/no-relax-pcrel-offset-fail-not-32.d: Test
case for RV32 so that no errors occur.
* testsuite/gas/riscv/no-relax-pcrel-offset-ok.s: Border case.
* testsuite/gas/riscv/no-relax-pcrel-offset-ok.d: Ditto.
Each SFrame FDE contains an offset to the start of its respective SFrame
FREs in the sfde_func_start_fre_off field. To generate this offset,
fre_symbols[] array is being used. The number of elements of this array
is currently set to the total number of SFrame FREs in the entire SFrame
section. This is more than unnecessary. We only need to track as many
points as the number of SFrame FDEs.
gas/
* gen-sframe.c (output_sframe_internal): Size fde_fre_symbols
with the number of SFrame FDEs.
Kévin discovered that commit ba005d32b0 ("Handle dynamic field
properties") regressed a test in the internal AdaCore test suite.
The problem here is that, when writing that patch, I did not consider
the case where an array type's bounds might come from a member of a
structure -- but where the array is not defined in the structure's
scope.
In this scenario the field-resolution logic would trip this condition:
/* Defensive programming in case we see unusual DWARF. */
if (fi == nullptr)
return nullptr;
This patch reworks this area, partly backing out that commit, and
fixes the problem.
In the new code, I chose to simply duplicate the field's location
information. This isn't totally ideal, in that it might result in
multiple copies of a baton. However, this seemed nicer than tracking
the DIE/field correspondence for every field in every CU -- my
thinking here is that this particular dynamic scenario is relatively
rare overall. Also, if the baton cost does prove onerous, we could
intern the batons somewhere.
Regression tested on x86-64 Fedora 41. I also tested this using the
AdaCore internal test suite.
Tested-By: Simon Marchi <simon.marchi@efficios.com>
It conflicts with the ldirname function that will be added in the next
libiberty sync.
ld/:
* ldlang.c (stat_ldirname): Rename from ldirname, all uses
changed.
When all LTO sections have been removed, the BFD lto_type is set to
lto_non_ir_object by bfd_set_lto_type. In this case, don't complain
needing a plugin when seeing a LTO slim symbol.
bfd/
PR binutils/32967
* archive.c (_bfd_compute_and_write_armap): Call
bfd_lto_slim_symbol_p to check LTO slim symbol.
* bfd-in2.h: Generated.
* bfd.c (bfd_lto_slim_symbol_p): New.
binutils/
PR binutils/32967
* nm.c (filter_symbols): Call bfd_lto_slim_symbol_p to check
LTO slim symbol.
ld/
PR binutils/32967
* testsuite/ld-plugin/lto-binutils.exp: Run PR binutils/32967
tests.
* testsuite/ld-plugin/strip-1a-s-all.nd: New file.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Support added in commit 3417bfca67 for dwarf5 directory table 0
assumed that .file 0 was always the first debug .file directive.
That's not necessarily true.
* dwarf2dbg.c (get_directory_table_entry): Don't assume entry
1 is available after putting DW_AT_comp_dir in entry 0. Pass
pwd as file0_dirname to recursive call to avoid another
getpwd in the case file0_dirname is NULL.
GDB is not properly exited via 'remote_close host' when running the
testsuite in a MinGW environment. Use the 'quit' command to properly
exit the GDB debugging session.
Approved-By: Tom Tromey <tom@tromey.com>
The emoji patch broke the create_breakpoint_parse_arg_string self-test
when gdb is running on a suitable terminal. The problem is that the
test case doesn't take the error prefix string into account.
This patch fixes the test by having it compare the exception message
directly, rather than relying on the result of exception_print. I did
try a different approach, of having the test mimic exception_print,
but this one seemed cleaner to me.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
