<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Rui,<br>
<br>
I completely agree, this is not an attribute associated with every
DefinedAtom. Already commented on that, adding to DefinedAtom is
not a good design.<br>
<br>
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.<br>
<br>
Shankar Easwaran<br>
<br>
On 2/26/2015 3:42 PM, Rui Ueyama wrote:<br>
</div>
<blockquote
cite="mid:CAJENXguo4OCQMHs=oi3Gwq9LXRaAQJSzYxyF1GcBia+fi84pkw@mail.gmail.com"
type="cite">
<pre wrap="">On Thu, Feb 26, 2015 at 12:53 PM, Shankar Kalpathi Easwaran <
<a class="moz-txt-link-abbreviated" href="mailto:shankarke@gmail.com">shankarke@gmail.com</a>> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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".
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
llvm-commits mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation</pre>
</body>
</html>