[llvm-dev] LLD status update and performance chart

[Rui Ueyama via llvm-dev]

On Mon, Dec 12, 2016 at 11:42 AM, Andrew Kelley <superjoe30 at gmail.com>
wrote:

>
>
> On Mon, Dec 12, 2016 at 11:13 AM, Rafael Avila de Espindola via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> writes:
>>
>> > On 12 Dec 2016, at 03:39, Rui Ueyama via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>> >>
>> >> LLD's driver currently takes only a command line argument strings, so
>> you need to write ELF files to a filesystem and read them back at the
>> moment.
>> >>
>> >> Theoretically, we could accept a list of command line strings and
>> MemoryBuffer objects (instead of filenames) so that we can link in-memory
>> ELF object files. Adding that feature shouldn't be hard.
>> >
>> > It would be nice to have a similar interface to the one in libclang,
>> where the driver is given a map that substitutes in-memory objects for
>> specific files, so that the same command line can be used whether the
>> inputs are on disk or in memory.
>>
>> I would strongly object to expanding our "library" interface at the
>> moment.
>>
>> Even what we currently have I think is a bad idea and a distraction from
>> the current objective: writing an excellent stand alone linker. We
>> benefit massively from simple error and memory management.
>>
>> Once the linker is "done", we can discuss other possible uses and their
>> costs. By "done" I mean at least having all the features we want and
>> having replaced bfd ld in at least two freebsd architectures.
>>
>
> It seems reasonable to me to focus on this first, but do you agree that
> once lld gets to this milestone, the library API is a worthy time
> investment?
>

I'm fine as long as our API is the same as the command line. In that sense,
passing a map from filename to MemoryBuffer objects in addition to command
line arguments is fine to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161212/110efb55/attachment.html>