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

[Indu Bhagat]

On 6/13/25 5:53 AM, Jan Beulich wrote:
> On 13.06.2025 09:32, Indu Bhagat wrote:
>> From: Jens Remus <jremus@linux.ibm.com>
>>
>> For relocatable links the output .sframe section size may be wrong.
>> This can be observed when dumping the SFrame information from the x86-64
>> sframe-reloc-1 test:
>>
>> Name              Address          Off    Size
>> .sframe           0000000000000000 000110 00007f
>>
>> Offset            Type               Symbol's Value  Symbol's Name + Addend
>> 000000000000001c  R_X86_64_PC32      0000000000000000 .text + 1c
>> 0000000000000030  R_X86_64_PC32      0000000000000000 .text + 65
>>
>> 0x00000000 e2de0201 0300f800 02000000 08000000 ................
>> 0x00000010 1e000000 00000000 28000000 00000000 ........(.......
>> 0x00000020 35000000 00000000 04000000 00000000 5...............
>> 0x00000030 00000000 25000000 0f000000 04000000 ....%...........
>>              offset 1st FRE---^^^^^^^^ ^^^^^^^^---number of FREs
>> 0x00000040 00000000 00030801 0510f004 0410f034 ...............4
>> FDE info---^^      | begin of FDEs
>> 0x00000050 0508f000 03080105 10f00404 10f02405 ..............$.
>>                   11111112222222223333333334444---FRE 1, 2, 3, 4
>> 0x00000060 08f00000 00000000 00000000 00000000 ................
>>             4444^^^^...
>> 0x00000070 00000000 00000000 00000000 000000   ...............
>>                                     ...^^^^^^---excessive section
>>
>> When running the x86-64 test cross build on a big-endian system, such
>> as s390x, objdump and readelf fail to dump the SFrame information with
>> the following error message:
>>
>> Error: SFrame decode failure: Buffer does not contain SFrame data.
>>
>> This is because the following check in flip_sframe() fails, which gets
>> only invoked if the endianness of the SFrame data is different from the
>> host system one:
>>
>> /* All FDEs and FREs must have been endian flipped by now.  */
>> if ((j != ihp->sfh_num_fres) || (bytes_flipped != (buf_size - hdrsz)))
>>                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> With:
>> j=8, ihp->sfh_num_fres=8, bytes_flipped=70, buf_size=127, hdrsz=28
> 
> All of this describes the symptom pretty extensively. However, ...
> 
>> --- a/bfd/elf-sframe.c
>> +++ b/bfd/elf-sframe.c
>> @@ -660,13 +660,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.  */
> 
> ... it doesn't become clear in how far this comment was wrong, and hence
> why for relocatable links the size also needs updating. (And yes, the
> connection between "has been relocated" and "size needs updating" looks
> suspect to me, but what's wrong with that wants calling out imo.)
> 

I do not recall why this comment was added originally, and I cannot make 
sense of this one now either.  I dont see the connection between "do not 
update size" because the "contents have not been relocated" ATM...

> Furthermore I'd expect a wrong section size to also manifest (as a
> problem) when endian-ness is the same between host and target. Is there
> some other issue lurking somewhere?
> 

For the relocatable links, SFrame section sizes were more than the 
actual data written in bytes.

In SFrame sections, there is an offset (sfh_fre_len) in the SFrame 
header that indicate the length of the last (variable length) 
sub-section.  Whether or not the size of section poses an issue depends 
on the reader I think.  E.g., the current readers (SFrame decoder 
object, dumper) were not going over to read the non-valid-data bytes for 
the case when no endian swap was needed.  For the case when endian swap 
is needed, Jens proposed a change 
https://sourceware.org/pipermail/binutils/2025-June/141519.html which 
will make it in soon.