[lld] r229762 - PECOFF: Fix symbol aliases

Shankar Easwaran shankare at codeaurora.org
Wed Feb 18 19:22:46 PST 2015


Thanks for the explanation.

On 2/18/2015 9:03 PM, Rui Ueyama wrote:
> On Wed, Feb 18, 2015 at 6:44 PM, Shankar Easwaran <shankare at codeaurora.org>
> wrote:
>
>>   Hi Rui,
>>
>> This is only in the Context of modeling Alias symbols. I agree we dont
>> want to bring the complete LayoutPass for simple usecases.
>>
>> Do you have a different solution/design that works with ordinals to layout
>> multiple alias atoms ?
>>
> It's too simple so I don't know if we can call it a solution or a design,
> but we can define 2^32 aliases for an atom in this way.
>
> Are you considering / need to support more than one alias to the *first *atom
>> created for a file ?
>>
> That should work already. As I described in the comment for getNextOrdinal,
> the ordinal of the first real atom is 1<<32 (not 0), so we can assign any
> number between 0 to 1<<32-1 to aliases for the first atom.
>
>
>> Shankar Easwaran
>>
>>
>> On 2/18/2015 8:28 PM, Rui Ueyama wrote:
>>
>> I know you wanted to bring LayoutPass back, and I think I described about
>> why that's not a good idea many times. The most recent discussion is this.
>> Could you read this and then elaborate why you think we should use the
>> LayoutPass based on that discussion?
>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-February/082130.html
>>
>> On Wed, Feb 18, 2015 at 6:06 PM, Shankar Easwaran <shankare at codeaurora.org> <shankare at codeaurora.org>
>> wrote:
>>
>>
>>   I feel using kindLayoutBefore references would be a preferred way for this
>> solution.
>>
>> We could enable the LayoutPass only if Alias symbols exist. Does COFF need
>> alias symbols for default operation ?
>>
>> Shankar Easwaran
>>
>>
>> On 2/18/2015 5:50 PM, Rui Ueyama wrote:
>>
>>
>>   On Wed, Feb 18, 2015 at 3:47 PM, Shankar Easwaran <shankare at codeaurora.org>
>> wrote:
>>
>>   On 2/18/2015 5:11 PM, Rui Ueyama wrote:
>>
>>    +  alias->setOrdinal(target->ordinal() - 1);
>>
>>    Wouldn't this cause a wrap around when the ordinal of the first atom
>>
>>   is 0 ?
>>
>>      +// getNextOrdinal returns a monotonically increasaing uint64_t
>>
>>   number
>> +// starting from 1. There's a large gap between two numbers returned
>> +// from this function, so that you can put other atoms between them.
>> +uint64_t FileCOFF::getNextOrdinal() {
>> +  return _ordinal++ << 32;
>> +}
>> +
>>
>>   Do you need it this to be shifted by 32 ? Wouldnt incrementing by 2 be
>>
>>   enough ?
>>
>>
>>   You could define two or more aliases to a symbol so we need more room than
>> for one alias. That doesn't work now, though.
>>
>>
>>
>>
>>   Shankar Easwaran
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>> by the Linux Foundation
>>
>>
>>
>>
>>   --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>> by the Linux Foundation
>>
>>
>>
>>
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
>>
>>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation




More information about the llvm-commits mailing list