[llvm-commits] [lto][patch] Remove weak attempt of tracking symbols defined in module level assembly
Chris Lattner
clattner at apple.com
Sun Feb 20 10:40:44 PST 2011
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
More information about the llvm-commits
mailing list