[llvm-dev] [RFC] Adding a new option to lld to make it easy to maintain compatibility with other linkers

[Rui Ueyama via llvm-dev]

I implemented the feature as --warn-backrefs in
https://reviews.llvm.org/rL329636.

On Thu, Apr 5, 2018 at 10:57 AM Rui Ueyama <ruiu at google.com> wrote:

> On Thu, Apr 5, 2018 at 10:51 AM James Y Knight <jyknight at google.com>
> wrote:
>
>>
>>
>>
>> On Thu, Apr 5, 2018 at 12:20 PM Rui Ueyama <ruiu at google.com> wrote:
>>
>>> On Wed, Apr 4, 2018 at 7:30 PM James Y Knight <jyknight at google.com>
>>> wrote:
>>>
>>>> I believe this will report an error on more command-lines than a
>>>> traditional linker would fail to link. E.g.:
>>>>   ld.lld foo.o A.a B.a A.a B.a
>>>> That "should" work fine if the libs are circularly-dependent, as long
>>>> as there's only a 1-level cycle. I've seen that sort of construct used a
>>>> fair amount, and while the start-group/end-group flags are pretty clearly a
>>>> superior option, but are not universally used.
>>>>
>>>
>>> Actually it won't report an error for that command line. We (and perhaps
>>> other linkers as well) don't do anything special for files that happen to
>>> be passed to a linker more than once, so the first A.a and second A.a are
>>> handled as different files.
>>>
>>
>> But if B.a requires pulling in an object from A.a, LLD will pull it from
>> the _first_ A.a on the command-line, and then, if this flag is specified,
>> report an error due to the incorrect ordering of dependencies. (Whereas GNU
>> ld will pull it from the _second_ A.a and succeed linking.)
>>
>
> Ahh, that's true. I don't think that's a serious issue, but that's indeed
> something that this feature would report as a false positive.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180409/ebbe156d/attachment.html>