Date: Sat, 30 Jan 2021 19:20:29 +0000 From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10 Message-ID: <bug-216316-29464-tBcvPcgDsT@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-216316-29464@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316 Michael Brown <mcb30@ipxe.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mcb30@ipxe.org --- Comment #7 from Michael Brown <mcb30@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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-216316-29464-tBcvPcgDsT>