Opened 5 years ago

Closed 4 years ago

Last modified 4 weeks ago

#220 closed defect (fixed)

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

Reported by: dmik Owned by: bird
Priority: normal Milestone: libc-0.6.6
Component: libc Version: 0.6.5
Severity: normal Keywords:
Cc: dryeo

Description (last modified by bird)

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

Attachments (7)

emxomf-no-export-locals.diff (4.2 KB) - added by dmik 5 years ago.
emxomf-no-export-locals-2010-03-10.zip (63.8 KB) - added by dmik 5 years ago.
emxomf with the patch
emxomf-remove-asterisk.diff (794 bytes) - added by dmik 5 years ago.
emxomf-for-qt-2010-03-12.zip (63.3 KB) - added by dmik 5 years ago.
emxomf with all recent patches
emxomf-03-fix-symbol-too-long.diff (7.9 KB) - added by dmik 4 years ago.
emxomf-04-no-hll-warnings.diff (1.1 KB) - added by dmik 4 years ago.
emxomf-2010-08-10.zip (64.1 KB) - added by dmik 4 years ago.
emxomf with all recent patches

Download all attachments as: .zip

Change History (22)

Changed 5 years ago by dmik

comment:1 Changed 5 years ago by 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.

Changed 5 years ago by dmik

emxomf with the patch

comment:2 Changed 5 years ago by 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.

comment:3 Changed 5 years ago by 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).

Changed 5 years ago by dmik

Changed 5 years ago by dmik

emxomf with all recent patches

comment:4 Changed 5 years ago by dmik

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

comment:5 Changed 4 years ago by dryeo

  • Cc dryeo added

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

comment:6 Changed 4 years ago by 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.

Changed 4 years ago by dmik

Changed 4 years ago by dmik

Changed 4 years ago by dmik

emxomf with all recent patches

comment:7 Changed 4 years ago by bird

  • Milestone set to libc-0.6.4

comment:8 Changed 4 years ago by bird

  • Status changed from new to assigned

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

comment:9 Changed 4 years ago by bird

  • Summary changed from emxomf tries to export local (non-public) symbols to emxomf: long names in libraries gets the wrong dict entry and barfs

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.

comment:10 Changed 4 years ago by bird

  • Description modified (diff)

comment:11 Changed 4 years ago by bird

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

comment:12 Changed 4 years ago by bird

  • Resolution set to fixed
  • Status changed from assigned to closed

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

comment:13 Changed 4 weeks ago by dmik

  • Component changed from emx to libc
  • Milestone changed from libc-0.6.4 to libc-0.6.6
  • Version changed from 0.6 to 0.6.5

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

comment:14 Changed 4 weeks ago by dmik

(Note: I didn't change the fields version, component and milestone above: my Safari changed it for me for unknown reason and I 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).

Last edited 4 weeks ago by dmik (previous) (diff)

comment:15 Changed 4 weeks ago by 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.

Note: See TracTickets for help on using tickets.