| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
ctf_arc_import_parent, called by the cached-opening machinery used by
ctf_archive_next and archive-wide lookup functions like
ctf_arc_lookup_symbol, has an err-pointer parameter like all other opening
functions. Unfortunately it unconditionally initializes it whenever
provided, even if there was no error, which can lead to its being
initialized to an uninitialized value. This is not technically an
API-contract violation, since we don't define what happens to the error
value except when an error happens, but it is still unpleasant.
Initialize it only when there is an actual error, so we never initialize it
to an uninitialized value.
While we're at it, improve all the opening pathways: on success, set errp to
0, rather than leaving it what it was, reducing the likelihood of
uninitialized error param returns in callers too. (This is inconsistent
with the treatment of ctf_errno(), but the err value being a parameter
passed in from outside makes the divergence acceptable: in open functions,
you're never going to be overwriting some old error value someone might want
to keep around across multiple calls, some of which are successful and some
of which are not.)
Soup up existing tests to verify all this.
Thanks to Bruce McCulloch for the original patch, and Stephen Brennan for
the report.
libctf/
PR libctf/32903
* ctf-archive.c (ctf_arc_open_internal): Zero errp on success.
(ctf_dict_open_sections): Zero errp at the start.
(ctf_arc_import_parent): Intialize err.
* ctf-open.c (ctf_bufopen): Zero errp at the start.
* testsuite/libctf-lookup/add-to-opened.c: Make sure one-element
archive opens update errp.
* testsuite/libctf-writable/ctf-compressed.c: Make sure real archive
opens update errp.
|
|
make-check-all.sh
I forgot to run test-case gdb.dwarf2/dw-form-strx-out-of-bounds.exp with
make-check-all.sh, and consequently failed to notice that it fails with for
instance target board fission-dwp.
The test-case does:
...
source $srcdir/$subdir/dw-form-strx.exp.tcl
...
and in that tcl file, prepare_for_testing fails, so a -1 is returned, but
that is ignored by the source command.
Fix this by using require, but rather that testing the result of the source
command, communicate success by setting a global variable
prepare_for_testing_done.
Likewise in gdb.dwarf2/dw-form-strx.exp.
Also, the test-case gdb.dwarf2/dw-form-strx-out-of-bounds.exp fails for target
board readnow, because the DWARF error occurs during a different command than
expected.
Fix this by just skipping the test-case in that case.
Tested on x86_64-linux.
Reported-by: Simon Marchi <simark@simark.ca>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Make gdb.debuginfod codespell-clean and add the dir to the pre-commit
configuration.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Make gdb.guile codespell-clean and add the dir to the pre-commit
configuration.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Make gdb.mi codespell-clean and add the dir to the pre-commit
configuration.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Make gdb.opt codespell-clean and add the dir to the pre-commit
configuration.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Make gdb.pascal codespell-clean and add the dir to the pre-commit
configuration.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Make gdb.reverse codespell-clean and add the dir to the pre-commit
configuration.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Make gdb.rocm codespell-clean and add the dir to the pre-commit
configuration.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Make gdb.stabs codespell-clean and add the dir to the pre-commit
configuration.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Make gdb.xml codespell-clean and add the dir to the pre-commit
configuration.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Make gdb.tui codespell-clean and add the dir to the pre-commit
configuration.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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 e6213e09ed0e ("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: e6213e09ed0e ("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 906f69cf65da ("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.
|
|
|
|
|
|
|
|
|
|
Andrew pointed out that a recent commit neglected to update the
comment for find_field_create_baton. This patch fixes the oversight.
|
|
Commit 07cf922195d1 fixed the one in size_inc_line_addr. Silly me
missed the identical overflow in emit_inc_line_addr
|
|
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.
|
|
* testsuite/config/default.exp (dep_plug_opt): Don't set unless
check_plugin_api_available returns true.
|
|
In 344b1e0f5f79 ("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.
|
|
Ref: https://github.com/riscv/riscv-zilsd/blob/main/zilsd.adoc
Signed-off-by: dysun <sundongya@nucleisys.com>
Co-developed-by: LIU Xu <liuxu@nucleisys.com>
Co-developed-by: ZHAO Fujin <zhaofujin@nucleisys.com>
|
|
|
|
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.
|
