[llvm-dev] What should IRObjectFile expose?

[Rafael Espíndola via llvm-dev]

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