_System suppresses __declspec(dllexport)

[dmik]

All builds of gcc starting at least from GCC 4.4.2 and up to at least 4.9.0 have the same problem: for a function declared with the _System cconv modifier the __declspec(dllexport) attribute is ignored. As a result, it's impossible to create _System DLL exports w/o a .DEF file (this feature is used in many modern sources).

There is a known workaround to this issue: a patch to EMXOMF that drops the asterisk that GCC prepends to the function name when it's declared as _System and this cures generation of exports (more details are here). However, Knut claims here that this is too hackish. In particular this asterisk is used in GCC for purpose (to suppress the leading underscore) and that GCC needs to be fixed instead, not EMXOMF.

[dmik]

What Knut means is probably that we should change GCC so that it doesn't use an asterisk to indicate suppression of underscores on _System functions but instead drop them (the underscores) by some other means. In order to say what's best here one really needs to study what these "other means" can be and how the asterisk is treated on other platforms when generating object files (do they trim it there at this stage as we now do in our workaround or not).

[dmik]

The test case is very simple:

int _System foo() __declspec(dllexport)
{
    return 1488;
}

If you compile this with gcc -Zomf -Zdll you should get an export named foo in the resulting DLL. With the stock EMXOMF you get nothing.

[dmik]

For the time being I created a new RPM (0.6.5-20) for libc which contains my fresh build of EMXOMF.EXE that differs from the stock one by applying the patches described here: http://trac.netlabs.org/libc/ticket/220#comment:15. This includes the (old) workaround for this ticket's problem which Yuri forgot to apply in the previous RPM build (0.6.5-19) and which was present in my EMXOMF.EXE from 10.08.2010 which all your GCC ZIPz (and all RPMs except the -19 one) have been using until now.

I suggest you to use my fresh EMXOMF from today in your future ZIPs until this issue (and all other issues my build contains patches for) is resolved. There is a zip with EMXOMF for your convenience (but it's also available in the corresponding SRPM in case this link breaks): http://rpm.netlabs.org/test/libc-emxomf-0_6_5-20.zip.

[psmedley]

should be fixed in https://github.com/psmedley/gcc/commit/3aa27ca0f8bd03e83bfe52e9af5392ce89dea18f at least the testcase now works correctly

[dmik]

The fix looks nice! Is it one of your leftovers? The original change comes from a cumulative patch and of the unknown origin.

BTW, you tested it with the "stock" libc 0.6.5 emxomf.exe, right? Anyway, I think we should re-release 4.7.4 with this patch as RPM, then I will check it, and, if all right, I will re-release the libc RPM without the workaround for this problem. I see a lot of commits on the current branch (4.7) from you. Are these your genuine changes? AFAICS, the branch is at 4.7.3 level and you didn't yet merge 4.7.4 changes into it. Am I right?

[psmedley]

Yes, 4.7 branch is still at 4.7.3 - I'm not sure how to do te merger to 4.7.4 in git :(

Patch still isn't quite right - it screws up fastcall by adding an underscore. Will fix try fix today once I finish adding 4.9.0 to git

...and yes, I tested with stock libc 0.6.5 emxomf

On 24/08/14 00:52, Dmitriy Kuminov wrote:

The fix looks nice! Is it one of your leftovers? The original change comes from a cumulative patch and of the unknown origin.

BTW, you tested it with the "stock" libc 0.6.5 emxomf.exe, right? Anyway, I think we should re-release 4.7.4 with this patch as RPM, then I will check it, and, if all right, I will re-release the libc RPM without the workaround for this problem. I see a lot of commits on the current branch (4.7) from you. Are these your genuine changes? AFAICS, the branch is at 4.7.3 level and you didn't yet merge 4.7.4 changes into it. Am I right?

— Reply to this email directly or view it on GitHub https://github.com/psmedley/gcc/issues/9#issuecomment-53155841.

[dmik]

I see. I'm reopening this ticket then, until you resolve this new side effect.

Regarding merging. I will recall how I'd do that and give you a hand :)

[psmedley]

OK - GCC 4.9.0 commited to the 4.9 branch.

I will cherrypick a few of those commits to the 4.7 branch this evening

On 24/08/14 21:36, Dmitriy Kuminov wrote:

I see. I'm reopening this ticket then, until you resolve this new side effect.

— Reply to this email directly or view it on GitHub https://github.com/psmedley/gcc/issues/9#issuecomment-53190215.

[psmedley]

OK, changes committed now, along with some other small fixes

On 24/08/14 21:36, Dmitriy Kuminov wrote:

I see. I'm reopening this ticket then, until you resolve this new side effect.

— Reply to this email directly or view it on GitHub https://github.com/psmedley/gcc/issues/9#issuecomment-53190215.

[dmik]

I confirm that with the fresh build of 4.9.2 this issue has gone (the fix above is on the 4.9 branch). I used the stock emxomf.exe from Knut in order to check that.

Yuri, this means that we should remove our "asterisk" patch from our build of emxomf.exe that we supply in libc RPMs. Please do that. I will close this issue once it's done.

[dmik]

I'm closing this since we (are about to) build EMX tools and LIBC from source with GCC 4 now where this patch will be absent (see https://github.com/bitwiseworks/libc/issues/3#issuecomment-456492563). Nothing needs to be done. Closing.