On 04/20/2012 03:59 PM, H. Peter Anvin wrote:
On 04/20/2012 03:41 PM, David Daney wrote:
From: David Daney<david.daney@xxxxxxxxxx>
If there are relocations on the __ex_table section, they must be fixed
up after the table is sorted.
Also use the unaligned safe accessors from tools/{be,le}_byteshift.h
Signed-off-by: David Daney<david.daney@xxxxxxxxxx>
---
This should address HPA's concerns about the i386 relocations. The
i386 kernel still boots after the sort, but I don't know how to test
the relocations, but they sure do look nice! My MIPS64 kernels still
boot too, so that is also good.
Hi...
This works for absolute relocations of the REL type, but not for
relocations of the RELA type nor for non-absolute relocations (moving
those changes the meaning.)
The program explicitly only handles MIPS and x86.
x86_64 and MIPS never have relocations, and x86_32 is always REL, so
that is handled
Also x86_32 is only emitting R_386_32 and those are handled.
I think Linus is right and the right thing to do is to switch to using
relative entries in the exception table; I am currently testing a
patchset to do exactly that (on x86). It also has the benefit of making
the table half the size on x86-64. Then we can just zero out the
.rel[a]__ex_table section and be done with it.
That's fine.
In any event we want to do build time sorting, this patch improves the
original sortextable, so may be worthwhile as purely a cleanup. I
wanted to fix the relocation breakage, even if the eventual solution
needs to be somewhat different.
The trick, of course, is that sorting a relative table is slightly
different than sorting an absolute table -- the way I'm doing it for the
in-kernel sorter (still needed for modules) is to add the intra-section
offset to each entry (both sides) before sorting, then doing a *signed*
sort, then denormalize again. Alpha does it differently, with custom
compare and swap routines.
-hpa
