This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: vtrelocs: large/modular C++ app speedup ...
- From: Michael Meeks <michael dot meeks at novell dot com>
- To: Ian Lance Taylor <iant at google dot com>, Andi Kleen <andi at firstfloor dot org>
- Cc: binutils at sources dot redhat dot com, libc-alpha at sources dot redhat dot com, gcc at gcc dot gnu dot org
- Date: Wed, 02 Apr 2008 17:19:03 +0100
- Subject: Re: vtrelocs: large/modular C++ app speedup ...
- References: <1207135768.31285.26.camel@t60sled.site> <m3k5jgjofi.fsf@google.com>
- Reply-to: michael dot meeks at novell dot com
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.
--
michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot