<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 4, 2016 at 5:06 AM Carlo Kok via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Op 2016-03-30 om 03:00 schreef Eric Christopher via llvm-dev:<br>
> Hi All,<br>
><br>
> This is something that's been talked about for some time and it's<br>
> probably time to propose it.<br>
><br>
> The "We" in this document is everyone on the cc line plus me.<br>
><br>
> Please go ahead and take a look.<br>
><br>
> Thanks!<br>
><br>
> -eric<br>
><br>
><br>
> Motivation<br>
> ========<br>
><br>
> Currently, types in LLVM debug info are described by the DIType class<br>
> hierarchy. This hierarchy evolved organically from a more flexible<br>
> sea-of-nodes representation into what it is today - a large, only<br>
> somewhat format neutral representation of debug types. Making this more<br>
> format neutral will only increase the memory use - and for no reason as<br>
> type information is static (or nearly so). Debug formats already have a<br>
> memory efficient serialization, their own binary format so we should<br>
> support a front end emitting type information with sufficient<br>
> representation to allow the backend to emit debug information based on<br>
> the more normal IR features: functions, scopes, variables, etc.<br>
><br>
> Scope/Impact<br>
> ===========<br>
><br>
> This is going to involve large scale changes across both LLVM and clang.<br>
> This will also affect any out-of-tree front ends, however, we expect the<br>
> impact to be on the order of a large API change rather than needing<br>
> massive infrastructure changes.<br>
><br>
<br>
How will you make it on the order of a large api change? At the moment<br>
we build bitcode ourselves and generate dibuilder equivalent structures.<br>
wouldn't frontends need to do their own well, DWARF and CodeView<br>
writing? Especially the ones that are tied to the C only apis.<br>
<br></blockquote><div><br></div><div>There will be some backend support. The hope is that it'll be a fairly direct translation from the existing APIs.</div><div><br></div><div>I make no claims about C API as we don't handle types at the C API level currently.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Proposal<br>
> =======<br>
><br>
> Short version<br>
> -----------------<br>
><br>
> 1. Split the DIBuilder API into Types (+Macros, Imports, …) and Line Table.<br>
> 2. Split the clang CGDebugInfo API into Types and Line Table to match.<br>
> 3. Add a LLVM DWARF emission library similar to the existing CodeView one.<br>
> 4. Migrate the Types API into a clang internal API taking clang AST<br>
> structures and use the LLVM binary emission libraries to produce type<br>
> information.<br>
> 5. Remove the old binary emission out of LLVM.<br>
><br>
<br>
What about allow multiple debug info formats at once? The current format<br>
could potentially<br>
allow such an option in the future (i know it doesn't actually do it<br>
now), will the new option<br>
hardcode it to a single format?<br>
<br></blockquote><div><br></div><div>What option?</div><div><br></div><div>I don't think this is much of a worry - at the very least it's probably not much more difficult than doing it right now.</div><div><br></div><div>-eric</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
--<br>
Carlo Kok<br>
RemObjects Software<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>