I should insert a disclaimer at this point: I don't fully grok weak symbols.
What I know is what I've gathered from some googling, browsing the (very old
and I don't know in what ways outdated) copy of the gABI docs at the old
caldera site, and skimming the Codesourcery ABI pages.
Right, now on with throwing myself in at the deep end:
Brian Dessent wrote on 15 September 2008 07:01:
> "Yaakov (Cygwin Ports)" wrote:
>
>> OTOH, I really would like to see a dynamic libstdc++6 for 1.7. So my
>> question is, how far off is a real fix to binutils, and if it's not
>> around the corner, will this workaround be compatible with the binutils
>> fix when it does happen?
>
> I haven't seen a plan outlined yet for how you'd solve this generically
> and I rather doubt it's possible without special casing or otherwise
> modifying the original code. Like Dave said
[ ... ]
> add indirection
> in the form of thunks and some kind of runtime support in the startup
> code
Yep, that's more-or-less what I was referring to by "stunk thubbery" ;-)
Ok: here's how PE pseudo-weak support currently works: when you build an
object containing a weakly-defined function, the assembler emits the function
renamed to some random new name, and a weak alias for the true name that
points at the random new name.
This works when you've got a weakly defined symbol in a DLL and a
strongly-defined function in the main .exe, because the strong version
overrides the weak symbol from the dll. So the exe calls the strong version
of the function. Similarly, if there's a strong version in a different DLL,
that's the one the linker will resolve the .exe's reference against.
The problem is that DLLs must be fully resolved when they are linked, and
that means that if there's nothing else for it to link against, the internal
references from the DLL to weak functions have to be resolved by the weak
alias.
This would be the point at which to interpose a thunk. (Actually, it could
maybe be done by a static function in the .dll.a import library, although that
would only handle the case when linking against the import library and not
when linking directly against the DLL).
The job of the thunk would be to do some kind of runtime lookup, and fall
back to calling the true function == the PE alias for the randomly-renamed
internal version, at that stage. (It would be a sensible option to consider
making the thunk simply load a pointer to a symbol name, and have the bulk of
the code in the runtime library somewhere. Shared libgcc springs to mind.)
This thunk can do pretty much anything it needs to find a pointer to the
strong definition of the symbol (well, in fact, it just needs to find any
strong version if there's more than one, IIRC ELF doesn't guarantee which one
gets picked if you try and mix multiple strong definitions. But in that event
it would seem to me probably best to pick one from the EXE first, ahead of any
from DLLs). So it can walk the list of modules and check export tables and
things like that if it needs, it can even modify import and export tables if
we want, conceivably we could go so far as to re-apply relocs.
The final piece of the puzzle is this: we need to make sure that the strong
definitions are always exported, because otherwise our runtime thunk won't be
able to find them. Perhaps we just want to export all strongly defined
functions under an alias, that will be ignored in the normal course of events?
Well, this is all just a vague plan in my head so far, and I imagine it'll
all fall apart when I realise the loopholes, but I haven't planned it out in
full enough detail to understand what would go wrong yet. I guess I should
post RFDs to some combination of here, mingw, gcc and binutils lists when I've
got it a bit more concrete.
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
