On 23/04/2012 16:55, Marvin Humphrey wrote:
On Mon, Apr 23, 2012 at 4:09 AM, Nick Wellnhofer<[email protected]> 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.
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.
Nick
