<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 5, 2016 at 7:03 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 4 April 2016 at 23:39, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>> wrote:<br>
> Hi Rafael,<br>
><br>
> There's a source file in Chromium that does something like this:<br>
><br>
> target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"<br>
> target triple = "x86_64-unknown-linux-gnu"<br>
><br>
> module asm ".text"<br>
> module asm "foo: ret"<br>
><br>
> declare void @foo()<br>
><br>
> define void @_start() {<br>
>   call void @foo()<br>
>   ret void<br>
> }<br>
><br>
> Currently the llvm-nm output for that looks like this:<br>
><br>
> ---------------- T _start<br>
>                  U foo<br>
> ---------------- t foo<br>
><br>
> That second entry is a bug, right? I just wanted to confirm before I go<br>
> ahead and fix it, since the fix seems like it would be rather involved.<br>
<br>
</span>It depends on how much you want it to do I guess.<br>
<br>
Given bugs people find when trying to use LTO I am pretty sure that<br>
parsing global assembly to detect symbols is necessary. For another<br>
recent report see <a href="https://llvm.org/bugs/show_bug.cgi?id=26745" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=26745</a>.<br>
<br>
Normally having a U and T just looks silly in llvm-nm, but as you<br>
noticed that breaks down when the definition is not marked global.<br>
<br>
(very?) long term my idea is to add a proper symbol table to the<br>
bitcode file. The idea is that it would have the final word on what<br>
symbols are defined in a given .bc. In particular:<br>
<br>
* A @foo would show up as "foo" or "_foo" or "_foo@some_windows_thing"<br>
in the symbol table.<br>
* There would be entries for symbols declared as inline assembly.<br>
<br>
In that universe IRObjectFile would be a lot more like any other<br>
object file implementation and not depend on MC :-)<br>
<br>
The flip side is that llvm-as would be doing mangling and either we<br>
would require asm symbol declarations in .ll or it would also parse<br>
assembly.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Thanks,</div></div>-- <br><div class="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>