Date: Sun, 31 Jan 2021 14:54:11 +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-7vncB96jtT@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 --- Comment #10 from Michael Brown <mcb30@ipxe.org> --- (In reply to Ed Maste from comment #8) >From looking at elfcopy/binary.c and its create_binary() function: it appears that elfcopy will use sh_offset to calculate the position within the final binary file (rather than the LMA or even the VMA). Since sh_offset is meaningless once the ELF headers have been stripped away, this behaviour is provably incorrect for anything other than extracting a single section via "-j <section>". Building elfcopy from source confirms this behaviour from the current code. So, we have three possible behaviours: 1. binutils objcopy Uses the section LMA to determine the offset within the output file. As above, I would say that this behaviour is correct. 2. FreeBSD objcopy as present in binary distributions Uses the section VMA to determine the offset within the output file. As above, I would say that this behaviour is wrong. 3. FreeBSD objcopy as built from source Uses the section sh_offset to determine the offset within the output file. This behaviour is very definitely wrong. I am puzzled why I get different behaviour from the FreeBSD binary and source distributions, particularly since the use of sh_offset appears to have been present since 2010. Michael -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-216316-29464-7vncB96jtT>