[PATCH] D11188: [LLD] New ELF implementation

Sean Silva chisophugis at gmail.com
Wed Jul 15 16:55:13 PDT 2015


On Wed, Jul 15, 2015 at 1:45 PM, Rui Ueyama <ruiu at google.com> wrote:

> If the file order in command line does't matter, we can read archive files
> and adding symbols from them concurrently, so even if total amount of work
> doesn't change, that could still make things faster.
>

--start-group and --end-group I don't think precisely cause COFF-like
behavior. IIRC they actually mean "use the same behavior, but circle back
around if there is anything unresolved". So it only causes a place which
would cause "undefined symbol error" to have the linker keep going.

-- Sean Silva


>
> On Wed, Jul 15, 2015 at 1:35 PM, Joerg Sonnenberger <
> joerg at britannica.bec.de> wrote:
>
>> On Tue, Jul 14, 2015 at 03:12:04PM -0700, Rui Ueyama wrote:
>> > On Tue, Jul 14, 2015 at 3:07 PM, Joerg Sonnenberger <joerg at netbsd.org>
>> > wrote:
>> >
>> > > joerg added a subscriber: joerg.
>> > > joerg added a comment.
>> > >
>> > > I don't understand how forcing everything to be grouped can make
>> things
>> > > more efficient, given that it is strictly required to do more work. It
>> > > doesn't even matter for plain object files, just for libraries. In
>> the case
>> > > of libraries, there are subtle error cases involving weak symbols, so
>> > > please do *not* change the resolution algorithm.
>> > >
>> >
>> > It's faster because we don't have to visit files grouped by
>> > --start-group/--end-group repeatedly.
>>
>> That statement *still* doesn't make sense. Except maybe glibc's libc.so
>> hack, I see groups rarely used at all. Certainly not for plain object
>> files and if anything, only implicitly for library archives. So how can
>> forcing the *additional* work improve things again?
>>
>> Joerg
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150715/f2617d4e/attachment.html>


More information about the llvm-commits mailing list