Re: RFC: MIPS .reginfo section and objcopy --extract-symbols

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Mon, 11 Jan 2016, Nick Clifton wrote:
> Hi Guys,
>
>   MIPS targets currently fail the linker's extract symbols test (in
>   ld-scripts).  This is because the stripped executable contains a
>   zero-length .reginfo section.  Such a section is invalid for a MIPS
>   ELF file, and so the MIPS backend refuses to recognise it.  This in
>   turn leads bfd_section_from_shdr() to complain about an unhandled
>   processor specific section, and so the test fails.
>
>   The --extract-symbols option to objcopy (or strip) is specifically
>   documented to remove all section data, but I am wondering if this is
>   the right thing to do for processor specific or OS specific sections.
>   As the MIPS test has shown a zero length target specific section may
>   be invalid, rendering the entire file illegal.
>
>   I have a patch to objcopy which will preserve target specific sections
>   when --extract-symbols is in effect, but I am wondering if this change
>   might break something.  It would certainly change the sematics of the
>   extract symbols operation, albeit is a subtle way.
>
>   Comments, suggestions ?

I don't think --extract-symbols has a known use-case so you're
in for a challenge to verify any semantics changes.  IIUC from
digging when it bit me some time ago, it was added to support
some vxworks processing, but exactly what, was lost already at
code submission.
<http://sourceware.org/ml/binutils/2015-10/msg00148.html>

brgds, H-P