This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fwd: LLVM collaboration?


> My reading of bfd/plugin.c is that it basically walks the directory and looks
> for first plugin that returns OK for onload. (that is always the case for
> GCC/LLVM plugins).  So if I instlal GCC and llvm plugin there it will
> depend who will end up being first and only that plugin will be used.
>
> We need multiple plugin support as suggested by the directory name ;)
>
> Also it sems that currently plugin is not used if file is ELF for ar/nm/ranlib
> (as mentioned by Markus) and also GNU-ld seems to choke on LLVM object files
> even if it has plugin.
>
> This probably needs ot be sanitized.

CCing Hal Finkel. He got this to work some time ago. Not sure if he
ever ported the patches to bfd trunk.

>> For OS X the situation is a bit different. There instead of a plugin
>> the linker loads a library: libLTO.dylib. When doing LTO with a newer
>> llvm, one needs to set DYLD_LIBRARY_PATH. I think I proposed setting
>> that from clang some time ago, but I don't remember the outcome.
>>
>> In theory GCC could implement a libLTO.dylib and set
>> DYLD_LIBRARY_PATH. The gold/bfd plugin that LLVM uses is basically a
>> API mapping the other way, so the job would be inverting it. The LTO
>> model ld64 is a bit more strict about knowing all symbol definitions
>> and uses (including inline asm), so there would be work to be done to
>> cover that, but the simple cases shouldn't be too hard.
>
> I would not care that much about symbols in asm definitions to start with.
> Even if we will force users to non-LTO those object files, it would be an
> improvement over what we have now.
>
> One problem is that we need a volunteer to implement the reverse glue
> (libLTO->plugin API), since I do not have an OS X box (well, have an old G5,
> but even that is quite far from me right now)
>
> Why complete symbol tables are required? Can't ld64 be changed to ignore
> unresolved symbols in the first stage just like gold/gnu-ld does?

I am not sure about this. My *guess* is that it does dead stripping
computation before asking libLTO for the object file. I noticed the
issue while trying to LTO firefox some time ago.

Cheers,
Rafael


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]