[RFC] objcopy, elf: Align Header Offset [PR 32324]

[Jan Beulich]

On 17.12.2024 15:39, Jan Beulich wrote:
> On 03.12.2024 17:30, Andre Vieira (lists) wrote:
>> OK so I have a binary reproducer for you, it's just a nonsensical hello 
>> world with a loop to make it run for long enough for perf to create a 
>> record that actually captures something. I compressed it using gzip, so 
>> hopefully the mailing list accepts it.
>>
>> This binary was built on an aarch64-none-linux-gnu target, using a top 
>> of the trunk build of llvm-bolt and a gcc 11.4 with the following commands:
>> $ gcc hello.c fn.c -O2 -g -Wl,--emit-relocs 
>> -fno-reorder-blocks-and-partition
>> $ perf record -e cycles:u -o perf.data -- ./a.out
> 
> The original binary would also have been of interest.
> 
>> $ ./bolt_build/bin/perf2bolt -p perf.data -o perf.fdata -nl  ./a.out
>> $ ./bolt_build/bin/llvm-bolt ./a.out -o ./a-bolted.out -data perf.fdata 
>> -reorder-blocks=ext-tsp -reorder-functions=hfsort -split-functions 
>> -split-all-cold -split-eh -dyno-stats
>>
>> To reproduce the issue with GNU strip/objcopy it is sufficient to call:
>> $ objcopy a-bolted.out bad_copy
>> objcopy: bad_copy: section `.eh_frame' can't be allocated in segment 2
>> LOAD: .text .text.cold .eh_frame .eh_frame_hdr
>> objcopy: bad_copy: section `.eh_frame_hdr' can't be allocated in segment 2
>> LOAD: .text .text.cold .eh_frame .eh_frame_hdr
> 
> It looks to me as if the problem was that objcopy tries to move the two
> sections from segment 4 to segment 2.

That was a red herring. The diagnostic emits an internal loop counter,
making the number reported entirely meaningless. There's no moving of
sections between segments, afaict right now. Back to square 1.

Jan