Issues on Sframe on LoongArch with Link Time Relexation

[Indu]

On 2025-09-18 6:00 a.m., Huang Pei wrote:
> Hi, everyone,
> 
> when I try to add Sframe support for LoongArch, it occurred to me
> that the current implementation assumed no code relaxation during
> link editing, which causes two issues:
> 
> +. ld triggered the "sframe_assert" from "sframe_decoder_get_fre",
> since the sfde_func_size (with R_LOONGARCH_{ADD32,SUB32}) is not
> resolved at the time because of link time relaxation.(This may
> not be an issue on RISC-V).
> 

Hi Huang,

SFrame merging is done after section relocation.  The 
_bfd_elf_merge_section_sframe () expects relocated section contents.  So 
if you are adding the R_LOONGARCH_{ADD32,SUB32}, this should have been 
resolved.

What sframe_assert are you hitting in sframe_decoder_get_fre ? It could 
be because of some emission problem in gas/sframe/loongaarch..

(Another thing that strikes me is that so far, SFrame sections have only 
had the PCREL relocations for SFrame FDE start addr, now if there are 
more relocations like R_LOONGARCH_{ADD32,SUB32} etc, some code 
adjustments may be necessary...)

What all relaxations are done by ld for loongarch ?  If there is a list 
somewhere that will be helpful. As insns change, we will need to make 
sure the IP offsets in the 'SFrame FRE start addr offsets' data are 
still correct.

> +. relax "rs_sframe" is not safe any more within gas, it need
> relocs on sfre_start_address, and delayed until link editing.
> 

The "rs_sframe" fragments in gas are handling two optimizations:

   /* We are dealing with two different kind of fragments here which need
      to be fixed up:
        - first, FRE start address in each FRE, and
        - second, Function info in each FDE (function info stores the 
FRE type)
      The two kind of fragments can be differentiated based on the opcode
      of the symbol.  */

Basically, we are finding out what is the max size of a function/code 
block between .cfi_startproc and .cfi_endproc, and then use that 
information to decide how many bytes are minimally needed to encode the 
data values of 'SFrame FRE start addr offsets', and the same information 
then is used to fix up the relevant bits in 'FDE->sfde_func_info'.

In presence of relaxation, the function size will not increase, will it 
?  Can you elaborate on why "rs_sframe" handling is not safe in presence 
in case of relaxation?

> -mno-relax(and -mthin-add-sub) in LoongArch gas can work around two
> issues, but any advice if not?
>