Hi Ian / Andi,
On Wed, 2008-04-02 at 07:56 -0700, Ian Lance Taylor wrote:
> * Use GNU instead of SUSE, as this is for the GNU tools.
Ah yes; you noticed the subliminal advertising ;-) If you're happy for
me to trample on the GNU section namespace that's fine, but I hesitate
to tread there by default.
> * Don't check for explicit section names. Instead, give the section a
> magic type.
> * It seems that this is not backward compatible--an executable built
> in this way will not work if the dynamic linker does not know about
> it. The section should have the SHF_OS_NONCONFORMING bit set.
Not clear how to fix either of those :-) I binned a redundant string
section name lookup in the binutils patch though.
> * Aren't you going to get a lot of duplicate vtreloc entries?
> Shouldn't they be grouped with the vtables themselves?
That's entirely possible; perhaps I misunderstand the question, but had
I hoped that by making the _ZVTR_ section weak the linker would discard
any duplicate vtreloc records for the same vtable.
> * The idea is useless without support in the dynamic linker, so you
> need to get signoff there first.
Naturally :-)
On Wed, 2008-04-02 at 17:06 +0200, Andi Kleen wrote:
> I wonder if it could be made backwards compatible. As in keep the old
> style relocations too, but the new linker would not process them
> when seeing the new special relocations.
It's certainly possible; of course it looses you any size savings. I
imagine that using the dynsort code we could shuffle the relevant relocs
to the end of the list fairly easily - that is if we could identify
whether they overlapped with the vtrelocs (or not): perhaps some big
bit-mask for the whole data section or something (?).
Thanks,
Michael.
--
[EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot
