Home Original page

[PATCH, V4 9/9] ld: bfd: sframe: Update section size also for relocatable links

Jens Remus jremus@linux.ibm.com
Wed Jun 25 11:43:09 GMT 2025 
Hello Indu!

On 19.06.2025 08:24, Indu Bhagat via Binutils wrote:
> From: Jens Remus <jremus@linux.ibm.com>
> 
> For relocatable links the output .sframe section size may be wrong.
...
> bfd/
> 	* elf-sframe.c (_bfd_elf_write_section_sframe): Update section
> 	size also for relocatable links.
> 
> Signed-off-by: Jens Remus <jremus@linux.ibm.com>

> diff --git a/bfd/elf-sframe.c b/bfd/elf-sframe.c
> index 0a2c4695c21..6dfe7053c73 100644
> --- a/bfd/elf-sframe.c
> +++ b/bfd/elf-sframe.c
> @@ -665,13 +665,11 @@ _bfd_elf_write_section_sframe (bfd *abfd, struct bfd_link_info *info)
>  				 (file_ptr) sec->output_offset,
>  				 sec->size))
>      retval = false;
> -  else if (!bfd_link_relocatable (info))
> +  else
>      {
>        Elf_Internal_Shdr *hdr = &elf_section_data (sec)->this_hdr;
>        hdr->sh_size = sec->size;
>      }
> -  /* For relocatable links, do not update the section size as the section
> -     contents have not been relocated.  */
>  
>    sframe_encoder_free (&sfe_ctx);

In the process of re-creating my Glibc libc.so SFrame statistics for V3
of my s390x sframe support series I noticed that there are multiple
linker errors regarding the .sframe section in Glibc Scrt1.o (at lest on
s390x):

ld: error in .../glibc/build-sframe/csu/Scrt1.o(.sframe); no .sframe will be created

The reason is "missing SFrame decoder context".  Dumping the Scrt1.o
.sframe section reveals that it is "empty" (zeroed):

$ readelf -WS -x .sframe --sframe build-sframe/csu/Scrt1.o
Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 6] .sframe           PROGBITS        0000000000000000 0000b8 000020 00   A  0   0  8

Hex dump of section '.sframe':
  0x00000000 00000000 00000000 00000000 00000000 ................
  0x00000010 00000000 00000000 00000000 00000000 ................

readelf: Error: SFrame decode failure: Buffer does not contain SFrame data.

I immediately thought about this patch.  With (only!) this patch applied
one of the Glibc links fails as follows:

gcc -B/home/jremus/temp/binutils-sframe/bin -Wa,--gsframe   -nostdlib -nostartfiles -r -o /home/jremus/git/glibc/build-sframe/elf/librtld.os '-Wl,-(' /home/jremus/git/glibc/build-sframe/elf/dl-allobjs.os /home/jremus/git/glibc/build-sframe/elf/rtld-libc.a -lgcc '-Wl,-)' \
          -Wl,-Map,/home/jremus/git/glibc/build-sframe/elf/librtld.os.map
gcc -B/home/jremus/temp/binutils-sframe/bin -Wa,--gsframe   -nostdlib -nostartfiles -shared -o /home/jremus/git/glibc/build-sframe/elf/ld.so.new                \
          -Wl,-z,relro -Wl,-z,defs      \
           \
          /home/jremus/git/glibc/build-sframe/elf/librtld.os -Wl,--version-script=/home/jremus/git/glibc/build-sframe/ld.map            \
          -Wl,-soname=ld64.so.1
/home/jremus/temp/binutils-sframe/bin/ld: /home/jremus/git/glibc/build-sframe/elf/librtld.os(.sframe+0x2afc): reloc against `.text': error 4

With error code 4 indicating (note to self: might be worth to improve
this error message):

/* The address to relocate was not within the section supplied.  */
bfd_reloc_outofrange,

With your series applied (which includes this patch) resolves the issue,
as it corrects the rela r_offset values.  For this particular object it
now causes an empty .sframe section to be output, which is an improvement
but still not ideal:

$ readelf -WS -x .sframe --sframe build-sframe/csu/Scrt1.o
Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 6] .sframe           PROGBITS        0000000000000000 0000b8 000000 00   A  0   0  8

Section '.sframe' has no data to dump.

Section '.sframe' has no debugging data.

Any idea how this could be improved to not generate any .sframe section
in that case?  Not necessarily as part of this series, although it would
be a great fit.


The reason for the "empty" .sframe section is that Scrt1.o is produced
by the following relocatable link and only start.os has a .sframe
section, that only consists of a SFrame header (no FDEs and FREs):

gcc -Wa,--gsframe -nostdlib -nostartfiles -r -o .../build-sframe/csu/Scrt1.o .../build-sframe/csu/start.os .../build-sframe/csu/abi-note.o .../build-sframe/csu/init.o

$ readelf -WS -x .sframe --sframe build-sframe/csu/start.os
Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [17] .sframe           PROGBITS        0000000000000000 000210 000020 00   A  0   0  8

Hex dump of section '.sframe':
  0x00000000 dee20200 04000000 00000000 00000000 ................
  0x00000010 00000000 00000000 00000000 00000000 ................

Contents of the SFrame section .sframe:
  Header :

    Version: SFRAME_VERSION_2
    Flags: NONE
    Num FDEs: 0
    Num FREs: 0

  Function Index :

$ readelf -x .sframe --sframe build-sframe/csu/abi-note.o

readelf: Warning: Section '.sframe' was not dumped because it does not exist
readelf: Warning: Section '.sframe' was not dumped because it does not exist

$ readelf -x .sframe --sframe build-sframe/csu/init.o

readelf: Warning: Section '.sframe' was not dumped because it does not exist
readelf: Warning: Section '.sframe' was not dumped because it does not exist


The reason for the .sframe section without any FDEs and FREs is:

Warning: no SFrame FDE emitted; RA reg 14 in .cfi_undefined

Maybe it would be possible to improve the assembler not to generate
any .sframe section if there are no FDEs?  Not as part of this series
of course.

Thanks and regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
+49-7031-16-1128 Office
jremus@de.ibm.com

IBM

IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
More information about the Binutils mailing list