Add an --extract-symbol option to objcopy

[Richard Sandiford]

Alan Modra <amodra@bigpond.net.au> writes:
> On Thu, Mar 01, 2007 at 01:00:13PM +0000, Richard Sandiford wrote:
>> This is unfortunately one of those patches that is being submitted
>> upstream long after it has been used in the wild (namely for VxWorks).
>
> Also unfortunately, it looks like this option has never worked very
> well.  Against binutils built from source just after this was
> committed:
>
> $ gcc -o hello /src/tmp/hello.c
> $ binutils/objcopy --extract-symbol hello hello.sym
> BFD: BFD (GNU Binutils) 2.17.50.20070302 assertion fail /src/binutils-local/bfd/elf.c:5698
>
> We now have http://sourceware.org/bugzilla/show_bug.cgi?id=6774

'Fraid this was a case of an option for a specific purpose.
The real VxWorks test was: does this work with a VxWorks kernel?
I could swear I tested that with HEAD binutils of the day,
and I think CS since used FSF binutils as the basis for a
VxWorks release.  But this was almost 18 months ago,
so I could be wrong.

> I've just committed a patch to cure the silly ELF headers that
> "objcopy --extract-symbol" generates, but I think some further changes
> are necessary.
>
> Firstly, when used on relocatable files I reckon there isn't much
> point in keeping the relocations.  Hence the copy_section change
> below.  Secondly, I don't see any real purpose in keeping the ELF
> program headers when "objcopy --extract-symbol" is used on
> executables.  Since we've lost the section contents, the headers ought
> to go too.  Fixed by not calling setup_bfd_headers.  Finally, why
> should the section vma/lma be set to zero, which changes section
> symbol value?

I don't know, sorry.  I think even when I submitted this, the reasons
for the option being the way it was had been lost in the mists of time.

Richard