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

[Jan Beulich]

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. While I don't think I'm aware of a
place where it is written down what exact changes objcopy is expected /
permitted to make, it would seem to me that it shouldn't alter the
section-to-segment mapping. The two sections in question should remain
in segment 4. Doing so would feel like partial re-linking of the binary,
which pretty certainly isn't what objcopy is supposed to do (and even
less so strip).

Jan