On Mon, Dec 6, 2010 at 3:09 PM, Andi Kleen <a...@firstfloor.org> wrote: >> On Mon, Dec 6, 2010 at 2:43 PM, Andi Kleen <a...@firstfloor.org> wrote: >>>> Hi, >>>> >>>> "ld -r" doesn't work with mixed IR/non-IR objects: >>>> >>>> http://www.sourceware.org/bugzilla/show_bug.cgi?id=12291 >>> >>> There are various bugs for it in gcc bugzilla too. >>> >>>> Some compilers support it. Should it be supported? >>> >>> Yes. I've been working on it (slim lto was the first part needed for it, >>> without slim lto it's imho hopeless) >> >> Slim lto is a workaround, not a real solution. > > Actually I consider fat lto as a workaround for toolchain deficiencies. > Generating everything twice and throwing one copy away is always > inefficient. IMHO slim lto is the natural way to do LTO.
The idea is the same object file can be used with compilers which don't support LTO. > The only problem is that you need to fix every piece in the toolchain > to not mess up LTO. > > That's why I did the gcc-ar,nm etc. wrappers. There were other problems > too, like gcc's build system itself not handling LTO correctly (it normally > only works because fat saves the day) > >> I think this support should >> be >> implemented in ld with help from GCC. > > Without slim lto you never know if a duplicate symbol is a mistake > of the programmer or just the "fat lto" copy. Also ELF semantics > like weak are hard if you have multiple copies. > It isn't easy, but doable. -- H.J.
