lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Wellnhofer <>
Subject Re: [lucy-dev] OFFSET globals
Date Mon, 23 Apr 2012 15:50:26 GMT
On 23/04/2012 16:55, Marvin Humphrey wrote:
> On Mon, Apr 23, 2012 at 4:09 AM, Nick Wellnhofer<>  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]:
>      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 and 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.

Oh, great idea. This would make the implementation much cleaner. I think 
it crossed my mind, but I dismissed it for some reason. There's only a 
small problem I can see on platforms where we can't hide symbols: 
Between the loading of the DLL and the initialization of the parcel 
there will be a window during which the offsets will become 
uninitialized. This would cause problems with threads.


View raw message