[llvm-dev] storage class 0 symbol is generated for a double constant in COFF-x86-64 object file

[Shiyao Ge via llvm-dev]

Hi,

I am using the llvm codegen facility (version 7.0.1) to translate LLVM IR
for different platforms. I have this error particularly in win64 platform.
In my IR code I have such code snippet:

%50 = call i8* @my_function(i8* %48, double 2.000000e+00, double
2.000000e+00)
...
declare dllimport i8* @my_function(i8*, double, double)

By passing it to llc.exe, I find following symbol is declared in object
file's symbol table.

[10](sec  5)(fl 0x00)(ty   0)(scl   0) (nx 0) 0x00000000
__real at 4000000000000000

which has storage class 0, and it will lead to an error when I try to link
it with the rest of objects.

obj1.obj: Unrecognized storage class 0 for .rdata symbol
`__real at 4000000000000000'.


As comparison, I compile an equivalent c file (to my llvm asm file) using
clang-7.0 and emit the llvm from there. For this particular line, I see no
difference in terms of syntax, except clang generates bunch of function
attributes to the function declaration. I pass the clang generated llvm asm
to llc and find the output object file also has one symbol has the same
name, but the storage class is set to 2.

[10](sec  5)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00000000
__real at 4000000000000000

That will probably resolve the linkage error issue. But I don't understand
what's the key factor to determine the storage class and what change should
I put into my generated IR.

Moreover, I looked up the microsoft doc about storage class. The storage
class 2 is described as "A value that Microsoft tools use for external
symbols. " It doesn't sound like a symbol represents a floating point
constant at all.

Due to my limited knowledge of PE COFF and llvm codegen for windows
platform,  I am totally confused here. Any suggestion and hint are
desperately welcomed!
-- 
Shiyao Ge (Gracia)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190628/a1a0d04a/attachment.html>