PR23611, objcopy is not removing executable relocatable sections

Alan Modra amodra@gmail.com
Mon Sep 10 13:25:00 GMT 2018


On Mon, Sep 10, 2018 at 10:54:50AM +0100, Andrew Burgess wrote:
> * Alan Modra <amodra@gmail.com> [2018-09-10 14:02:27 +0930]:
> > When --remove-relocations was added to objcopy with commit
> > d3e5f6c8f1e, objcopy lost the ability to remove dynamic relocation
> > sections such as .rela.plt from executables using the option
> > "--remove-section=.rela.plt".  This patch reinstates that
> > functionality.
> > 
> > I thought it best to keep --remove-relocations as is, rather than
> > extending to handle dynamic relocations as per the patch in the PR,
> > because executables linked with --emit-relocs may have both dynamic
> > and non-dynamic relocations.  In that case --remove-relocataions=* is
> > useful to remove all the non-dynamic relocations.
> 
> I think having an option that removes _almost_ all relocation sections
> is going to cause user confusion.  Yes, we can document it, but if we
> can make it work for all relocation sections I think we probably
> should.

Removing dynamic relocation sections from an executable is such a
weird thing to do that I'm not overly concerned.  Also, they aren't
really removed.  What actually happens is that the section disappears
from the section headers and the contents are overwritten with zeros.
Contrast that with what happens to relocation sections in a
relocatable object, where the section is removed and other sections
take up its file space.

You also might like to inspect the output of
gcc -o hello -Wl,-z,nocombreloc,--emit-relocs hello.c
before you discount the utility of the current --remove-relocations
behaviour.  I call it a (perhaps accidental) feature rather than a bug
that the --emit-relocs created sections can be removed with
--remove-relocations.

> >  /* Wrapper for dealing with --remove-section (-R) command line arguments.
> >     A special case is detected here, if the user asks to remove a relocation
> >     section (one starting with ".rela." or ".rel.") then this removal must
> > -   be done using a different technique.  */
> > +   be done using a different technique in a relocatable object.  */
> 
> I'm not sure I agree with this comment, how about:

I agree that it's not 100% accurate, but it's near enough without
going into too much detail.

> As far as I can tell through experimenting things like .rela.text are
> always held as data off of the .text section no matter what the kind
> of object/executable.

Before -z combreloc we often saw .rela.data of the dynamic reloc kind
in an executable.

-- 
Alan Modra
Australia Development Lab, IBM



More information about the Binutils mailing list