[PATCH] LLD: Core: Fix file ordinals of archive members.

[Shankar Easwaran]

For ELF it need to be the next ordinal available in resolution order. There
are usecases where such behavior is needed especially by users who write
linker scripts. We would need to have a override function in the
LinkingContexts, to suite flavor specific behavior.

On Wed, Mar 4, 2015 at 2:06 PM, Rui Ueyama <ruiu at google.com> wrote:

> We don't need this behavior for non-ELF ports. Maybe we should document
> that the symbols are ordered in outputs as they are resolved.
>
> On Wed, Mar 4, 2015 at 11:38 AM, Shankar Easwaran <shankare at codeaurora.org
> > wrote:
>
>> On 3/4/2015 1:25 PM, Rui Ueyama wrote:
>>
>>> On Wed, Mar 4, 2015 at 11:22 AM, Shankar Kalpathi Easwaran <
>>> shankarke at gmail.com> wrote:
>>>
>>>  ================
>>>> Comment at: lib/Core/Resolver.cpp:84
>>>> @@ -83,3 +83,3 @@
>>>>       if (const File *member = archiveFile->find(undefName,
>>>> dataSymbolOnly)) {
>>>> -      member->setOrdinal(_ctx.getNextOrdinalAndIncrement());
>>>> +      member->setOrdinal(archiveFile->ordinal() + _memberOrdinal++);
>>>>         const_cast<File *>(member)->beforeLink();
>>>> ----------------
>>>> The member ordinal seems wrong, it should be the next ordinal available
>>>> for GNU.
>>>>
>>>
>>> Why do you think so?
>>>
>> As that is how the input files were picked by the resolver. If a
>> different behavior is needed, may be add a linkingContext function to
>> return the ordinal by passing a file ?
>>
>>
>> Shankar Easwaran
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>> by the Linux Foundation
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150304/41d9090a/attachment.html>