[PATCH] [lld] [LinkerScript] Implement semantics for simple sections mappings

[Shankar Easwaran]

Hi Rui,

I completely agree, this is not an attribute associated with every 
DefinedAtom. Already commented on that, adding to DefinedAtom is not a 
good design.

This information has to be known only to the Writer, and we have 
Sections that are created in the linker and the rule_id need to be 
associated with that.

Shankar Easwaran

On 2/26/2015 3:42 PM, Rui Ueyama wrote:
> On Thu, Feb 26, 2015 at 12:53 PM, Shankar Kalpathi Easwaran <
> shankarke at gmail.com> wrote:
>
>> Rui,
>>
>> There are more complicated examples than that where ruleid's are required,
>> It makes the design scale a lot, than keeping more data structures IMO.
>>
>> For example :
>>
>> .data : { *(.data1 *.data2 *.data3) } is very hard to implement with one
>> single map.
>>
>> Say you have say you have two objects 1.o 2.o, which contains data1,
>> data2, data3 as sections.
>>
>> 1.o { data1->a, data2->b, data3->c } and 2.o { data1->d data2->e data2->f }
>>
>> The (->) corresponds to the section containing the defined atom.
>>
>> The Layout would need to be a,b,c,d,e,f instead of a,d,b,e,c,f.
>>
>> Rule id is less costly than using a map IMO.
>>
> What's called "rule id" here is a precedence of linker script commands.
> First of all, it's a bad name -- there are tons of things that we can call
> "rules" in the linker. It's too generic term to name something.
>
> But what's bad is that the details of the linker script is leaking
> unnecessarily to all ELF atoms and even to DefinedAtom, although only the
> thing that sort atoms and make a decision on file layout needs that data
> need to know about that. The precedence (or the "rule id") shouldn't be
> attached to each atom. The reason why you needed that notion seems that you
> computed the precedence too early and too far from where you needed that
> value, so you had to make it a field of the atom to propagate that data
> from the reader to the writer.
>
> Instead, call getRuleId() (we should rename this function, but anyways)
> from the order pass when you sort atoms. By caching the function cal
> results, the order of computation of the precedence remains the same. By
> doing that we can eliminate the notion of "rule id".
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits


-- 
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/20150226/acbcc1c0/attachment.html>