<div dir="ltr">As a thought experiment and a counter example, we could imagine if we adopt that "metadata model" to the current LLD code base. We would remove the following member functions from DefinedAtom in favor of the generic key-value pair.<div><br></div><div>  ordinal()</div><div>  size()</div><div>  scope()</div><div>  merge()</div><div>  alignment()</div><div>  sectionChoice()</div><div>  customSectionName()</div><div>  and more ...</div><div><br></div><div>ordinal() would be rewritten as getAttribute(DefinedAtom::Ordinal), for example. It seems apparent degradation in code quality to me.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 10, 2014 at 5:03 PM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 11/10/2014 6:55 PM, Rui Ueyama wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Nov 10, 2014 at 12:34 PM, Shankar Easwaran <<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  2) Add a generic dictionary method to lld::File.  The dictionary might be<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
empty for ELF and COFF readers, but the mach-o reader would populate the<br>
dictionary with some key/value encoding for each attribute it needs (e.g.<br>
“minOS” —> “10.9”).<br>
<br>
</blockquote>
I would like this, lld::File would become more flavor neutral with<br>
</blockquote>
this. For example if you add minOS to lld::File it would not make sense for<br>
COFF/ELF.<br>
<br>
</blockquote>
There will be a default (do nothing) implementation for these methods in<br>
the base class File.  COFF and ELF can just ignore them.  The dictionary<br>
design is not a normal C++ pattern.<br>
<br>
</blockquote>
The LLVM IR also uses a metadata/dictionary model, to store attributes<br>
that are associated with the module. I think we also need a model that we<br>
can associate metadata with atoms.<br>
</blockquote>
<br>
Yeah, I'd guess that's sometimes useful indeed. I once hoped to have<br>
something like that because it would be convenient. But at the same time,<br>
there's a risk that it becomes a kitchen sink that we put everything there<br>
in an disorganized manner. Named fields and named accessors are, on the<br>
other hand, organized and type-safe. LLVM IR and the internal<br>
representation of object files in LLD are naturally different. I'd think<br>
adding a generic key-value store to an atom is too flexible for us.<br>
</blockquote>
<br></div></div>
I think adding a metadata model, is more cleaner than adding flavor / target specific attributes in the Atom model.<br>
<br>
We could have specific keys, that access metadata information, rather than flavors adding any arbitrary set of keys (Best of both worlds).<br>
<br>
With this both LLVM IR, lld's IR both would share the same design too.<span class="HOEnZb"><font color="#888888"><br>
<br>
Shankar Easwaran</font></span><div class="HOEnZb"><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Shankar Easwaran<br>
<br>
--<br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted<br>
by the Linux Foundation<br>
<br>
<br>
</blockquote></blockquote>
<br>
<br>
-- <br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br>
<br>
</div></div></blockquote></div><br></div>