[llvm-commits] [lto][patch] Remove weak attempt of tracking symbols defined in module level assembly

[Chris Lattner]

On Feb 19, 2011, at 6:35 PM, Rafael Ávila de Espíndola wrote:

>> I agree that the heuristic is a gross hack, but this will break
>> building llvm itself with LTO, since the JIT defines a symbol (for
>> the compilation callback) in file scope inline asm.
> 
> Why would this break the build? If a symbol is not present in the IL but
> shows up in the final .o produce by LTO, the linker should still put in
> in the binary.

I don't know.  Devang, you added this code to get llvm to build with LTO, do you remember?  Can we just rip it out?

> 
> I just tried a clang bootstrap with LTO and this patch and the dynamic
> symbol table of lli contains the symbol:
> 
>  6923: 00000000004f4ed0   130 FUNC    GLOBAL DEFAULT   13
> X86CompilationCallback
> 
> If this is a limitation of the Apple linker, can this code be made
> conditional on a Mach-O target?

I wouldn't be surprised if this was something specific to liblto that didn't impact libgold.

> 
>> I think that the right longer term answer is to use the MC parser
>> with a custom mcstreamer to pick out symbol definitions.
> 
> I am not fully decided. Just some observations:
> 
> *) Having this logic in libLTO causes surprising results like when the
> gnu nm using the LTO plugin prints a symbol but llvm's own llvm-nm doesn't.

But the symbol *is* there.  I would consider that to be a bug in llvm-nm, not liblto.

> *) This would add another expensive step to an already expensive stage.

Scanning module-level inline asm isn't expensive, particularly since the common case is that it doesn't exist :)

> Both of those problems could be avoided with an explicit symbol table in
> the .bc files, but then the logic for parsing the assembly and finding
> definitions and references would have to be in the IL assembler so that
> simple tools like llvm-as still produce the correct result.

There is another solution here, at least to the LTO side of the issue (not NM): we could have liblto splat the module level asm out to its own *native* .o file, hand that back to the linker, then have the linker handle it + the IR together.

-Chris