<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 1, 2014 at 1:09 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">Hi,<br>
<br>
Since all the atoms in a file share the same filename/membername(for archives), we could have a field thats could be used as metadata. Formats may decide to store metadata information, if they decide to.<br>
<br>
We should restrict the types of metadata information that can be added though (metadataKinds).</blockquote><div><br></div><div>Yes and no. We cannot just say we should restrict. What we need is to think carefully before adding a field of Atom. If there's a legitimate reason, it's totally okay to add a new one. What's worse is to invent a complicated workaround just to avoid adding a new field.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
Shankar Easwaran</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 12/1/2014 2:49 PM, Rui Ueyama wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We don't need a filename for the PE/COFF writer, but if it existed, it<br>
wouldn't hurt us. We'll leave the field nullptr.<br>
<br>
I don't think we need to vote here. Even if only one arch needs it, if it<br>
should naturally be added to Atom, it should be added to Atom.<br>
<br>
On Mon, Dec 1, 2014 at 12:44 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">
+ Nick<br>
<br>
Rui,<br>
<br>
Does PECOFF writer need the filename in the writer as well, I am not sure<br>
if linker scripts are supported with PECOFF though.<br>
<br>
If PECOFF also needs it, I think it makes sense to store the filename in<br>
the Atom as the native format needs to store that information.<br>
<br>
The only option for the ELF writer to know this information is to use<br>
References if other flavors dont need the filename (only in DEBUG mode,<br>
clumsy but would work).<br>
<br>
PS : Moving this discussion to llvmdev.<br>
<br>
Shankar Easwaran<br>
<br>
On 12/1/2014 2:34 PM, Rui Ueyama wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That sounds like we really need a new property of Atom.<br>
<br>
1. If we run LLD in Release build, the roundtrip passes don't run, so<br>
everything works fine.<br>
2. If we run LLD in Debug build (and from the unit tests), the information<br>
is dropped during the round-trip conversion, and it fails.<br>
3. RoundTrip tests should't drop any information.<br>
<br>
2 and 3 conflicts.<br>
<br>
I should note that, again, I don't actually like the idea of YAML/Native<br>
format, though. It feels like it doesn't worth the cost of maintaining two<br>
more different outputs.<br>
<br>
On Mon, Dec 1, 2014 at 12:20 PM, Shankar Easwaran <<br>
<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>><br>
wrote:<br>
<br>
  Hi Rui,<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We discussed to add a new property to the atom, but its really not needed<br>
as the original filename from where the atom was parsed is available in<br>
release mode(roundtrip passes dont get called in release mode).<br>
<br>
The discussion was here, <a href="http://lists.cs.uiuc.edu/" target="_blank">http://lists.cs.uiuc.edu/</a><br>
pipermail/llvmdev/2014-<br>
November/078910.html.<br>
<br>
Shankar Easwaran<br>
<br>
<br>
<br>
<br>
</blockquote></blockquote>
--<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></div>