llvm dev - Apr 2016 - What should IRObjectFile expose?

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.

-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160404/7e94cfd4/attachment.html>

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.

Cheers,
Rafael

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>

> 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>