[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets

[davek at gcc dot gnu dot org]

------- Comment #2 from davek at gcc dot gnu dot org  2010-05-15 09:34 -------
(In reply to comment #1)

> 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".

Theory confirmed by applying the following gross hack to src/ld/pe-dll.c:
Index: ld/pe-dll.c
===================================================================
RCS file: /cvs/src/src/ld/pe-dll.c,v
retrieving revision 1.129
diff -p -u -r1.129 pe-dll.c
--- ld/pe-dll.c 28 Apr 2010 15:24:22 -0000      1.129
+++ ld/pe-dll.c 15 May 2010 09:32:37 -0000
@@ -867,7 +867,7 @@ process_def_file_and_drectve (bfd *abfd
       char *name;

       /* Check for forward exports */
-      if (strchr (pe_def_file->exports[i].internal_name, '.'))
+      if (0 && strchr (pe_def_file->exports[i].internal_name, '.'))
        {
          count_exported++;
          if (!pe_def_file->exports[i].flag_noname)

Will attach the trivial testcase I tried it against.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139