[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316

Michael Brown <mcb30 at ipxe.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mcb30 at ipxe.org

--- Comment #7 from Michael Brown <mcb30 at ipxe.org> ---
I have updated the iPXE build process to place the (meaningless) load addresses
for the various NOLOAD sections earlier than the .zinfo section.  This change
is in commit https://github.com/ipxe/ipxe/commit/fe52f8e8b and eliminates the
harmless "moving loadable section" warning.

However, there seems to be something else very broken in the elftoolchain
implementation of "objcopy -O binary".  Extracting a single section using e.g.

  objcopy -O binary -j .zinfo bin/ipxe.pxe.tmp bin/ipxe.pxe.zinfo

works as expected.  Extracting multiple sections using e.g.

  objcopy -O binary -R .zinfo bin/ipxe.pxe.tmp bin/ipxe.pxe.bin

or even just

  objcopy -O binary bin/ipxe.pxe.tmp wtf

produces a binary file with no discernible relation to the input.  It looks
vaguely as though objcopy is ignoring the load addresses and just placing the
sections semi-randomly within the output file.

For now, I've modified the iPXE build process to check for the elftoolchain
version of objcopy and refuse to use it
(https://github.com/ipxe/ipxe/commit/1fea8ce06).

It would be good to get a proper fix for this, if anyone has time to dig into
how the elftoolchain objcopy is handling "-O binary".

Michael

-- 
You are receiving this mail because:
You are the assignee for the bug.