------- Comment #1 from davek at gcc dot gnu dot org 2010-05-15 09:06 -------
(In reply to comment #0)
> Windows targets that use emutls add a "." character as a separator from the
> _emutls_{t,v} and the true symbol name. However, exporting these symbol names
> from a DLL is problematic (i.e. a thread local data variable), because the "."
> in the symbol name tells the Windows loader to treat the symbol as a
> forwarding
> RVA to a second DLL (in this case, it will look for the symbol "varname" in
> __emutls_v.dll, the symbol exported is __emutls_v.varname). Note that this is
> a runtime issue, not a compile/link issue.
I think it's actually a link time issue after all, and we could be going to
dodge a bullet re: having to break backward compatibility here. The PE spec
has this to say about forwarded exports (pe coff spec rev. 8, 6.3.2):
" Each entry in the export address table is a field that uses one of two
formats in the following table. If the address specified is not within the
export section (as defined by the address and length that are indicated in the
optional header), the field is an export RVA, which is an actual address in
code or data. Otherwise, the field is a forwarder RVA, which names a symbol in
another DLL. "
In other words, I don't think the runtime loader actually keys off the presence
of a dot in the exported symbol, but where the EAT entry points to. If we can
persuade ld that sometimes a dot in a .DEF file symbol listing is indeed just a
dot, and not a forwarder definition, it should be able to generate a regular
EAT entry pointing at the exported symbol, rather than placing an ASCII string
in the export section and pointing the EAT entry at it, and hopefully
everything should "just work".
I'll test if this works by crudely hacking ld about a bit before thinking about
how we should implement this in terms of interface. We might be able to get
away without changing the compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
