Re: PR23611, objcopy is not removing executable relocatable sections

[Andrew Burgess <andrew dot burgess at embecosm dot com>]

* Michael Matz <matz@suse.de> [2018-09-14 12:51:12 +0000]:

> Hi,
> 
> On Wed, 12 Sep 2018, Andrew Burgess wrote:
> 
> > > Kamlesh's patch to make --remove-relocations remove all types of reloc
> > > section, but on reconsidering decided the existing behaviour was worth
> > > keeping despite needing to document it.
> > 
> > This is what puzzles me about this discussion.  You saw value in
> > --remove-relocations NOT being able to remove some relocation
> > sections?
> > 
> > What value can that possibly have?
> 
> relocations emitted by --emit-relocs into DSOs aren't necessary at runtime 
> (which is why they aren't emitted by default), dynamic relocations are.  
> As the latter are part of the process image they aren't actually just 
> placed in sections but also in segments.  You can't remove such pieces 
> easily, you could only nullify them.  If you do that the result will stop 
> working.  So I'd ask the opposite question: what value can removing 
> dynamic relocations possibly have?

I don't have an answer to that question, but I don't see the value in
asking the question.

Alan, did make --remove-section=... work for dynamic relocation
sections, that was the issue that triggered this whole email chain, so
making the point that removing dynamic relocations is weird or
pointless (though probably true) has very little to do with this
discussion.

Further, many of the options in objcopy can leave an object in a state
that might be considered weird or broken, for example
'--remove-section=.text'.  I see objcopy as a general purpose object
manipulation tool, I'd just like to present a consistent interface.

However, while thinking about this over the last couple of days I can
see one use case in which the restriction on not removing dynamic
relocations is helpful.

When relocations have been left in with --emit-relocs, if the user now
wants to remove them, but leave dynamic relocations in place, then,
'--remove-relocations=*' will do the job.  This at least provides some
reason for making the current choice.   The inconsistent interface
still irritates a little, but I'm sure that will pass with time :)

Thanks,
Andrew