emxomf: long names in libraries gets the wrong dict entry and barfs

[dmik]

~Recently I run into a situation when GCC 4.4.2 generated an N_EXP stub for a local symbol (having a name like _T.3032 to be precise) which is an emitted inline function (static member of a class defined as declspec(dllexport)) in the object file.~

~Given the resulting .obj file, emxomf created an OMF export record for this symbol but the linker (WLINK here) failed with the 'unresolved export' message when creating a DLL out of this .obj which is not a surprise because _T.3032 isn't public at all (lacks .globl in the assembler file). I understand that creating OMF export records for such local symbols will never succeed so I changed it to not do that which solved the problem (the patch is attached).~

emxomf-03-fix-symbol-too-long.diff: Make sure the stripped down symbol name is used not only when performing an AOUT to OMF conversion for a single object file but also when converting the whole object library. Prior to this fix, an unstripped version of the symbol would go to the OMF library's dictionary which caused the 'Symbol too long' error and program termination.

[dmik]

I must say that although emxomf seems to behave incorrectly, it's not the first one to spank in the line. I also really wonder:

a) why this inline method is emitted as a separate function at all: the code is generated in -O2 mode which permits inlining (it's a very simple function that only contains return other_not_inline_static_function(args);) and more over, there are many properly inlined invocations of this very same method in this object file. Looks a bit like a GCC misfeature.

b) why the emx GCC plugin generates a N_EXP stub for it while it is not a public symbol. As far as I see, it does that because some internal name for this symbol starts with something like DLL_IMPORT_EXPORT_PREFIX"e." which suggests that it's actually just another consequence of same GCC bug as in a): in addition to erroneously making it partly inlined, it also erroneously makes it starting with this "e" prefix (I don't have GCC 4.4.2 sources ATM so I cannot check this).

P.S. JFYI, _T.3032 has n_type = N_TEXT in the object file, while other (working) dllexport symbols have N_EXT | N_TEXT.

[dmik]

emxomf with the patch

[dmik]

I attached the patched emxomf.exe here for those who bumps into the same problem since it's rather small. Tested it with GCC 3.3.5 CSD3 as well as GCC 4.4.2 built by Paul Smedley.

[dmik]

For some reason, GCC 4.4.2 prepends an asterisk ('*') to the symbols with the _System attribute when generating N_EXP stubs for them. This apparently confuses emxomf.exe and eventually breaks exporting of such symbols with declspec(dllexport). I'm attaching a new patch that fixes this, as well as the new binary (that contains all patches).

[dmik]

emxomf with all recent patches

[dmik]

Note that I also disabled informational warnings in emxomf regarding unknown stubs (related to the HLL debug info as I understand).

[dryeo]

This patched emxomf also fixed a build break in Mozilla where some symbols now have an at sign ('@') prefix.

[dmik]

A couple of new emxomf fixes and a fresh binary. Not related to the subject of this topic but jut to keep it in one place.

1. emxomf-03-fix-symbol-too-long.diff: Make sure the stripped down symbol name is used not only when performing an AOUT to OMF conversion for a single object file but also when converting the whole object library. Prior to this fix, an unstripped version of the symbol would go to the OMF library's dictionary which caused the 'Symbol too long' error and program termination.
2. emxomf-04-no-hll-warnings.diff: Suppress three remaining HLL debug info related warnings which make no sense for the end user and only annoy him.

[dmik]

emxomf with all recent patches

[bird]

This is a bug in the gcc port you're using really, but I'll see what I can do about the patches.

[bird]

The asterisk problem is a bug in the gcc port and should be fixed there and not in emxomf (emxomf-remove-asterisk.diff). A leading asterisk is used to indicate that the symbol should not have a leading underscore.

The _T.3032 export fix should be done in GCC, not emxomf. The behavior of emxomf+wlink is correct, i.e. the should fail when given bad input.

Disabling the stabs stuff isn't useful as it indicates that emxomf isn't producing the right HLL output. If anyone is annoyed by this, address the frustration into fixing the issue instead of hiding it.

The library w/ long names issue is valid. Will apply fix.

[bird]

(In [3729]) emxomf.c: applied emxomf-03-fix-symbol-too-long.diff with modifications and a fix (import lib). References #220.

[bird]

(In [3730]) 0.6: Backported r3729: emxomf.c: applied emxomf-03-fix-symbol-too-long.diff with modifications and a fix (import lib). Fixes #220.

[dmik]

JFYI, I created a GCC issue for the asterisk problem (emxomf-remove-asterisk.diff) here: ​https://github.com/psmedley/gcc/issues/9.

[dmik]

(Note: I didn't change the fields version, component and milestone: my Safari changed it for me for unknown reason an dI don't really know how to change it back, it reverts them to what you see above before I have an opportunity to press submit).

[dmik]

JFYI2: There is a new build of emxomf.exe in the libc-devel RPM package version 0.6.5-20 that contains emxomf-remove-asterisk.diff​ and also patches from #293 and #295.