wrong x86 asm symbol name decoration

[llvmbot]

Bugzilla Link	2936
Resolution	FIXED
Resolved on	Feb 12, 2010 09:38
Version	2.4
OS	Windows XP
Attachments	testcase, x86 asm intel, x86 asm intel (correct), x86 asm att, x86 asm att (correct), diff X86IntelAsmPrinter.cpp, diff X86ATTAsmPrinter.cpp
Reporter	LLVM Bugzilla Contributor
CC	@asl

Extended Description

when dllexport'ing functions with llvm on the x86 cygwin platform two bugs arose:

1. the X86ATTAsmPrinter uses the properly decorated function names in the function definition, but exports the undecorated names.

2. both, the X86ATTAsmPrinter and X86IntelAsmPrinter use an incorrectly decorated name when calling a fastcall/stdcall function. this only happens if the function is called before it is defined.

I'm attaching a single testcase to reproduce both problems.
It is only reproduceable with the 2.4 branch on cygwin or mingw.

Additionally I'm providing a workaround (not a fully tested patch).

[asl]

Additionally I'm providing a workaround (not a fully tested patch).
I see the problem, but it's still unclear for me what was so changed, that this
stuff became broken. In any case workarounds are incorrect: at least there will be problems with stdcall functions (note the leading underscore!)

I'll investigate.

[llvmbot]

perhaps this helps:

the order of emitting the function header has the side-effect that MF.getInfo() is populated in FunctionInfoMap.
if decorateName() cannot find a populated info in FunctionInfoMap for reuse, it populates the info from calculateFunctionInfo(F*, TD*) on its own.

IMHO the problem is: X86MachineFunctionInfo(MF&) != calculateFunctionInfo(F*, TD*)
X86MachineFunctionInfo(MF&) initializes the member to default values -> n bytes are always decorated as @​0
only calculateFunctionInfo(F*, TD*) looks at the actual parameters and attributes to sum up the bytes to pop on return -> correct @​n

my workaround forces that only info from calculateFunctionInfo(F*, TD*) is used, by removing the call to MF.getInfo().

[asl]

my workaround forces that only info from calculateFunctionInfo(F*, TD*) is
used, by removing the call to MF.getInfo().
This is only small part of the problem. Another issue (and more severe) is that we need to emit "_foo@n" for stdcall functions inside intel asm printer and "foo@n" inside att. For fastcall we need to emit "@foo@n".

[asl]

*** Bug llvm/llvm-bugzilla-archive#4743 has been marked as a duplicate of this bug. ***

[llvmbot]

Example (zip archive)
Yet another, worse issue... Linking fails with undefined reference to `_foo'. Notice that .def is not generated at all.

[llvmbot]

[...] we need to emit "_foo@n" for stdcall functions
inside intel asm printer and "foo@n" inside att.

FSF's MinGW32-GCC emits "_foo@n" in both Intel and ATT mode...

[asl]

Fixed in r95980

[asl]

mentioned in issue llvm/llvm-bugzilla-archive#4743

[asl]

mentioned in issue llvm/llvm-bugzilla-archive#5851