[PATCH] [lld] Remove duplicate class definitions of ELF LinkingContexts

[Filipe Cabecinhas]

Hi Shankar,

On Sat, Feb 21, 2015 at 9:55 AM, Shankar Easwaran <
shankar.kalpathi.easwaran at gmail.com> wrote:

> filcab,
>
> We need lld to be tightly integrated with LLVM targets, these are the
> reasons I have in mind :
>
> - targets need to get instruction eencoding recorded in the Td file. If
> you see the Hexagon target in lld we have one huge file that contains all
> the encodings which is just duplicating informattoo in the Td files. I
> believe MIPS also needs this encoding information.
>
Is this about the code like what's in
http://llvm.org/klaus/lld/blob/master/lib/ReaderWriter/ELF/Hexagon/HexagonTargetHandler.cpp#L-54
(and other files for other archs)?

>From talking to Michael, I got the impression that it's such a small amount
of code (that will basically never change), that it's not worth it to have
lld depend on all the target infrastructure for no or very little gains.

- enable better diagnostics with encoding information.
>
What kinds of diagnostics, for what kinds of errors?

It's also needed in the future for LTO purposes to invoke the code
> generator from lld after reading bit code files.
>
I don't understand this. lld should be able to use the lto library without
caring about which targets are enabled (as long as lld can handle the
triple it wants, of course). It's “just”: “here's bitcode. Give me machine
code”. And then finish the link. No target things should leak out of the
lto library. Or is this wrong?
The way I see it is: lld depends (directly) on the lto library. The lto
library will depend on the targets, but lld won't depend on them directly.


I would like to propose LLD_TARGET_<flavor> as we have multiple flavors
> that may support the same target in future. Other proposals are welcome too.
>
Doesn't sound bad to me :)

Thanks,

 Filipe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150221/13446baf/attachment.html>