This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] - objcopy --extract-symbol clears e_flags ELF header field
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: Ronald Hoogenboom <hoogenboom30 at zonnet dot nl>, binutils at sourceware dot org
- Date: Sun, 18 Oct 2015 15:59:45 -0400 (EDT)
- Subject: Re: [PATCH] - objcopy --extract-symbol clears e_flags ELF header field
- Authentication-results: sourceware.org; auth=none
- References: <561D44BC dot 9080307 at atom dot grundel> <20151014002120 dot GK4434 at bubble dot grove dot modra dot org> <561EB0A7 dot 9000402 at atom dot grundel> <20151015130648 dot GA13961 at bubble dot grove dot modra dot org> <alpine dot BSF dot 2 dot 02 dot 1510180506480 dot 83989 at arjuna dot pair dot com>
I keep talking to myself:
On Sun, 18 Oct 2015, Hans-Peter Nilsson wrote:
> That's because objcopy --extract-symbol hacks in a start-address
> 0 instead of letting it be or consulting the target (new
> framework may be needed). Why does it change the start-address?
> The symbols are left, so why zero the start-adress; why is that
> more logical than keeping it when removing all contents?
> If the answer is ELF-related, I think it'd be up to ELF bits to
> handle the start-address-zeroing.
Sigh. It's deliberate and documented. Alas, already in the
original post from 2007 it is mentioned that the actual reasons
are historical and unknown. :(
Though, the start-address part is *not* tested by the added
testcases (AFAICS without hacking).
It was also deliberate (and mentioned in the ChangeLog) at the
time to not copy private BFD data, but at least that part wasn't
documented. :P (Not that I can think of a reason to thus deny
the target to fix and check target-specific output-format
consistensies.) I guess I'll just have to hack mmo.c to not do
the start-address = Main check if there's no section contents,
using that hook.
brgds, H-P