View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000494GCC - GNU C CompilerBugpublic2011-10-28 12:032020-08-24 03:14
Reporterdmik Assigned Topsmedley  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Summary0000494: __stdcall function names are C++-mangled
DescriptionThis is wrong since (according to the original MSDN specification http://msdn.microsoft.com/en-us/library/zxk0tw93%28v=vs.80%29.aspx) the name is decorated with the underscore nad suffixed with '@N' where N is the number of bytes in the argument list.

E.g. void __stdcall foo(int a) should get a "_foo@4" name in both C and C++ mode while it gets "__Z3fooi@4" in C++ mode instead.

Note that IBM VAC behaves the MS-compatible way and doesn't mangle __stdcall names too.

Another difference is that vararg functions like void __stdcall bar(...) will still get a '@N' suffix (where N is the number of non-vararg bytes) while according to the spec __stdcall should be equal to __cdecl in this case (i.e. the above example should give "_bar", not "_bar@0" as it gives now).

The problem exists in all versions of GCC for OS/2 (3.x and 4.x).


TagsNo tags attached.

Activities

psmedley

2011-10-28 22:16

administrator   ~0002024

How does cygwin behave?

psmedley

2011-10-29 08:48

administrator   ~0002025

OK - for emx - emx_c_set_decl_assembler_name() in emx.c does the name mangling

This is emx specific.

For other platforms, TARGET_MANGLE_DECL_ASSEMBLER_NAME can be defined (and is on windows) to perform the adjustments required for things like stdcall or fastcall

psmedley

2011-10-29 09:01

administrator   ~0002026

ok so I have some ideas now on how to better replicate the mingw / cygwin behaviour - and also simplify the gcc diffs

dmik

2011-10-29 10:55

reporter   ~0002027

I haven't checked cygwin but I believe it behaves correctly. Which means there should be a corresponding codepath in the GCC sources. Could you please commit your fixes to this issue to github so that I could see them as well?

If I come with some patches on my side, I will commit them there too. Therefore we will be able to review each other.

dmik

2011-10-29 14:57

reporter   ~0002029

I think this should relate to the OS/2-specific _Optlink modifier as well: IBM VAC seems to suppress mangling for it too.

psmedley

2011-10-30 00:32

administrator   ~0002030

_optlink isn't currently supported as the patches from 3.3.x can't be applied cleanly and I don't understand them well enough to try and implement them

When I have real patches that work, not just ideas, I'll commit

dmik

2011-11-03 17:14

reporter   ~0002033

One more interesting observation. Sometimes, declaring the function with extern "C" is enough to workaround the problem and get the C++ mangling disabled, sometimes the definition also needs to be placed within extern "C" {} in order to achieve that. The randomness of this behavior reminds me of the similar randomness with _System underscores as described in 0000474... Note that I use the test build of GCC 4.4.6 from that ticket here.

dmik

2011-11-03 17:34

reporter   ~0002034

In other words, if both the declaration (with extern "C") and the definition (without extern "C") are in the same source file, it works. If the declaration (with extern "C") is in a separate header, it doesn't (in 90% of cases, there are a few where it works). Really strange; I always thought the header is a big macro, nothing more (WRT the compilation of the translation unit).

dmik

2011-11-03 18:09

reporter   ~0002035

The _Pascal cconv should behave like _System in terms of mangling, i.e. no leading underscore.

psmedley

2011-11-05 00:32

administrator   ~0002036

Per jabber conversation, mingw appears to behave in the same manner as the emx port.

dmik

2011-11-22 17:44

reporter   ~0002053

I did some more tests. The native MS complier does *not* suppress C++ mangling for __stdcall -- a regular extern "C" is necessary for that. What it does however is it treats a __stdcall declaration with ... (varargs) as __cdecl -- GCC is unaware of that and this is what needs to be fixed.

dmik

2011-11-22 18:16

reporter   ~0002054

Fuck fuck fuck fuck. Killed my comment again. Lame Mantis author.

Checked the native IBM compiler, and according to that, any explicit cconv specification (checked _System, _Optlink __cdecl and __stdcall) automatically assumes extern "C" and disables C++ mangling.

I really wonder who should we be compatible with... Ideally it would be nice to have an option. I will check how hard it is.

psmedley

2011-11-22 19:57

administrator   ~0002055

It's actually a PHP issue with session authentication - nothing to do with mantis

psmedley

2011-11-22 20:04

administrator   ~0002056

I bumped up session.gc_maxlifetime to 24 hrs in php.ini - will hopefully help

dmik

2011-11-23 18:08

reporter   ~0002057

Ah, okay, lame me then. Sorry, author.

I made it behave the IBM VAC way here: https://github.com/psmedley/gcc/commit/2e73649db617b1778b3a96bd5db2911ab807d4dc. That is, extern "C" is implied for all listed calling conventions even when they are used in C++ code.

If we ever find out that we need MSVC-like behavior, we will introduce a target-specific command line option that will switch between these two behaviors.

dmik

2011-11-24 11:41

reporter   ~0002058

It turns out that the code from winnt.c already handles varargs properly and disables the @NN mangling for them. They only case when it doesn't work is this declaration:

  int foo(...)

i.e. a function with only variable arguments. According to the C standard, this is not legal (at least one fixed argument must be present since otherwise it's impossible for the function itself to get access to the arguments). However, GCC allows for this notation and only seems to treat this function as not having a prototype (which leads the @0 suffix to be added as if it were a function taking no arguments).

I don't know if the above is fully correct, but anyway I don't feel like I want (or we need) to alter this behavior.

Therefore, this ticket must be considered as resolved as everything mentioned in the description works now.

dmik

2011-11-28 22:43

reporter   ~0002059

BTW, I've fixed the optlink calling convention here https://github.com/psmedley/gcc/commit/89e310f78e4ffbf03326bf8f17204b1a94cccd6f.

I didn't do full testing (the convention seems to be very complex to test it w/o a comprehensive test case) so probably some weird cases (like integer arguments alternating the aggregate ones) will not work correctly. But I checked simple test cases (the ones turned out to be present in wgss and odin) and they do work.

dmik

2011-11-29 09:41

reporter   ~0002060

JFTR, this also fixed regparm(N) cconv which was broken by the merge of the old EMX code too.

psmedley

2011-12-03 21:39

administrator   ~0002062

Fixed by Dmik

Issue History

Date Modified Username Field Change
2011-10-28 12:03 dmik New Issue
2011-10-28 22:16 psmedley Note Added: 0002024
2011-10-29 08:48 psmedley Note Added: 0002025
2011-10-29 09:01 psmedley Note Added: 0002026
2011-10-29 10:55 dmik Note Added: 0002027
2011-10-29 14:57 dmik Note Added: 0002029
2011-10-30 00:32 psmedley Note Added: 0002030
2011-11-03 17:14 dmik Note Added: 0002033
2011-11-03 17:34 dmik Note Added: 0002034
2011-11-03 18:09 dmik Note Added: 0002035
2011-11-05 00:32 psmedley Note Added: 0002036
2011-11-22 17:44 dmik Note Added: 0002053
2011-11-22 18:16 dmik Note Added: 0002054
2011-11-22 19:57 psmedley Note Added: 0002055
2011-11-22 20:04 psmedley Note Added: 0002056
2011-11-23 18:08 dmik Note Added: 0002057
2011-11-24 11:41 dmik Note Added: 0002058
2011-11-28 22:43 dmik Note Added: 0002059
2011-11-29 09:41 dmik Note Added: 0002060
2011-12-03 21:39 psmedley Note Added: 0002062
2011-12-03 21:39 psmedley Status new => resolved
2011-12-03 21:39 psmedley Resolution open => fixed
2011-12-03 21:39 psmedley Assigned To => psmedley
2020-08-24 03:14 psmedley Status resolved => closed