<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 10, 2014 at 12:34 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"><span><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">
2) Add a generic dictionary method to lld::File.  The dictionary might be empty for ELF and COFF readers, but the mach-o reader would populate the dictionary with some key/value encoding for each attribute it needs (e.g. “minOS” —> “10.9”).<br>
</blockquote></blockquote>
I would like this, lld::File would become more flavor neutral with this. For example if you add minOS to lld::File it would not make sense for COFF/ELF.<br>
</blockquote>
There will be a default (do nothing) implementation for these methods in the base class File.  COFF and ELF can just ignore them.  The dictionary design is not a normal C++ pattern.<br>
</blockquote></span>
The LLVM IR also uses a metadata/dictionary model, to store attributes that are associated with the module. I think we also need a model that we can associate metadata with atoms.</blockquote><div><br></div><div>Yeah, I'd guess that's sometimes useful indeed. I once hoped to have something like that because it would be convenient. But at the same time, there's a risk that it becomes a kitchen sink that we put everything there in an disorganized manner. Named fields and named accessors are, on the other hand, organized and type-safe. LLVM IR and the internal representation of object files in LLD are naturally different. I'd think adding a generic key-value store to an atom is too flexible for us.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br>
<br>
Shankar Easwaran<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></div>