[llvm-dev] What should IRObjectFile expose?

[Mehdi Amini via llvm-dev]

> On Apr 5, 2016, at 7:03 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
> On 4 April 2016 at 23:39, Peter Collingbourne <peter at pcc.me.uk <mailto:peter at pcc.me.uk>> wrote:
>> Hi Rafael,
>> 
>> There's a source file in Chromium that does something like this:
>> 
>> target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
>> target triple = "x86_64-unknown-linux-gnu"
>> 
>> module asm ".text"
>> module asm "foo: ret"
>> 
>> declare void @foo()
>> 
>> define void @_start() {
>>  call void @foo()
>>  ret void
>> }
>> 
>> Currently the llvm-nm output for that looks like this:
>> 
>> ---------------- T _start
>>                 U foo
>> ---------------- t foo
>> 
>> That second entry is a bug, right? I just wanted to confirm before I go
>> ahead and fix it, since the fix seems like it would be rather involved.
> 
> It depends on how much you want it to do I guess.
> 
> Given bugs people find when trying to use LTO I am pretty sure that
> parsing global assembly to detect symbols is necessary. For another
> recent report see https://llvm.org/bugs/show_bug.cgi?id=26745 <https://llvm.org/bugs/show_bug.cgi?id=26745>.
> 
> Normally having a U and T just looks silly in llvm-nm, but as you
> noticed that breaks down when the definition is not marked global.
> 
> (very?) long term my idea is to add a proper symbol table to the
> bitcode file.

I am glad to read this as I have the exact same (vague) plan!

— 
Mehdi


> The idea is that it would have the final word on what
> symbols are defined in a given .bc. In particular:
> 
> * A @foo would show up as "foo" or "_foo" or "_foo at some_windows_thing"
> in the symbol table.
> * There would be entries for symbols declared as inline assembly.
> 
> In that universe IRObjectFile would be a lot more like any other
> object file implementation and not depend on MC :-)
> 
> The flip side is that llvm-as would be doing mangling and either we
> would require asm symbol declarations in .ll or it would also parse
> assembly.
> 
> Cheers,
> Rafael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160405/dfde2d29/attachment.html>