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

[Rafael Ávila de Espíndola]

>> 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.

libgold is mostly an API mapping from libLTO to the gold api. That is
why I was seeing wrong names in the apifile it produces.

>> 
>>> 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.

Fair enough.

>> *) 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 :)

It is expensive in code size. At least llvm-nm or llvm-as would have to
link with MC.

>> 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.

At least with gold the plugin sees a two stage process

*) Collect definitions and references
*) Give the linker the final object files

The final files are already native, so having the module asm in another
file wouldn't change things for gold.

As you noted on IRC, the one case that would fail in gold is if an
object in an archive would be used only because of a symbol defined in
global asm.

If we ignore llvm-nm for now, I think the two reasonable solutions would be

*) Don't report definition in global asm
*) Implement a special symbol recording streamer. libLTO should be
update to use MC anyway.

Both should be fairly robust/easy to understand. The second option would
also get the undefined references from global asm.

Right now I have some lower hanging fruit (like using MC at all!), so if
we must keep the current logic, that is fine. I will keep it disabled
locally and try to come back to the special streamer idea once more
stuff is working.

> -Chris

Cheers,
Rafael