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