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

[Rui Ueyama]

On Thu, Feb 26, 2015 at 1:48 PM, Shankar Easwaran <shankare at codeaurora.org>
wrote:

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

We shouldn't attach a precedence even to Sections.

The thing is that atom ordering and atom binning are different. We need the
precedence only for atom ordering -- which atom needs to be emit before
which atom, and that should be done in the order pass. The writer on the
other hand only does atom binning -- which atom needs to be emit in which
section, and in order to do that we don't use the original order of linker
script commands, so attaching that data to Section has no use.


> 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 listllvm-commits at cs.uiuc.eduhttp://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/04dc6c34/attachment.html>