[llvm-dev] What should IRObjectFile expose?

[Peter Collingbourne via llvm-dev]

On Tue, 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> 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.
>
> 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. 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.
>

Thanks Rafael, that all makes sense. I think the first step would be to add
some logic to IRObjectFile to have it compute a symbol table that's good
enough to handle cases like this. Later we can perhaps consider moving some
of that logic to somewhere like the bitcode writer and make IRObjectFile
rely on that symbol table.

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