On Mon, 2011-05-23 at 13:43 -0700, Roland McGrath wrote:
Note that eu-unstrip already does this in some modes, though
roundabout way of getting there.
Yes, I wanted something that would just do the right thing at strip
time, so people didn't need an extra tool/step. Also eu-unstrip -R does
a bit more than I was after (but see below).
You don't want to constrain it to STT_SECTION symbols. Any
shndx is in a non-allocated section ought to be fine. Whether you see only
section-relative references or see symbols too depends on the tools and
machine (IIRC s390 gets a lot of symbol-relative relocations).
Too bad, it kept the code simple since I could just ignore the actual
symbol value was always zero, which made the ET_REL case almost
completely trivial. And in all the cases I saw the cross-debug-section
relocations use the STT_SECTION symbol of another debug section plus an
addend (either explicit in the RELA case, or already at the offset
location in the REL case).
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
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.
Also, I'm not sure that it matters to confine it to
is more in line with the name of the option, I suppose. But the essential
thing is that a reloc whose target is in any ~SHF_ALLOC section is a
"trivial" reloc, i.e. will be resolved to 0+addend by libdwfl/gdb.
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.