There's no point involving symbol_clone_if_forward_ref(), just for it to
replace dot_symbol by one obtained from symbol_temp_new_now(). For the
abs-section case also produce a slightly more "complete" (as in: all
potentially relevant fields filled) expression by going through
expr_build_uconstant().
Move the function next to current_location(), for it to be easier to see
the (dis)similarities. Correct the function's comment while there.
The comment says this is for HP/UX, which is no longer supported. There
should be no functional changes with this, since nothing checks
HAVE_ELF_HP_H.
Change-Id: Ie897fc64638c9fea28463e1bf69e450c3673fd84
This makes the lists easier sort read and modify. There are no changes
in the generated config.h files, so I'm confident this brings no
functional changes.
Change-Id: Ib6b7fc532bcd662af7dbb230070fb1f4fc75f86b
This patch adds support for Guarded Control Stack in AArch64 linker.
This patch implements the following:
1) Defines GNU_PROPERTY_AARCH64_FEATURE_1_GCS bit for GCS in
GNU_PROPERTY_AARCH64_FEATURE_1_AND macro.
2) Adds readelf support to read and print the GCS feature in GNU
properties in AArch64.
Displaying notes found in: .note.gnu.property
[ ]+Owner[ ]+Data size[ ]+Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: GCS
3) Adds support for the "-z gcs" linker option and document all the values
allowed with this option (-z gcs[=always|never|implicit]) where "-z gcs" is
equivalent to "-z gcs=always". When '-z gcs' option is omitted from the
command line, it defaults to "implicit" and relies on the GCS feature
marking in GNU properties.
4) Adds support for the "-z gcs-report" linker option and document all the
values allowed with this option (-z gcs-report[=none|warning|error]) where
"-z gcs-report" is equivalent to "-z gcs-report=warning". When this option
is omitted from the command line, it defaults to "warning".
The ABI changes adding GNU_PROPERTY_AARCH64_FEATURE_1_GCS to the GNU
property GNU_PROPERTY_AARCH64_FEATURE_1_AND is merged into main and
can be found in [1].
[1] https://github.com/ARM-software/abi-aa/blob/main/sysvabi64/sysvabi64.rst
Co-authored-by: Matthieu Longo <matthieu.longo@arm.com>
Co-authored-by: Yury Khrustalev <yury.khrustalev@arm.com>
The previous message for missing BTI feature in GNU properties was
not very clear. The new message explains that a missing GNU property
marking is lacking on this specific input.
This patch attempts to make the linker output more friendly for the
developers by limiting the number of emitted warning/error messages
related to BTI issues.
Every time an error/warning related to BTI is emitted, the logger
also increments the BTI issues counter. A batch of errors/warnings is
limited to a maximum of 20 explicit errors/warnings. At the end of
the merge, a summary of the total of errors/warning is given if the
number exceeds the limit of 20 invidual messages.
The current implementation of searching the first input BFD with GNU
properties has a bug. The search was not filtering on object inputs
belonging to the output link unit only, but was also including dynamic
objects, BFD plugins, and linker-created files.
This means that the initial initialization of the output properties
were skewed, and warnings on input files that should have been emitted
were not.
This patch fixes the filtering to exclude the object input files not
belonging to the output link unit, not having the same ELF class, and
not the same target architecture.
There is an early exit in _bfd_aarch64_elf_link_setup_gnu_properties
that is enabled when the output link unit is relocatable, i.e. ld
generates an output file that can in turn serve as input to ld. (see
ld manual, -r,--relocatable for more details).
At this stage, the GNU properties have already been merged and errors
or warnings (if any) have already been issued. However, OUTPROP has
not been updated yet.
Not updating OUTPROP means that implicits enablement of BTI PLTs via
the GNU properties will be ignored for final links. Indeed, the
enablement of BTI PLTs is checked inside _bfd_aarch64_add_call_stub_entries
by looking up at gnu_property_aarch64_feature_1_and (OUTPROP).
Since the final link does not happen in the case of partial linking,
the behaviour with or without the early exit should be the same.
Given that there is currently no comment for explain why the exit is
there, and that there might in the future be cases were these properties
affect relocatable links, it is preferrable to drop the early exit.
Move the code related to the search of the first bfd input with GNU
properties to a separate function:
_bfd_aarch64_elf_find_1st_bfd_input_with_gnu_property
Before this patch, warnings were reported normally, and errors
(introduced by a previous patch adding '-z bti-report' option)
were logged as error but were not provoking a link failure.
The root of the issue was a misuse of _bfd_error_handler to
report the errors.
Replacing _bfd_error_handler by info->callbacks->einfo, with the
addition of the formatter '%X' for errors fixed the issue.
Exposing the output GNU property as a parameter of
_bfd_aarch64_elf_link_setup_gnu_properties seems to break the
encapsulation. The output GNU property update should be part of the
function that sets up the GNU properties.
This patch removes the parameter, and perform the update of the GNU
property on the output object inside the function.
The current condition used to check if a GNU feature property is set
on an input object before the merge is a bit confusing.
(aprop && !<something about aprop>) || !aprop
It seems easier to understand if it is changed as follows:
(!aprop || !<something about aprop>)
- declare a new struc aarch_protection_opts to store all the
configuration options related to software protections (i.e. bti-plt,
pac-plt, bti-report level).
- add a new option "-z bti-report" to configure the log level of reported
issues when BTI PLT is forced.
- encapsulate the BTI report inside _bfd_aarch64_elf_check_bti_report.
- moved all the BTI and PAC tests into a new subfolder: "protections".
bti-far-*
bti-plt-*
bti-pac-plt-*
- move several procedures used only for AArch64 linker tests to a new exp
library file aarch64-elf-lib.exp in ld/testsuite/ld-aarch64/lib.
- use aarch64-elf-lib.exp in aarch64-ld.exp and aarch64-protections.exp.
The test gdb.cp/step-and-next-inline.exp creates a test binary called
step-and-next-inline-no-header. This test includes a function
`tree_check` which is inlined 3 times.
When testing with some older versions of gcc (I've tried 8.4.0, 9.3.1)
we see the following DWARF representing one of the inline instances of
tree_check:
<2><8d9>: Abbrev Number: 38 (DW_TAG_inlined_subroutine)
<8da> DW_AT_abstract_origin: <0x9ee>
<8de> DW_AT_entry_pc : 0x401165
<8e6> DW_AT_GNU_entry_view: 0
<8e7> DW_AT_ranges : 0x30
<8eb> DW_AT_call_file : 1
<8ec> DW_AT_call_line : 52
<8ed> DW_AT_call_column : 10
<8ee> DW_AT_sibling : <0x92d>
...
<1><9ee>: Abbrev Number: 46 (DW_TAG_subprogram)
<9ef> DW_AT_external : 1
<9ef> DW_AT_name : (indirect string, offset: 0xe8): tree_check
<9f3> DW_AT_decl_file : 1
<9f4> DW_AT_decl_line : 38
<9f5> DW_AT_decl_column : 1
<9f6> DW_AT_linkage_name: (indirect string, offset: 0x2f2): _Z10tree_checkP4treei
<9fa> DW_AT_type : <0x9e8>
<9fe> DW_AT_inline : 3 (declared as inline and inlined)
<9ff> DW_AT_sibling : <0xa22>
...
Contents of the .debug_ranges section:
Offset Begin End
...
00000030 0000000000401165 0000000000401165 (start == end)
00000030 0000000000401169 0000000000401173
00000030 0000000000401040 0000000000401045
00000030 <End of list>
...
Notice that one of the sub-ranges of tree-check is empty, this is the
line marked 'start == end'. As the end address is the first address
after the range, this range cover absolutely no code.
But notice too that the DW_AT_entry_pc for the inline instance points
at this empty range.
Further, notice that despite the ordering of the sub-ranges, the empty
range is actually in the middle of the region defined by the lowest
address to the highest address. The ordering is not a problem, the
DWARF spec doesn't require that ranges be in any particular order.
However, this empty range is causing issues with GDB newly acquire
DW_AT_entry_pc support.
GDB already rejects, and has done for a long time, empty sub-ranges,
after all, the DWARF spec is clear that such a range covers no code.
The recent DW_AT_entry_pc patch also had GDB reject an entry-pc which
was outside of the low/high bounds of a block.
But in this case, the entry-pc value is within the bounds of a block,
it's just not within any useful sub-range. As a consequence, GDB is
storing the entry-pc value, and making use of it, but when GDB stops,
and tries to work out which block the inferior is in, it fails to spot
that the inferior is within tree_check, and instead reports the
function into which tree_check was inlined.
I've tested with newer versions of gcc (12.2.0 and 14.2.0) and with
these versions gcc is still generating the empty sub-range, but now
this empty sub-range is no longer the entry point. Here's the
corresponding ranges table from gcc 14.2.0:
Contents of the .debug_rnglists section:
Table at Offset: 0:
Length: 0x56
DWARF version: 5
Address size: 8
Segment size: 0
Offset entries: 0
Offset Begin End
...
00000021 0000000000401165 000000000040116f
0000002b 0000000000401040 (base address)
00000034 0000000000401040 0000000000401040 (start == end)
00000037 0000000000401041 0000000000401046
0000003a <End of list>
...
The DW_AT_entry_pc is 0x401165, but this is not the empty sub-range,
as a result, when GDB stops at the entry-pc, GDB will correctly spot
that the inferior is in the tree_check function.
The fix I propose here is, instead of rejecting entry-pc values that
are outside the block's low/high range, instead reject entry-pc values
that are not inside any of the block's sub-ranges.
Now, GDB will ignore the prescribed entry-pc, and will instead select
a suitable default entry-pc based on either the block's low-pc value,
or the first address of the first range.
I have extended the gdb.cp/step-and-next-inline.exp test to check this
case, but this does depend on the compiler version being used (newer
compilers will always pass, even without the fix).
So I have also added a DWARF assembler test to cover this case.
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
The baseline was, afaik, specifically chosen to align with the baseline
ISA of x86-64. It therefore makes no sense to emit that property only
conditionally; if anything it confuses tools analyzing the difference
between generated object files, which may result from just
added / changed / removed (entirely ISA-independent) code, without any
change to the enabled extensions. Compilers, after all, are free to use
these baseline "extensions" when generating 64-bit code.
While changing the one testcase that needs adjustment, also correct its
misleading name (to be in sync with the filename).
On the grounds of the principle put down near the bottom of [1], along
with image and section relative operations, let's also support as insn
operands what .secidx is for on the data side (of course like elsewhere
the reloc operator can then also be used for data generation, albeit a
small tweak to x86_cons() is needed for this to work).
[1] https://sourceware.org/pipermail/binutils/2024-November/137617.html
As was pointed out in [1] compilers produce code using such constructs,
and hence we'd better support this. In analogy to the .rva directive
permit @rva to be used for this, and in analogy with other architectures
(plus to not diverge from e.g. Clang's integrated assembler, albeit I
haven't been able myself to confirm it knows this form) also permit
@imgrel.
While there also adjust the operand type specifier for the adjacent
@secrel32 - 64-bit fields cannot be used with a 32-bit relocation.
Further while there also deal with *-*-pe* in x86-64.exp, even if (right
now) perhaps only for completeness.
[1] https://sourceware.org/pipermail/binutils/2024-November/137548.html
Add missing return statements in
* gdb.threads/process-exit-status-is-leader-exit-status.c
* gdb.threads/next-fork-exec-other-thread.c
to fix 'no return statement' compiler warnings, e.g.:
process-exit-status-is-leader-exit-status.c: In function ‘start’:
process-exit-status-is-leader-exit-status.c:46:1: warning: no return
statement in function returning non-void [-Wreturn-type]
46 | }
| ^
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Fix more potential buffer overflows, and correct trad-code.c and
cisco-core.c where they should be using bfd_{z}alloc rather than
bfd_{z}malloc. To stop buffer overflows with fuzzed objects that
don't have a terminator on the core_file_failing_command string, this
patch allocates an extra byte at the end of the entire header buffer
rather than poking a NUL at the end of the name array (u_comm[] or
similar) because (a) it's better to not overwrite the file data, and
(b) it is possible that some core files make use of fields in struct
user beyond the end of u_comm to extend the command name. The patch
also changes some unnecessary uses of bfd_zalloc to bfd_alloc.
There's not much point in clearing memeory that will shortly be
completely overwritten.
PR 32399
* aix5ppc-core.c (xcoff64_core_p): Allocate an extra byte to
ensure the core_file_failing_command string is terminated.
* netbsd-core.c (netbsd_core_file_p): Likewise.
* ptrace-core.c (ptrace_unix_core_file_p): Likewise.
* rs6000-core.c (rs6000coff_core_p): Likewise.
* trad-core.c (trad_unix_core_file_p): Likewise, and bfd_alloc
tdata rather than bfd_zmalloc.
* cisco-core.c (cisco_core_file_validate): bfd_zalloc tdata.
Remove another adjustment for section address, this time for the
offset into .debug_str{,.dwo} read from .debug_str_offsets{,.dwo} by
fetch_indexed_string.
Signed-off-by: oltolm <oleg.tolmatcev@gmail.com>
Commit 36bbf8646c ("s390: Treat addressing operand sequence as one in
disassembler") changed how plain "nop" gets disassembled and missed to
update any affected linker tests accordingly.
ld/testsuite/
* ld-s390/tlsbin.dd: "nop" disassembles into "nop".
Fixes: 36bbf8646c ("s390: Treat addressing operand sequence as one in disassembler")
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
