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

Rui Ueyama ruiu at google.com
Thu Feb 26 13:42:42 PST 2015


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".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150226/a48d8680/attachment.html>


More information about the llvm-commits mailing list