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

[Jan Beulich]

On 02.12.2024 15:16, Andre Vieira (lists) wrote:
> This RFC 'fixes' the issue described in PR32324, but I doubt this is the 
> right thing to do.  I am not at all familiar with this piece of code but 
> it looked wrong for the offset after objcopy to be lower than the 
> 'Align' value, whereas all other headers seem to have an 'Offset' that 
> is larger than their 'Align'.
> Debugging this also hinted that had the offset been the same as 'Align' 
> and in fact the original 'Offset' then everything would fall in place.
> 
> (deleted some leading 0s so it would fit in 80-char line).
> Before objcopy/strip:
>    Type           Offset             VirtAddr           PhysAddr
>                   FileSiz            MemSiz              Flags  Align
> ...
>    LOAD           0x00000000200000 0x00000000600000 0x00000000600000
>                   0x0000000040467c 0x0000000040467c  R E    0x200000
> 
> After objcopy/strip:
>    Type           Offset             VirtAddr           PhysAddr
>                   FileSiz            MemSiz              Flags  Align
> ...
>    LOAD           0x00000000030120 0x00000000430120 0x00000000600000
>                   0x0000000040467c 0x0000000040467c  R E    0x200000

Neither here nor in the bug report a complete picture is presented. I
don't think providing the info for just a single segment / section can
suffice. What's more, in the PR you mention the input image is the
result of some other tool's optimization. Pre-optimized image data may
also be relevant, especially as long as we can't exclude there's an
issue with that optimization (as you hint at as a possibility in the
PR).

Therefore can you please provide at least a full program and section
header dump from the one binary in question, for all three states of
it (pre optimization, post optimization, and post stripping)? Ideally
you'd make available a shrunk down testcase, for people (like me) to
actually play with.

> So I decided to try this hack for now and for this case it seems to work 
> for the binary I was using to reproduce this.
> This is just intended as breadcrumbs for the next person to pick this up.
> 
> My reasoning was that I was seeing that the p_offset and p_vaddr of the 
> Header where things went wrong was much lower than the original, however 
> the section addresses were not, so some sections were no longer fitting 
> in this Segment and were being moved to the next one and eventually we 
> ran out of space for some Sections, hence the warnings.

Right, except that I don't think it makes much sense to special case
offsets below p_align. p_align, after all, says nothing about full
addresses, but is just about requirements towards their low bits.

Jan