[cxx-abi-dev] comparing type_infos (was Re: Patch for throw/catch problems)

[Mark Mitchell]

--On Wednesday, August 15, 2001 04:36:16 AM -0400 Jakub Jelinek 
<jakub at redhat.com> wrote:

> On Tue, Aug 14, 2001 at 04:08:49PM -0700, Mark Mitchell wrote:
>>
>> Comments about people complaining are valid.  Users trump theory.
>>
>> > And no, caching and prelinking don't help here since we're dealing
>> > with weak symbols.  Those can't be prelinked and wind up on the
>> > conflict list (which uses yet more runtime memory, btw) which gets
>> > resolved after the rest of prelinking is complete.
>> >
>>
>> I think I meant something more ambitious; you create a table of
>> what values to relocate into what absolute memory locations,
>> and squirrel them away (along with hashes/timestamps of the DSOs
>> you were using).  Then, when you load the program, you check that
>> all the hashes match and that your DSOs ended up at the addresses
>> you expected and then just blast in your dynamic relocations
>> using the saved values without bothering to parse the relocation
>> sections or without looking up any symbols.
>>
>> Would that work, in theory?
>
> That works in reality too

Good to know I've reinvented the wheel.

> What could trim the conflict list down substantially would be some kind of
> lazy virtual methods

Interesting idea.  But, you've spotted the major issue; a
pointer-to-member contains an implicit reference into the vtable; values
are looked up without being called.  I assume that the dynamic linker
smushes weak symbols together first and then does relocations only
against the survivors.  If we had thought of this we could have put
bits on the pointers-to-members to indicate whether they were resolved
or not.  Rats.

Nathan Meyers and I were discussing just this issue (Nathan, we're
talking about how to reduce dynamic relocations at program start) a
few days ago.  Nathan's belief (and this seems plausible) is that
most of the relocations aren't ever doing you any good; you're building
a KDE app to display a calendar and you're doing relocations that apply
to a class that implements the entire FTP protocol in a single widget,
say.  Does the prelinking stuff you refer to above try to analyze that?
If you could prove (perhaps with additional compiler assistance) that lots
of stuff in this DSO doesn't matter, and just not relocate it at all,
that might be a big win.

Also, do we take advantage of mapping the same DSOs at the same
virtual addresses across processes?  If libkdecore.so is mapped
at the same address in three processes, it's possible that all three
could actually share the same instance; relocations would only have
to be done the first time.  Even if in general you cannot prove this
is safe, it might be that for some DSOs the DSO-builder could make
that assertion.

I am now wandering into la-la land, I know.

-- 
Mark Mitchell                mark at codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com