<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 12, 2013 at 4:31 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank" class="cremed">dblaikie@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Where would the encoding schema be specified?</div></blockquote>
<div><br></div></div><div>Same question applies to a string encoding. We have to define the schema somewhere clearly. I'm just lobbying for the textual IR and the APIs to both operate directly on N fields, and just make the memory representation dense.</div>

</div></div></div></blockquote><div><br></div></div><div>The difference here is that debug info parsing code would know the schema externally - so the metadata itself wouldn't have to be self-describing or typed in any way. Just a flat series of bytes of a fixed size would be sufficient. (then leaving out the fields that refer to other IR constructs such as functions, variables, etc)<br>

<br>But if we could make general metadata generally more compact that'd be nice too and maybe sufficient/instead/not worth the added complexity in debug info code of pulling out fields in the debug info handling code.</div>
</blockquote></div><br>If it makes it possible for humans to read, author, and adjust debug info test cases, that would also be worth it IMO. I'm really unsatisfied by the reliance on C-code-in-comments to figure out what on earth the debug info came from.</div>
</div>