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

[Rafael Ávila de Espíndola]

> 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 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 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.
*) This would add another expensive step to an already expensive stage.

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.

> -Chris

Cheers,
Rafael