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

Shiyao Ge via llvm-dev llvm-dev at lists.llvm.org
Mon Jul 1 17:37:50 PDT 2019


Hi Reid,

Sure. Here I attach the trimmed IR(sim_0.ll) which llc.exe takes and
produces a 0 storage class symbol.
The IR is fairly long but there is only 1 usage of real constant as actual
argument passing to function iki_vlog_time() at line 137.
The version of llc.exe is

$ llc.exe --version
  LLVM (http://llvm.org/):
  LLVM version 7.0.1
  DEBUG build.
  Default target: x86_64-pc-win32
  Host CPU: skylake

The command I use to produce PE object is:

llc.exe -filetype=obj -O0 sim_0.ll -o sim_0.obj


Reid Kleckner <rnk at google.com> 于2019年7月1日周一 下午1:45写道:

> I can't speak for what past versions of LLVM used to do, but I can see
> that today for this IR, we generate an external symbol __real at 40...:
>
> declare dllimport void @my_function(double, double)
> define i32 @main() {
>   call void @my_function(double 2.000000e+00, double 2.000000e+00)
>   ret i32 0
> }
>
> $ dumpbin -symbols t.o
> ...
> 006 00000000 SECT4  notype       Static       | .rdata
>     Section length    8, #relocs    0, #linenums    0, checksum 76DC4190,
> selection    2 (pick any)
> 008 00000000 SECT4  notype       External     | __real at 4000000000000000
> ...
>
> If you can provide complete IR on which llc produces a 0 storage class,
> that would be interesting, but otherwise there's not much we can do.
>
> On Fri, Jun 28, 2019 at 5:59 PM Shiyao Ge via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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)
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>

-- 
Shiyao Ge (Gracia)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190701/c0245110/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sim_0.ll
Type: application/octet-stream
Size: 39912 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190701/c0245110/attachment-0001.obj>


More information about the llvm-dev mailing list