Use SFrame FDE of type SFRAME_FDE_TYPE_FLEX_TOPMOST_FRAME.
When FP, RA were moved to a general-purpose register, the SFrame
generation previously warned and skipped the FDE (except on s390x).
This patch updates the translator to detect .cfi_register for RA (and
FP), tracks the destination register in the SFrame row entry,
and emits the register in the relevant FRE offsets in SFrame FDE type
SFRAME_FDE_TYPE_FLEX.
gas/
* gen-sframe.c (sframe_row_entry_initialize): Propagate ra_reg
and ra_deref_p.
(sframe_xlate_do_register): Handle .cfi_register for RA/FP on
AMD64 by setting flex_p and recording the register.
gas/testsuite/gas/
* cfi-sframe/cfi-sframe.exp: Run new test.
* cfi-sframe/cfi-sframe-x86_64-5.d: New test.
* cfi-sframe/cfi-sframe-x86_64-5.s: Simple test for checking
FLEX FDE generation for `.cfi_register REG_RA, XX`.
* cfi-sframe/cfi-sframe-x86_64-esc-expr-3.d: New test.
* cfi-sframe/cfi-sframe-x86_64-esc-expr-3.s: New test with DWARF
expression for REG_FP, followed by .cfi_register and .cfi_offset
for REG_FP.
* cfi-sframe/cfi-sframe-x86_64-ra-undefined-flex-1.d: New test.
* cfi-sframe/cfi-sframe-x86_64-ra-undefined-flex-1.s: New test
for FLEX FDE with undefined RA.
gas/testsuite/
* gas/cfi-sframe/cfi-sframe-x86_64-4.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-4.s: Non SP/FP based CFA.
* gas/cfi-sframe/cfi-sframe-x86_64-esc-expr-1.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-esc-expr-1.s: DRAP pattern
with both CFA expression and FP expression.
* gas/cfi-sframe/cfi-sframe-x86_64-esc-expr-2.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-esc-expr-2.s: Test CFA
expression with sleb128.
* gas/cfi-sframe/cfi-sframe.exp: Add new tests.
This patch updates the SFrame generation in GAS to translate specific
.cfi_escape directives into the new SFrame V3 FDE type
SFRAME_FDE_TYPE_FLEX.
The primary goal is to support code patterns where:
- the Canonical Frame Address (CFA) is not defined by a simple offset
from the Stack Pointer (SP) or Frame Pointer (FP), or where the CFA
rule involves a dereference. Such patterns are generated by compilers
for stack realignment (e.g., DRAP on x86_64, or when mixing legacy
codes that keep 4-byte stack alignment with modern codes that keep
16-byte stack alignment for SSE compatibility).
- the Frame Pointer is not defined by a simple offset from the CFA,
but may even involve another register and/or dereferencing.
- the Return Address is not defined by a simple offset from the CFA,
but may even involve another register and/or dereferencing.
Support for non-SP/FP based CFA: Update sframe_xlate_do_def_cfa () and
sframe_xlate_do_def_cfa_register () to detect when a non-SP/FP register
is used for the CFA.
Support for CFA expressions: A vital part of supporting the
above-mentioned cases on AMD64 is support for CFA expressions. Add
sframe_xlate_do_escape_cfa_expr () to parse simple
DW_CFA_def_cfa_expression sequence in .cfi_escape.
Support for FP expressions: Update sframe_xlate_do_escape_expr () to
handle DW_CFA_expression involving DW_OP_breg6 (rbp) on AMD64,
allowing for tracking of the Frame Pointer when it is saved with a
dereference rule in the DRAP pattern.
The "support" for both CFA expressions and FP expressions is quite
minimal, and is tailored to the most commonly seen occurrences generated
by GCC for AMD64.
gas/
* gas/gen-sframe.c (output_sframe_row_entry_offsets):
(sframe_xlate_do_def_cfa): Handle non-SP/FP CFA registers by setting
flex_p for AMD64.
(sframe_xlate_do_def_cfa_register): Likewise.
(sframe_xlate_escape_sleb128_to_int64): New definition.
(sframe_xlate_do_escape_cfa_expr): New function to handle
DW_CFA_def_cfa_expression of specific shapes.
(sframe_xlate_do_escape_expr): Update to handle dereferenced FP rules.
(sframe_xlate_do_cfi_escape): Invoke sframe_xlate_do_escape_cfa_expr ().
(create_sframe_all): In case of error, but when signal frame is
also true, there cannot be a flex FDE.
For the newly added SFrame FDE type SFRAME_FDE_TYPE_FLEX, add a new
backend hook so that the respective ABI/arch can opt out of the
generation of SFRAME_FDE_TYPE_FLEX in GAS.
AArch64 is an example of an ABI for which SFrame is supported, but one
that does not need the flexible FDE representation for any of the
current usecases currently.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
gas/
* config/tc-aarch64.c (aarch64_support_flex_fde_p): New
definition.
* config/tc-aarch64.h (aarch64_support_flex_fde_p): New
declaration.
(sframe_support_flex_fde_p): Define.
* config/tc-i386.c (x86_support_flex_fde_p): New definition.
* config/tc-i386.h (x86_support_flex_fde_p): New declaration.
(sframe_support_flex_fde_p): Define.
* config/tc-s390.c (s390_support_flex_fde_p): New definition.
* config/tc-s390.h (s390_support_flex_fde_p): New declaration.
(sframe_support_flex_fde_p): Define.
Refactor the SFrame textual dumper in sframe-dump.c to properly handle
the new FDE type.
In SFrame V2, the textual dumper could afford to be oblivious to the
exact DWARF register number for stack-pointer and frame-pointer
registers in each ABI. This is because a single bit was used to
differentiate between the two (irrespective of the ABI), and the dumper
could easily just use a:
const char *base_reg_str[] = {"fp", "sp"};
to get the register name.
With the introduction of new SFrame FDE type SFRAME_FDE_TYPE_FLEX, which
carry DWARF register numbers if applicable, this needs to change. E.g.,
for some patterns on AMD64, one may see CFA is the value at 'r10+0'; or
FP is the value at 'rbp+8'. This means that for textual dump, we now
need a mapping from:
- the ABI-specific frame-pointer to string "fp"
- the ABI-specific stack-pointer to string "sp"
This is done via the SFRAME_ABI_REG_MAP helper macros and the new
sframe_get_reg_name () API.
For registers other than stack-pointer and frame-pointer, the SFrame
textual dump does not print the register name (say, "rax"), but just the
number (i.e., "r0").
Check the func_info2 byte and dispatch the stack frame row entry (FRE)
dumping to the correct function: either dump_sframe_func_fre_simple or
dump_sframe_func_fre_flex.
Ensure the display is consistent to previous semantics. When flex FDE
is in effect, there may not always be an RA offset (after the CFA
offsets). A padding offset for RA is present if FP offsets follow. So
if a padding offset for RA is seen, we will display "U". If no RA
offset is seen, however, we will display a "u" unless its an ABI where
RA offset is fixed (in the latter case we display "f").
libsframe/
* sframe-dump.c (SFRAME_SP): Define mapping from stack-pointer
register number to "sp".
(SFRAME_FP): Define mapping from frame-pointer register number
to "fp".
(SFRAME_ABI_REG_MAP): Helper macro to define per-ABI-arch
mappings.
(sframe_get_reg_name): Helper API to get register name.
(dump_sframe_func_with_fres): Refactor a bit...
(dump_sframe_func_fre_simple): ..into this.
(sframe_format_fre_disp): New definition.
(dump_sframe_func_fre_flex): Likewise.
(dump_sframe): Allow both SFrame version 2 and version 3.
For FDE type SFRAME_FDE_TYPE_FLEX, the offsets are not only laid out
differently, they also have different encoding:
- first data item is of unsigned type, it indicates the "Control Word"
- second data item is of signed type, it indicates the "Offset Word"
(The usage of "Word" above is colloquial, does not indicate a machine word of
a specific size.)
Adjust the APIs in libsframe to get stack frame offsets by adding a new
argument type. Also add a new API to read the data items as unsigned
types of the specified size: sframe_get_fre_udata.
At the moment, like the generation routines in GAS, the textual dump
routines in sframe-dump.c are also unaware of the FDE type
SFRAME_FDE_TYPE_FLEX. In the next commits, these capabilities will be
added.
include/
* sframe-api.h (MAX_NUM_STACK_OFFSETS): Increase the number of
stack offsets to 6 to accommodate the FDE type
SFRAME_FDE_TYPE_FLEX.
(sframe_get_fre_udata): New declaration.
(sframe_fre_get_cfa_offset): Add new arg.
(sframe_fre_get_fp_offset): Likewise.
(sframe_fre_get_ra_offset): Likewise.
libsframe/
* libsframe/sframe-dump.c (dump_sframe_func_with_fres): Pass
SFRAME_FDE_TYPE_DEFAULT for FDE type.
* sframe.c (sframe_fre_get_cfa_offset): Handle FDE type.
(sframe_fre_get_fp_offset): Likewise.
(sframe_fre_get_ra_offset): Likewise.
* libsframe/libsframe.ver: Add new API sframe_get_fre_udata.
libsframe/testsuite/
* libsframe.find/findfre-1.c: Pass SFRAME_FDE_TYPE_DEFAULT for
FDE type.
* libsframe.find/findfunc-1.c: Likewise.
* libsframe.find/plt-findfre-1.c: Likewise.
* libsframe.find/plt-findfre-2.c: Likewise.
This patch updates the routines for emission of the new FDE type
SFRAME_FDE_TYPE_FLEX in the SFrame output section. The support for
generating these flex FDEs themselves is added in a subsequent commit.
Update struct sframe_row_entry to track additional state for CFA,
FP, and RA. Modify output_sframe_row_entry_offsets () to emit
metadata/offset pairs for flexible FDEs or padding where applicable,
ensuring the usual ordering (CFA, RA, FP). The padding data, a.k.a.
SFRAME_FRE_RA_OFFSET_INVALID is emitted in flexible FDEs when RA is
untracked but FP offsets follow. Trailing padding offsets should not
occur. Add a new function get_udata_size_in_bytes () to account for
sizing of unsigned register metadata.
gas/
* gen-sframe.c (get_udata_size_in_bytes): Get size of unsigned
int data in bytes.
(get_fre_num_offsets): Handle SFRAME_FDE_TYPE_FLEX.
(sframe_get_fre_offset_size): Account for register metadata
in flexible FDEs.
(output_sframe_row_entry_offsets): Add logic for flexible
FDE offset pairs.
(output_sframe_row_entry): Reset base register for flex FDEs.
(output_sframe_funcdesc): Emit FDE type in func_info2.
(sframe_xlate_ctx_init): Initialize flex_p.
(sframe_xlate_ctx_finalize): Finalize flex_p status.
(sframe_row_entry_initialize): Copy new deref tracking bits.
(sframe_xlate_do_offset): Set deref bits during translation.
* gen-sframe.h (struct sframe_row_entry): Add cfa_deref_p,
fp_deref_p, and ra_deref_p.
(struct sframe_func_entry): Add fde_flex_p.
(struct sframe_xlate_ctx): Add flex_p.
Up until now, for SFrame stack trace data generation (for default FDE
type), keeping two states sufficed to distinguish between the following
cases:
- the tracked entity is saved on a location on stack (identified by
SFRAME_FRE_ELEM_LOC_STACK)
- the tracked entity is in its designated register (identified by
SFRAME_FRE_ELEM_LOC_REG).
Soon though, we will start to generate a new FDE type
SFRAME_FDE_TYPE_FLEX, where in addition to above:
- the tracked entity may be saved in a temporary register
- the tracked entity may be saved at a "non-standard" location, e.g.,
not a simple CFA+offset based location
- and other cases
To effectively distinguish between the various states (necessary to
track for flex FDEs), define three states to track the location of each
tracked entity:
- SFRAME_FRE_ELEM_LOC_NONE: the entity is in its desginated location
(e.g., in case of AMD64 where the RA is at fixed offset from CFA)
- SFRAME_FRE_ELEM_LOC_REG: the entity is in a location based off a
register
- SFRAME_FRE_ELEM_LOC_STACK: the entity is in a location based off the
CFA
While at it, rather than asserting in sframe_xlate_do_offset (), reset
the fp_reg state to SFRAME_FRE_REG_INVALID. This is in preparation for
upcoming flex FDE generation patches.
Co-Authored-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
gas/
* gen-sframe.c (sframe_xlate_do_offset): Reset other state.
(sframe_xlate_do_same_value): Reset to SFRAME_FRE_ELEM_LOC_NONE.
* gen-sframe.h (SFRAME_FRE_ELEM_LOC_REG): New definition.
(SFRAME_FRE_ELEM_LOC_STACK): Likewise.
(SFRAME_FRE_ELEM_LOC_NONE): Likewise.
In SFrame V2, we did use the the term 'FDE Type' for the two designated
'PC Type' for the SFrame FDEs (SFRAME_FDE_TYPE_PCINC,
SFRAME_FDE_TYPE_PCMASK). In hindsight, 'FDE Type' was an inappropriate
term for the said intent. Fix this terminology by defining two new
constants:
- SFRAME_V3_FDE_PCTYPE_MASK
- SFRAME_V3_FDE_PCTYPE_INC
The old constants from V2 (SFRAME_FDE_TYPE_PCINC,
SFRAME_FDE_TYPE_PCMASK) remain, but are now unused in the codebase.
The term 'FDE Type' should be used for the actual FDE Types. In a
subsequent commit, we will add SFRAME_FDE_TYPE_FLEX FDE Type for SFrame
V3.
bfd/
* elf64-s390.c (_bfd_s390_elf_create_sframe_plt): Rename
inappropriate SFRAME_FDE_TYPE_PCINC to SFRAME_V3_FDE_PCTYPE_INC.
* elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Likewise. Also
rename inappropriate SFRAME_FDE_TYPE_PCMASK to
SFRAME_V3_FDE_PCTYPE_MASK.
gas/
* gen-sframe.c (output_sframe_funcdesc): Likewise.
* sframe-opt.c (sframe_convert_frag): Likewise.
libsframe/
* sframe-dump.c (dump_sframe_func_with_fres): Likewise.
* sframe.c (sframe_fre_check_range_p): Likewise.
(sframe_fde_create_func_info): Likewise.
libsframe/testsuite/
* libsframe.encode/encode-1.c: Likewise.
* libsframe.find/findfre-1.c: Likewise.
* libsframe.find/findfunc-1.c: Likewise.
* libsframe.find/plt-findfre-1.c: Likewise.
* libsframe.find/plt-findfre-2.c: Likewise.
In SFrame V2, the FDE representation caters to the most common cases of
stack trace metadata:
- CFA is SP/FP based,
- FP/RA offsets, if present are CFA based (except some cases in s390x
where reg can be encoded).
Introduce an additional FDE type SFRAME_FDE_TYPE_FLEX, which can encode
a more flexible set of CFA, FP and RA recovery rules. Some of the
patterns supported include:
- CFA may be non-SP/FP based.
- CFA, FP may encode dereferencing of register after offset adjustment
- RA may be in a non-default register.
The important bit here is that since SFrame does not track all
callee-saved registers, the above-mentioned recovery rules must only be
done for topmost frames (by the stack tracer).
Adding a new FDE type does have implications for a stack tracer in that
it needs to:
- Check the FDE type before interpreting the variable length bytes
trailing the SFrame FRE header as stack offsets.
- If the FDE type is SFRAME_FDE_TYPE_FLEX, and the
recovery rules employ the use of any non-SP/FP based register, the
stack tracer must proceed only if it is the topmost frame on stack.
For CFA, RA, and FP, up to two "offsets" may be used. The two offsets
represent the information as follows:
- (minimum 8-bit) offset1 to encode register like:
(regnum << 3) | unused << 2 | deref << 1 | reg_p (=1)
- offset2 to encode offset: offset
reg_p = 1 indicates a register, reg_p = 0 indicates CFA.
The offsets are in the usual order: CFA, RA, FP if present.
For example, for FP/RA tracking,
a) If the reg is REG1 for FP/RA tracking,
- Encoding:
+ offset1 to encode register: (REG1 << 3) | unused << 2 | deref << 1 | reg_p (=1)
+ offset2 to encode offset: offset
- Action:
+ if deref, FP/RA = \*(REG1 + offset) (e.g., seen for FP recovery
with certain DRAP patterns on x86_64)
+ if no deref, FP/RA = REG1 + offset
b) If the reg is CFA for FP/RA tracking,
- Encoding:
+ [=Effectively Padding] offset1 to encode register:
(( 0 << 3 ) | unused << 2 | 0 << 1 | reg_p (=0))
+ offset2 to encode offset: offset
- Action:
+ if deref, FP/RA = *(CFA + offset)
+ if no deref, FP/RA = CFA + offset (pattern shouldnt be seen for
RA)
Next for CFA tracking,
- Action:
+ if deref, CFA = *(reg + offset) (e.g., seen for CFA recovery in
some stack realignment patterns on AMD64)
+ if no deref, CFA = reg + offset (e.g., for .cfi_def_cfa 2, 8, or
.cfi_def_cfa 10, 0)
Expected usage of this FDE type is quite low (DRAP on x86_64).
NB: In SFrame V2, we did use the the term 'FDE Type' for the two
designated 'PC Type' for the SFrame FDEs (SFRAME_FDE_TYPE_PCINC,
SFRAME_FDE_TYPE_PCMASK). In hindsight, 'FDE Type' was inappropriate
term. In a subsequent commit, we will fix this terminology for SFrame
V3.
include/
* sframe.h (SFRAME_FDE_TYPE_FLEX): New SFrame FDE type.
(SFRAME_V3_FDE_TYPE_MASK): New constant definition.
(SFRAME_V3_FDE_TYPE): New macro definition.
(SFRAME_V3_SET_FDE_TYPE): Likewise.
(SFRAME_V3_FLEX_FDE_REG_ENCODE): Macro to encode register in the
SFrame offset data.
(SFRAME_V3_FLEX_FDE_OFFSET_REG_NUM): New definition.
(SFRAME_V3_FLEX_FDE_OFFSET_REG_DEREF_P): Likewise.
(SFRAME_V3_FLEX_FDE_OFFSET_REG_P): Likewise.
The existing field func_info (in the SFrame FDE) is used to convey important
information around the encoding and interpretation of the rest of the
stack trace data for the respective SFrame FDE: the SFrame FRE type,
SFrame FDE PC type, etc.
Currently there is 1 bit left for AArch64, and 2 bits for AMD64, s390x
(and other future ABIs to be supported). Provision some additional
space now (specifically an additional 8-bits) for future needs for V3
and beyond.
Compared to V2, this now increases the size of SFrame FDE by 1 byte in
V3. In this patch, the additional func_info2 byte is not used
functionally yet. Hence, rather mechanical changes in libsframe, bfd
and libsframe/testsuite accompany. We will put func_info2 into use in a
later patch by reserving 5 of these bits for SFrame FDE types.
With the addition of a new byte for additional func info (func_info2),
add a new arg to allow usecases like textual dumper to get all data
members in one API: sframe_decoder_get_funcdesc_v3. To keep the APIs
symmetric looking, add new arg to sframe_encoder_add_funcdesc_v3 too.
Since bfd uses these APIs, carry out the mechanical change in the
respective APIs too. And of course, the testsuite which exercises these
APIs.
bfd/
* elf-sframe.c (_bfd_elf_merge_section_sframe): Get and set
func_info2.
* elf64-s390.c (_bfd_s390_elf_create_sframe_plt): Pass 0 for
func_info2 for SFrame FDE for PLT.
* elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Likewise.
gas/
* gen-sframe.c (output_sframe_funcdesc): Emit the uint8_t for
func_info2.
libsframe/
* sframe-dump.c (dump_sframe_func_with_fres):
* sframe.c (sframe_fde_tbl_init): Handle the new additional
member.
(sframe_encoder_write_fde): Likewise.
* sframe.c (sframe_decoder_get_funcdesc_v3): Update func_info2.
libsframe/testsuite/
* libsframe.decode/DATA2: Update data file with SFrame section
data.
* libsframe.encode/encode-1.c: Pass 0 for func_info2 arg.
* libsframe.find/findfre-1.c: Likewise.
* libsframe.find/findfunc-1.c: Likewise.
* libsframe.find/plt-findfre-1.c: Likewise.
* libsframe.find/plt-findfre-2.c: Likewise.
include/
* sframe.h: Add new uint8_t sfde_func_info2 to
sframe_func_desc_entry_v3.
* sframe-api.h (sframe_decoder_get_funcdesc_v3): New arg.
(sframe_encoder_add_funcdesc_v3): Likewise.
Update the SFrame generation logic in GAS to emit Function Descriptor Entries
(FDEs) for signal frames even when no Frame Row Entries (FREs) could be
generated.
Previously, create_sframe_all () would discard any FDE that failed
translation or resulted in zero FREs. However, for signal frames (marked
with .cfi_signal_frame), preserving the FDE may be valuable even without
stack offsets. The presence of the SFrame FDE with the 'Signal'
attribute may allow stack tracers to identify the frame as a signal
trampoline and potentially apply fallback handling, rather than treating
the PC range as having no stack trace info at all.
The patch modifies create_sframe_all () to detect translation errors for
signal frames, effectively allowing the generation of an empty FDE (0 FREs)
marked with the 'S' attribute.
gas/
* gen-sframe.c (sframe_fde_free): Add NULL check for safety.
(create_sframe_all): Allow FDEs for signal frames even if translation
encountered errors or produced no FREs.
gas/testsuite/
* gas/cfi-sframe/cfi-sframe.exp: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-signal-1.d: New test ensuring
signal frame FDE is emitted with 0 FREs.
* gas/cfi-sframe/cfi-sframe-x86_64-signal-1.s: New test.
Reserve a bit in function info byte in the SFrame FDE to designate
signal frames.
Also update the SFrame opt code in GAS and dumping routines in libsframe
to handle signal frame bit.
include/
* sframe.h (SFRAME_V3_FDE_SIGNAL_P): Extract signal frame bit.
(SFRAME_V3_FDE_UPDATE_SIGNAL_P): Set signal frame bit.
gas/
* gen-sframe.c (get_dw_fde_signal_p): New function to retrieve signal
frame state from DWARF FDE.
(sframe_v3_set_func_info): Renamed from sframe_v1_set_func_info.
Accept signal_p argument and encode it.
(sframe_set_version): Update ops to use sframe_v3_set_func_info.
(sframe_set_func_info): Pass signal_p to the ops hook.
(output_sframe_funcdesc): Retrieve signal frame marker and pass to
sframe_set_func_info.
* gen-sframe.h (struct sframe_version_ops): Update set_func_info
signature.
* sframe-opt.c (sframe_convert_frag): Preserve signal_p bit during
fragment conversion. While at it, use SFRAME_V3_* macros where
applicable.
libsframe/testsuite/
* gas/cfi-sframe/cfi-sframe-common-13.d: New test.
* gas/cfi-sframe/cfi-sframe-common-13.s: New test.
* gas/cfi-sframe/cfi-sframe.exp: Run new test.
libsframe/
* sframe-dump.c (dump_sframe_func_with_fres): Decode signal frame bit
and print "S" attribute in the dump output.
This change enables support text > 2 GiB in SFrame format.
Each SFrame FDE needs to hold information about the start PC of the
function it pertains to. Currently, the field 'sfde_func_start_address'
in SFrame FDE is encoded as a 32-bit offset to the start PC of the
function from the field itself.
In SFrame V2, this offset was a signed 32-bit offset. The signedness
gives the flexibility of having .sframe ELF section before or after the
.text* sections. But the size of 32-bit puts the limitation that
.sframe togther with the .text* sections must fit the 2 GiB range.
Currently, if the linker sees the offset not representable as 32-bit
signed offset, it issues an error (not seen in the wild, simulated by
forcing a function to align via an '.align 2147483648' directive):
test.o:(.sframe+0x1c): relocation truncated to fit: R_X86_64_PC32 against `.text'
make: *** [Makefile:7: all] Error 1
ATM, EH Frame also suffers with the same issue.
Moving forward, some cloud applications have been shown to be nearing
1.5 GiB threshold. Extending the offset to int64_t now seems to be good
choice to make now for future-proof'ing the sections.
The use of int64_t offset is done for all SFrame V3 sections. This
bump from int32_t to int64_t should not lead to an increase in the size
of SFrame sections, because of the following additional changes to the
SFrame FDE specification:
- Reduce the type of sfde_func_num_fres (from uint32_t to uint16_t)
- Remove the 2 bytes of padding (sfde_func_padding2). These served the
two-fold purpose of keeping FDE data aligned _and_ unused space for
future needs.
Now that the offset is int64_t, start using the
sframe_decoder_get_funcdesc_v3 () instead of
sframe_decoder_get_funcdesc_v2 () in GNU ld.
This patch changes the offset type in the SFrame FDE definition to an
int64_t. No further changes in gas are necessary because the code
already accounts for writing out as per the size of the member of the
struct:
emit_expr (&exp, sizeof_member (sframe_func_desc_entry,
sfde_func_start_offset));
bfd/
* elf-sframe.c (sframe_read_value): Signed offset for start PC
is 8-bytes now.
(_bfd_elf_merge_section_sframe): Likewise.
* elf64-s390.c (_bfd_s390_elf_create_sframe_plt): Use V3 API.
(elf_s390_finish_dynamic_sections): Signed offset for start PC
is 8-bytes now.
* elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Use V3 API.
(_bfd_x86_elf_finish_dynamic_sections): Signed offset for start
PC is 8-bytes now.
gas/
* sframe.c (output_sframe_funcdesc): Rename to
sfde_func_start_offset.
libsframe/
* libsframe/sframe.c (sframe_fde_tbl_init): Rename to
sfde_func_start_offset.
(flip_fde): Likewise.
(sframe_decoder_get_secrel_func_start_addr): Use int64_t.
(sframe_fre_check_range_p): Likewise.
(sframe_decoder_get_offsetof_fde_start_addr): Rename to
sfde_func_start_offset.
(sframe_get_funcdesc_with_addr_internal): Use int64_t.
(sframe_find_fre): Likewise.
(sframe_encoder_get_offsetof_fde_start_addr): Rename to
sfde_func_start_offset.
(sframe_encoder_add_funcdesc_internal): Use int64_t.
(sframe_encoder_add_funcdesc): Likewise. And rename to
sfde_func_start_offset.
(sframe_encoder_write_fde): Rename to sfde_func_start_offset.
libsframe/testsuite/
* libsframe.decode/DATA2: Regenerate the data file.
* libsframe.encode/encode-1.c: Use int64_t for start pc offset.
* libsframe.find/findfre-1.c: Likewise.
* libsframe.find/findfunc-1.c: Likewise.
* libsframe.find/plt-findfre-1.c: Likewise.
* libsframe.find/plt-findfre-2.c: Likewise.
include/
* sframe-api.h (sframe_find_fre): Update arg type to int64_t.
(sframe_encoder_add_funcdesc): Likewise.
* sframe.h: Change data type to int64_t.
Remove the unused sfde_func_padding2 member from the
sframe_func_desc_entry_v3 structure.
A later patch in this series reorganizes the members of the FDE
structure in a way explicit padding is no longer necessary to keep
natural alignment. So remove the explicit padding now.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
include/
* sframe.h: Remove sfde_func_padding2 from
sframe_func_desc_entry_v3.
gas/
* gen-sframe.c (output_sframe_funcdesc): Stop writing
sfde_func_padding2.
libsframe/
* sframe.c (sframe_encoder_write_fde): Stop writing
sfde_func_padding2.
* testsuite/libsframe.decode/DATA2: Regenerate binary test data.
Reduce the size of the num_fres field in the Function Descriptor Entry
(FDE) from 32 bits to 16 bits.
The number of Frame Row Entries (FREs) for a single function is extremely
unlikely to exceed 65,535 in real-world scenarios. Reducing this field
saves 2 bytes per FDE, contributing to a smaller overall SFrame section size.
(BTW, these savings will be eaten up by a later commit which adds
support for text > 2 GiB by increasing an offset from int32_t to
int64_t).
Safety checks are added to the assembler to warn and skip SFrame FDE
generation if a function's FRE count exceeds UINT16_MAX.
Note regarding alignment: With the current patch, the members of
sframe_func_desc_entry_v3 are not at aligned boundaries anymore. Recall
that all sframe_func_desc_entry_v3 entries are stored together in the
"SFrame FDE sub-section" forming an index. Only after a later patch in
the series "[29/36] [SFrame-V3] include: gas: libsframe: split FDE into
desc and attr" will the alignment properties of SFrame index will be
restored.
include/
* sframe.h (sframe_func_desc_entry_v3): Change sfde_func_num_fres
type to uint16_t.
gas/
* gen-sframe.c (output_sframe_funcdesc): Write 2 bytes for num_fres
and assert it fits in uint16_t.
(sframe_do_fde): Add check to skip FDE emission if num_fres exceeds
UINT16_MAX.
libsframe/
* sframe.c (sframe_encoder_write_fde): Cast num_fres to uint16_t
to ensure correctly written out data.
* testsuite/libsframe.decode/DATA2: Update binary test data.
(Similar to V2) Add two new APIs for adding and getting SFrame FDE:
- sframe_encoder_add_funcdesc_v3
- sframe_decoder_get_funcdesc_v3
Note the argument for the function start address is int64_t instead of
int32_t (the latter is used in sframe_encoder_add_funcdesc_v2 and
sframe_encoder_get_funcdesc_v2). The new V3 APIs will be used in a
subsequent commit to extend SFrame V3 to support text > 2 GiB by
allowing int64_t offsets by default.
Similar to the analogous V2 APIs, they return 0 on success and
SFRAME_ERR (in case of sframe_decoder_get_funcdesc_v3) or error code (in
case of sframe_encoder_add_funcdesc_v3) on failure.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
include/
* sframe-api.h (sframe_decoder_get_funcdesc_v3): New
declaration.
(sframe_encoder_add_funcdesc_v3): Likewise.
libsframe/
* libsframe.ver: Add the new APIs.
* sframe.c (sframe_decoder_get_funcdesc_v3): New definition.
(sframe_encoder_add_funcdesc_v3): Likewise.
Consolidate the 2.0 and 2.1 nodes into a new 3.0 node.
In subsequent patches for releasing SFrame V3, libsframe APIs will be
affected. A non-exhaustive list of noteworthy changes are mentioned
next.
Some existing APIs (breaking binary compatibility) by adding an
additional arg to these:
- sframe_fre_get_ra_offset
- sframe_fre_get_fp_offset
- sframe_fre_get_cfa_offset
Change of argument type:
- sframe_find_fre
The behaviour of some APIs will change:
- sframe_encoder_write now writes out V3.
And lastly removal of two APIs:
- sframe_decoder_get_funcdesc
- sframe_encoder_add_funcdesc
Above make this release of the library binary incompatible with previous
release, hence a version bump and new version node 3.0.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
libsframe/
* libsframe.ver: Create a new 3.0 node. Remove the 2.0 node.
* libtool-version: Bump the so version.
Bump version to SFRAME_VERSION_3. Introduce a new definition of SFrame
FDE for version 3, which is a duplicate of SFrame FDE in V2, for now.
In other words, no changes to the format specification yet.
GNU as emits SFrame V3 by default. SFrame encoder (ld) emits SFrame V3
sections. In a later commit, we will add a new command line option to
gas: --gsframe-3 which will bind the implementation in gas to emit
SFrame V3.
Also, adjust the testcases for the new version string
"SFRAME_VERSION_3".
bfd/
* elf-sframe.c (_bfd_elf_merge_section_sframe): Linker emits
the latest version by default.
* elf64-s390.c (_bfd_s390_elf_create_sframe_plt): Linker emitted
PLT sections are also SFRAME_VERSION_3.
* elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Likewise.
gas/
* gen-sframe.c (sframe_set_version): GAS emits SFrame V3 by
default.
(output_sframe): Likewise.
libsframe/
* sframe-dump.c (dump_sframe): Enable dumping for both
SFRAME_VERSION_2 and SFRAME_VERSION_3.
include/ChangeLog:
* sframe.h (SFRAME_VERSION_3): New definition.
(SFRAME_VERSION): Current version is now SFRAME_VERSION_3.
(SFRAME_V3_FDE_FUNC_INFO): New definition.
(SFRAME_V3_FDE_FRE_TYPE): Likewise.
(SFRAME_V3_FDE_PC_TYPE): Likewise.
(SFRAME_V3_AARCH64_FDE_PAUTH_KEY): Likewise.
(SFRAME_V3_FDE_UPDATE_PAUTH_KEY): Likewise.
binutils/testsuite/
* all affected tests: Replace SFRAME_VERSION_2 with
SFRAME_VERSION_3.
gas/testsuite/
* all affected tests: Likewise.
ld/testsuite/
* all affected tests: Likewise.
libsframe/testsuite/
* all affected tests: Likewise.
As the library version will be bumped soon, include this change now.
Note the arg names in sframe-dump.c APIs have 'sfd_ctx' instead of the
usual 'dctx'. We can address this cosmetic change at a later time.
Other cosmetic changes, e.g. to make fixing function-level comments more
consistent, are left out of the patch for now.
Additionally, constify the return type of static function
sframe_decoder_get_header, now that the call sites consistently use a
const object.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
sframe_decoder_get_funcdesc () was added for SFRAME_VERSION_1. This has
since been obsoleted by introduction of SFRAME_VERSION_2 and its
corresponding sframe_decoder_get_funcdesc_v2 API.
Remove from the version script file as well. We will bump the version
of the library to 3.0.0 in a subsequent patch (closer to release) and
consolidate the entries into a new LIBSFRAME_3.0 node.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
include/
* sframe-api.h (sframe_decoder_get_funcdesc): Remove.
libsframe/
* libsframe.ver: Likewise.
* sframe.c (sframe_decoder_get_funcdesc): Remove definition.
The existing frecnt-2.c testcase reads the SFrame section from the
provided DATA2 buffer. It exercises the sframe_decode (),
sframe_decoder_get_num_fidx (), and sframe_decoder_get_funcdesc_v2 ()
APIs. Currently DATA2 file is the SFrame section created from the test
input (mentioned in the comments in the file) in SFrame version 2
format.
Moving forward, creating SFrame V2 section via GNU assembler and GNU ld
will not be supported. But textual dump of SFrame V2 sections via
readelf/objdump will need to be supported. Add a test similar to
frecnt-2.c using SFrame version 2 binary data to the libsframe
testsuite. Such a test will help ensure that sframe_decode () and
related APIs remain tested for multiple supported arches till the
support for dumping V2 sections is to be maintained.
Duplicate frecnt-2.c to create a frecnt-v2.c, the latter will test with
a SFrame V2 input section always.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
libsframe/
* Makefile.in: Regenerated.
libsframe/testsuite/
* libsframe.decode/decode.exp: Add new test.
* libsframe.decode/local.mk: Likewise
* libsframe.decode/DATA-V2: New SFrame V2 test data file.
* libsframe.decode/frecnt-v2.c: New test.
In subsequent commits, we will add support for SFrame V3. In the next
GNU Binutils release, GNU as and ld will only generate SFrame V3; SFrame
V2 will not be supported for generation nor linking.
For readelf/objdump, however, continue to support textual dump of SFrame
V2 sections. Add a binary file (with no debug data) with SFrame V2
section to keep the dumping tested.
Add ET_REL And ET_EXEC binary file based tests for x86_64 and s390x.
Check that both readelf and objdump works on the SFrame V2 sections.
binutils/testsuite/
* binutils-all/s390/README-sframe-tests: New test.
* binutils-all/s390/sframe.exp: New test.
* binutils-all/s390/test-v2-ET_EXEC.sframe.bz2: New test.
* binutils-all/s390/test-v2-ET_EXEC.sframe.dump: New test.
* binutils-all/s390/test-v2-ET_REL.sframe.bz2: New test.
* binutils-all/s390/test-v2-ET_REL.sframe.dump: New test.
* binutils-all/x86-64/README-sframe-tests: New test.
* binutils-all/x86-64/sframe.exp: New test.
* binutils-all/x86-64/test-v2-ET_EXEC.sframe.bz2: New test.
* binutils-all/x86-64/test-v2-ET_EXEC.sframe.dump: New test.
* binutils-all/x86-64/test-v2-ET_REL.sframe.bz2: New test.
* binutils-all/x86-64/test-v2-ET_REL.sframe.dump: New test.
Support for DWP v1 was removed in commit 92a222b648 ("gdb/dwarf: remove
support for DWP v1").
Change-Id: I6ce341bb6a2238b434fb458b3e2aa81db74cd8ae
Approved-By: Eli Zaretskii <eliz@gnu.org>
I looked at adding -Wmissing-noreturn to the warning flags. This
resulted in too many false reports, IMO, so I am not planning to
submit it.
However, it did point out a few spots that legitimately should have
[[noreturn]].
In making this patch, my criterion was to mark up a function whose
contract is that it always throws an exception. I did not include
functions that just happen to always throw (e.g.,
default_infcall_mmap). That is, this patch uses the attribute as a
form of documentation and not really for its code-generation
application.
Tested by rebuilding.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries reported [1] that a use of the `t` printf length modifier
(used for ptrdiff_t) breaks "set debug dwarf-die 1":
+break -qualified main
Reading Reading compcomp unit at offset unit at offset 0x00x39
Reading comp unit at offset 0x1a8
Reading comp unit at offset 0x1e9
Reading comp unit at offset 0x2c5
Reading comp unit at offset 0x2a2
Reading comp unit at offset 0x904
Unrecognized format specifier 't' in printf
This use is in dwarf2/read.c:
gdb_printf (gdb_stdlog, "Read die from %s@0x%tx of %s:\n",
m_die_section->get_name (),
(begin_info_ptr - m_die_section->buffer),
bfd_get_filename (m_abfd));
Add support for the `t` length modifier in format_pieces, which
gdb_printf ultimately uses (through ui_out::vmessage). Modify the three
users of format_pieces: gdb's printf command, gdb's ui_out::vmessage
function and gdbserver's ax_printf function.
The implementation is mostly copied from what we do for size_t.
Since format_pieces is also used to implement the printf command, this
patch brings user-visible changes. Before:
(gdb) printf "%td\n", -123
❌️ Unrecognized format specifier 't' in printf
After:
(gdb) printf "%td\n", -123
-123
[1] https://inbox.sourceware.org/gdb-patches/d4ccce34-aad5-4e3d-8fc9-efb2fc11275c@suse.de/
Change-Id: Ie9fce78f5f48082d8f8a9ca2847b5ae26acaa60d
Approved-By: Tom Tromey <tom@tromey.com>
The HFILES_NO_SRCDIR in our Makefile has gotten a little out of date.
The files: expanded-symbol.h, finish-thread-state.h, and
nat/amd64-linux.h are missing, and there are a few files that are in
the list twice.
This commit adds the missing files and removes the duplicates.
There should be no changes to a built GDB after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
Bug PR gdb/33748 reports a regression with print styled output from
Python when using ANSI escape sequences to apply the styling. This
regression was introduced by commit:
commit 3825c972a6
Date: Wed Jun 18 15:02:29 2025 +0100
gdb: allow gdb.Color to work correctly with pagination
Prior to this commit GDB would always forward any ANSI escape
sequences directly to the output stream, but this meant that GDB
didn't know which style was currently in effect.
The above commit changed GDB so that we would parse the ANSI escape
sequence, and then apply it to the output stream, this allowed GDB to
track which style was in use, which in turn meant that GDB could
correctly suspend the style and reapply it when the pager was
activated.
The problem though is that ANSI escape sequences can be built up in
parts. For example, a user can emit the sequence to change the
foreground blue, and then later emit the sequence to change the text
to bold. The result is output that is both blue and bold.
In the above commit, when parsing an incoming ANSI sequence, GDB was
always starting from the default styling state. The result of parsing
the ANSI sequence was then being applied. In our above example, this
meant that when parsing the sequence for bold text we would "forget"
that the current style had a blue foreground color.
This can be easily fixed by starting from the current style, rather
than the default style.
This fix was suggested by Patryk Sondej who originally reported the
bug.
Co-Authored-By: Patryk Sondej <patryk.sondej@gmail.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33748
Approved-By: Tom Tromey <tom@tromey.com>
This 'return' comes after a call to a 'noreturn' function, and can be
removed.
I am not sure exactly what is up with the comment, but perhaps there
was a time when 'error' was not marked this way.
create_dwo_unit_in_dwp_v2 and create_dwo_unit_in_dwp_v5 are very
similar. Merge them into a common create_dwo_unit_in_dwp function, with
a few conditionals for what differs. This makes it easier to spot the
differences between the two paths, and it's less code to maintain.
Change-Id: I71c44b827fff3d4c8214a075a397a852a38d1cf9
Reviewed-By: Tom Tromey <tom@tromey.com>
The two variants of section_pool are identical, except the size of the
section_ids array. We can have only one, we just need to ensure that it
is large enough for v5. And then I think that the "section_pool" struct
is unnecessary, we can have the fields directly in dwp_hash_table.
Change-Id: I70167a95ff61ff668c09c7e19568ced2798fa6f3
Reviewed-By: Tom Tromey <tom@tromey.com>
Change the `void *` parameter to `dwp_file *`. Remove the unused `abfd`
parameter. These were probably missed when converting the caller from
bfd_map_over_sections to gdb_bfd_sections.
Change-Id: I0420c83ba35ae304901b9e140584ebaba31f2330
Approved-By: Tom Tromey <tom@tromey.com>
The GCC wiki [1] says that version 1 of the DWP format "was an
experimental version that is no longer supported". That comment was
written in 2013. From what I understand, DWP version 1 was not widely
adopted. Unlike version 2 and version 5 (which is part of DWARF 5).
I propose to get rid of v1 support, which allows removing a bit of code,
making things a bit easier when reasoning about DWARF code.
[1] https://gcc.gnu.org/wiki/DebugFissionDWP
Change-Id: Ie46b55662e63b7f341b7827330154ec4ab5af9e5
Approved-By: Tom Tromey <tom@tromey.com>
I noticed that create_dwo_unit_in_dwp_v2 and create_dwo_unit_in_dwp_v5
initialized structure virtual_v2_or_v5_dwo_sections differently, one
with a memset and one with default initialization. Make that consistent
by moving the initialization in the struct itself, which is less
error-prone anyway.
Change-Id: I48a21a871601d076bbeeb19befd0ad62e9ba7f2a
Approved-By: Tom Tromey <tom@tromey.com>
When linker relaxation converts CALL (auipc+jalr, 8 bytes) to JAL
(4 bytes), further relaxation to C.J or C.JAL (2 bytes) may become
possible as code shrinks and jump distances decrease.
This patch adds _bfd_riscv_relax_jal to perform this second-pass
relaxation. To enable this, we introduce R_RISCV_DELETE_AND_RELAX,
a new internal relocation that combines piecewise deletion with
preservation of relaxation capability. When _bfd_riscv_relax_call
relaxes CALL to JAL, it marks the deletion as R_RISCV_DELETE_AND_RELAX
instead of R_RISCV_DELETE. After the piecewise deletion is resolved,
R_RISCV_DELETE_AND_RELAX is converted back to R_RISCV_RELAX at the
JAL instruction offset, allowing _bfd_riscv_relax_jal to further
relax JAL to C.J/C.JAL.
C.JAL is only available on RV32 (rd=ra), while C.J is available on
both RV32 and RV64 (rd=x0).
Changes since v1:
- Use R_RISCV_DELETE_AND_RELAX with piecewise deletion instead of
calling _riscv_relax_delete_immediate directly, to maintain
relaxation performance.
- Add preserve_relax parameter to riscv_relax_delete_bytes to
simplify the logic in _bfd_riscv_relax_call.
There is no value assigned in `_bfd_mips_elf_generic_reloc' via the
`error_message' parameter and consequently the original `error_message'
variable in `_bfd_mips_elf_orphan_shr16_reloc' remains uninitialized in
the error case, which newer versions of GCC can correctly diagnose:
In function '_bfd_mips_elf_orphan_shr16_reloc',
inlined from 'mips_elf_free_hi16_list' at ../../binutils-gdb/bfd/elfxx-mips.c:13309:12:
../../binutils-gdb/bfd/elfxx-mips.c:13281:5: error: 'error_message' may be used uninitialized [-Werror=maybe-uninitialized]
13281 | _bfd_link_reloc_status_error (abfd, info, hi->input_section,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
13282 | &hi->rel, error_message, r);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../binutils-gdb/bfd/elfxx-mips.c: In function 'mips_elf_free_hi16_list':
../../binutils-gdb/bfd/elfxx-mips.c:13255:9: note: 'error_message' declared here
13255 | char *error_message;
| ^~~~~~~~~~~~~
cc1: all warnings being treated as errors
Fix the problem by preinitializing the variable to NULL as at other
places.
This patch is in response to fuzzing testcases that manage to cause
segfaults due to stale references to freed memory via mips_hi16.data.
A number of the error/warning handlers in ldmain.c use %C. This can
cause debug info to be parsed for the first time in order to print
file/function/line. If one of those warnings is triggered after some
hi16 relocs have been processed but before the matching lo16 reloc is
handled, *and* the debug info is corrupted with a lo16 reloc, then the
mips_hi16_list will be flushed with the result that printing a warning
changes linker output. It is also possible that corrupted debug info
adds to the hi16 list, with the result that when the linker handles a
later lo16 reloc in a text section, ld will segfault accessing
mips_hi16.data after the debug buffers have be freed. Both of these
problems are fixed by keeping a per-section mips_hi16_list rather than
a per-file list.
* elfxx-mips.c (struct mips_hi16): Move earlier, deleting
input_section field.
(struct _mips_elf_section_data): Add mips_hi16_list.
(struct mips_elf_obj_tdata): Delete mips_hi16_list.
(_bfd_mips_elf_free_cached_info): Adjust to suit new location
of mips_hi16_list.
(_bfd_mips_elf_hi16_reloc, _bfd_mips_elf_lo16_reloc): Likewise.
(_bfd_mips_elf_orphan_shr16_reloc): Likewise.
(mips_elf_free_hi16_list): Likewise.
(_bfd_mips_elf_finalize_section_relocs): Likewise.
(_bfd_elf_mips_get_relocated_section_contents): Likewise.
Add GAS and LD test cases for orphan REL HI16 relocation processing,
including verification of the addends produced as well as the warning
messages expected.
Due to the ordering used for the list of oustanding cached HI16 reloc
entries warnings for non-ELF links are issued in the reverse order
compared to one for ELF links. This is not considered a defect as all
the required warnings are produced in both cases, however separate
warning lists are required and included here for ELF and srec output.
Correct the addend being ignored for orphan REL HI16 relocations.
For assembly and non-ELF links `_bfd_mips_elf_hi16_reloc' is called from
`bfd_install_relocation' and `bfd_perform_relocation' respectively via
the respective howtos. It caches the relocation for later processing as
`_bfd_mips_elf_lo16_reloc' is called via the corresponding LO16 reloc's
howto, at which point both the HI16 and the LO16 parts are calculated
and installed.
If no matching LO16 relocation has been later encountered, then the
cached entry is never processed, with the outstanding cached entries
silently dropped at the conclusion of processing, resulting in zero
addend being used for the field relocated.
Dropping of the entries only happens in `_bfd_mips_elf_free_cached_info'
at the time the BFD is being successfully closed and section contents
long written to output. For non-ELF links dropping will also execute in
`_bfd_elf_mips_get_relocated_section_contents' via a separate piece of
code if the function has encountered an error.
Address the issues first by factoring out code to process outstanding
cached entries to `mips_elf_free_hi16_list' and then by making the
function actually install the relocations cached as required. This has
to happen before section contents have been written and therefore the
success path wires the function call to `bfd_finalize_section_relocs',
for assembly and `_bfd_elf_mips_get_relocated_section_contents' for
non-ELF links.
For housekeeping purposes the latter call will just drop cached entries
as it happens now in the case of an error, and likewise the call from
`_bfd_mips_elf_free_cached_info' is retained in case a fatal error in
the assembler prevents `bfd_finalize_section_relocs' from being called.
This also results in a warning being issued now about orphan REL HI16
relocations encountered in non-ELF links. Previously no such warning
was produced since the cached entries were dropped. For assembly we
expect the tool to have issued its own warning, so we process orphan
relocations silently if successful, but still issue a warning if an
error is returned.
We are careful in `mips_elf_free_hi16_list' to retain any incoming BFD
error as the function may be called under an error condition and if
there's another failure in processing at this stage we don't want to
clobber the original error.
Test cases will be added with a separate change.
Correct the addend being ignored for orphan REL HI16 relocations.
For ELF links `_bfd_mips_elf_relocate_section' handles relocation and
uses `mips_elf_add_lo16_rel_addend' to shift the incoming HI16 in-place
addend into its intended [31:16] bit positions and combine it with the
LO16 part. If no matching LO16 reloc has been found, then the function
returns early and consequently the incoming HI16 addend is not shifted
and remains in bits [0:15]. For final links any value of the symbol
referred is then added. Then the final value is shifted back into bits
[0:15] for installation into the field relocated. It is obviously wrong
as the original HI16 in-place addend has now been lost.
Fix the issue by shifting the incoming HI16 in-place addend before using
`mips_elf_next_relocation' to find the matching LO16 relocation. Then
upon early return from `mips_elf_add_lo16_rel_addend' the addend is in
the intended [31:16] bit positions already.
Test cases will be added with a separate change.
Use the warning callback for the orphan REL HI16 relocation warning just
as with any other linker relocation processing warnings, standardizing
the message format and providing source location where available.
Test cases will be added with a separate change.
Ever since commit 749b8d9d45 ("PATCH: ld/4208: `final link failed: Bad
value' when building Linux MIPS kernels."), which went in back in 2007,
<https://inbox.sourceware.org/binutils/20070320043504.GA7735@lucon.org/>,
we've been warning about unmatched HI16 REL relocations in the linker,
as it has been concluded in the discussion on PR ld/4208 that we have no
need to be forgiving about compiler bugs that lead to object files to be
made that are not compliant with the psABI.
However no corresponding update has ever been made to GAS, despite that
it's always helpful to issue a warning as early as possible in the build
process. In this particular case GAS also has more information to hand
as it always has the full original addend available that has been used
for both the high-part and the low-part relocation, while the linker has
to rely on the in-place value stored in the relocatable field by earlier
processing, which has necessarily been truncated. Therefore the linker
may miss cases where unrelated high-part and low-part relocations have
been put next to each other that had significantly different addends at
assembly time (small differences are deliberately permitted where they
are known not to affect any borrow from the high part).
Additionally GAS is able to point at the exact place in sources where
any offending orphan relocations have been used.
Update GAS to issue the warning then where applicable and remove an old
comment referring to GCC producing orphan HI16 relocations.
Test cases will be added with a separate change.
Update `bfd_finalize_section_relocs' to return status so that backends
can fail in this interface and propagate that to the respective callers.
Add suitable error reporting there. No failure cases in the existing
handlers though.
The `*_set_reloc' interface is to be called at the conclusion of section
relocation processing, however its name reflects a particular action to
take rather than the context of invocation. Implementation is already
backend-specific.
Rename the interface such as not to make its name artificially limit the
intended purpose. Update the callers and documentation accordingly. No
functional change.
Fold a separate call to `bfd_set_reloc' into SET_SECTION_RELOCS itself,
so that the GAS interface to this facility is contained in a single
invocation.
Currently both `write_relocs' and `obj_mach_o_reorder_section_relocs'
call `bfd_set_reloc', causing the function to be called twice by Mach-O
targets, such as `i386-darwin', once before target-specific processing
and again afterwards, which is at the very least fragile in terms of
assuming that any actions made by the function on the first invocation
won't interfere with the final intended result.
Set the macro by default to a plain call to `bfd_set_reloc', letting
backends override the macro, with the requirement now to factor in a
call to said function at the appropriate time. Backends can choose
whether to call `bfd_set_reloc' first (such as COFF), or last (such as
Mach-O), or at any other point in relation to their own additional
actions.
Update the COFF variant accordingly, moving it to a new function for a
better code structure, retaining functionality.
This is in preparation for `bfd_set_reloc' to return an error status.
In test-case gdb.base/tls-dlobj.exp we use breakpoints to step through the
executable. The breakpoints are used only once, but they are permanent, so we
end up with 11 breakpoints, 10 of which of the form $srcfile:$n.
The executable loads and unloads shared libraries, triggering solib events in
gdb, which will re-set the breakpoints.
Setting a breakpoint of the form $srcfile:$n triggers a filename search that
iterates over all CUs in all objfiles for which we have debuginfo.
In case glibc debuginfo is installed, and in case we have a slow gdb, for
instance because of building with -O0 and Address Sanitizer, this might become
noticeable.
While it's a good idea to try to speed up this search (see for instance
PR33781), measuring this speed is not the point of this test-case, so fix this
by making the breakpoints temporary.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
