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