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

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Hans-Peter Nilsson <hp@bitrange.com> writes:
> 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>

To what extent can we really consider an ELF that has been through the
--extract-symbols logic to represent anything ABI compliant?

My perspective is that the resulting ELF is nothing more than a
convenient container for symbol information. Would it be feasible to
completely remove sections rather than just their content?

We have to support weird and wonderful ELF files in tools because we
can't constrain what users may want to do when squeezing every last byte
out of their system. This means that a MIPS ELF with all the processor
specific sections removed is accepted as valid in the tools albeit
missing some information that the MIPS ABI would normally mandate.
Corrupt special sections are a different matter though and raising
errors for such cases seems reasonable.

Thanks,
Matthew