lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: [lucy-dev] OFFSET globals
Date Mon, 23 Apr 2012 14:55:04 GMT
On Mon, Apr 23, 2012 at 4:09 AM, Nick Wellnhofer <wellnhofer@aevum.de> wrote:
> On 23/04/2012 06:15, Marvin Humphrey wrote:

>>   * Generating headers suddenly get more complicated, because the content
>>     derived from each .cfh file will be different for each target parcel!
>>     Plus, things like METHOD and SUPER_METHOD will require parcel-specific
>>     implementations...
>
> This could be handled with defines:
>
> #define Lucy_Hash_Fetch_OFFSET ext_Hash_fetch_OFFSET

Hmm, wait a minute... I think that even on systems where we can't stop symbol
export, ELF symbol resolution rules may work in our favor and render this
complexity unnecessary.

My understanding is that in the event that two ELF DSOs export the same
symbol, the general rule is that the last library loaded wins[1]:

    http://www.akkadia.org/drepper/dsohowto.pdf

    Note that there can be many references to the same symbol in different
    objects. The result of the lookup can be different for each of the objects
    so there can be no short cuts except for caching results for a symbol in
    each object in case more than one relocation references the same symbol.
    The lookup scope mentioned in the steps below is an ordered list of a
    subset of the loaded objects which can be different for each object
    itself.

(I imagine symbol resolution of Mach-o DSOs on OS X follows similar rules.)

But if Clownfish.so and Lucy.so both export Cfish_Hash_Fetch_OFFSET, it
doesn't matter which copy of the var gets used so long as all copies get
initialized to the proper value during bootstrapping (and no method calls are
made during the boostrapping phase). The values of these OFFSET vars are
constant once bootstrapping completes.

The bootstrapping will work because there will only be a single canonical
copy of each VTable, and it will know the offsets.  Cyclic dependency graphs
are a problem, but that was already true regardless of visibility.

So I don't think symbol visibility matters unless there are systems out there
where we can't stop symbol export AND the dynamic loader crashes if it finds
multiple copies of the same symbol.  I'm not an expert on this subject (yet!),
but probably such a system does not exist.

Marvin Humphrey

[1] "How to Write Shared Libraries" by Ulrich Drepper, section 1.4.5.

Mime
View raw message