[PATCH] D11188: [LLD] New ELF implementation

[Rui Ueyama]

On Wed, Jul 15, 2015 at 4:55 PM, Sean Silva <chisophugis at gmail.com> wrote:

>
>
> 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.
>

That's right. COFF behavior is not the same as the case if all files are
wrapped with --start-group and --end-group. I'd think we eventually had to
implement Unix semantics.


>
> -- 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/20150716/ab80b5c4/attachment.html>