Re: eu-strip --reloc-debug-sections

[Roland McGrath <roland at hack dot frob dot com>]

> But I got a s390x testcase and I see you are right. BTW that really
> looks somewhat inefficient. It creates a new symbol for each relocation,
> but keeps the addend zero. So there are hundreds of relocations, all
> with their own symbol, which all look like:
>   0x000000000000f9cc  390_32      0x0000000000005446  +0 .LASF1542

Yes, I don't think I was ever satisfied that it had any good reason for
doing this.  But it does.  I'm not sure if it's as simple as --keep-locals
being the default for the s390 assembler (or equivalent internal rules), or
if it's weirder than that.  But we are in the business of cleaning up after
binutils, whether or not we also get binutils to produce less crap.

> So for s390 it even would make sense to remove all these symbols, since
> they are only used for the relocations anyway. But I don't think I will
> bother with that for now. I'll add the s390x testcase and rewrite the
> code to just use any symbol value in the section.

There is an argument to be made for removing all symbols in non-allocated
sections.  It should probably be a separate flag.  There's no real reason
to do this without removing relocs too, but the spiffy implementation of
that flag combination would be to turn them all into section-relative relocs.

> That was indeed kind of deliberate. The cross-debug-section relocations
> made up 95% of all relocations (really, almost everything comes from DIE
> names, which point into .debug_str). And in theory these relocations can
> be reversed if really wanted by just parsing the dwarf structures and
> reintroducing them. Admittedly, it is unlikely anybody really wants
> that. But at least it was clear what these relocations really are about.
> Which made convincing myself that the changes were correct and testing
> easier. There is a theoretical chance something uses other ~SHF_ALLOC
> sections in an unforeseen way. The gain just seemed too little to care
> about it. But I am not against doing it if you think having a
> --reloc-non-alloc-sections option is more useful/natural.

I can see both sides.  I guess I don't really feel that strongly about it.
But if you do add a symbol-removing pass, then I really think that is best
done based on SHF_ALLOC rather than making it more fiddly.  And in that
case, having the reloc application rule be consistent makes some sense.


Thanks,
Roland