<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 1, 2017, at 1:56 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Sep 1, 2017 at 1:50 PM Adrian Prantl <<a href="mailto:aprantl@apple.com" class="">aprantl@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 1, 2017, at 1:46 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank" class="">dblaikie@gmail.com</a>> wrote:</div><br class="m_7972407418543163130Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Sep 1, 2017 at 1:41 PM Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank" class="">aprantl@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 1, 2017, at 1:36 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank" class="">dblaikie@gmail.com</a>> wrote:</div><br class="m_7972407418543163130m_-5066715224544666855Apple-interchange-newline"><div class=""><div dir="ltr" class="">Could we get reasonable test cases for them up-front, to see where things are?<br class=""></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class="">You mean for the cases that do work as expected? That seems reasonable.</div></div></div></blockquote><div class=""><br class="">All the cases, actually - so we can see what they are, whether they need improvement, track what those improvements are, etc.<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class="">That seems excessive to me, since you'd have to create them manually (unless yaml-obj makes that trivial?). What about all C(++) types that can be produced by clang?</div></div></div></blockquote><div class=""><br class="">Doesn't seem too hideously expensive to produce by hand, are they? maybe 10-15 lines of assembly (even including the abbreviation) per thing? (It can be really simple DWARF - like a bunch of DW_TAG_variables that have only a DW_AT_type (no name, no other attributes), etc)<br class=""></div></div></div></div></blockquote><div><br class=""></div>Perhaps, but you'll also need to dig through the specification to understand how each is supposed to be used (for example, a variable with a DW_AT_type(DW_TAG_thrown_type <>) doesn't actually make sense). I don't know, maybe I'm overestimating how much work this would be.</div><div><br class=""></div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""></div><div class="">-- adrian</div></div></div><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""><br class=""></div><div class="">-- adrian</div></div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><br class="">(I still find it a bit weird to get const/volatile falling out through this process, but yeah, if there's a whole bunch of other cases that fall through this way for now, guess it makes sense)</div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Sep 1, 2017 at 1:24 PM Adrian Prantl via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank" class="">reviews@reviews.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">aprantl added a comment.<br class="">
<br class="">
In <a href="https://reviews.llvm.org/D36993#859034" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D36993#859034</a>, @dblaikie wrote:<br class="">
<br class="">
> In <a href="https://reviews.llvm.org/D36993#858768" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D36993#858768</a>, @JDevlieghere wrote:<br class="">
><br class="">
> > In <a href="https://reviews.llvm.org/D36993#858121" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D36993#858121</a>, @dblaikie wrote:<br class="">
> ><br class="">
> > > In <a href="https://reviews.llvm.org/D36993#858093" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D36993#858093</a>, @JDevlieghere wrote:<br class="">
> > ><br class="">
> > > > David, apologies for missing your e-mail. I really hate that it doesn't automatically show up in Phabricator! 🙁<br class="">
> > > ><br class="">
> > > > If the tag doesn't have a name attribute, everything will go through this function except: `DW_TAG_pointer_type`, `DW_TAG_ptr_to_member_type`, `DW_TAG_reference_type`, `DW_TAG_rvalue_reference_type`. The first part explains why `class` and `struct` don't show up. I prefer this approach because it's guaranteed to be robust. Every `DW_TAG_*_type` encountered without a name will have something meaningful printed.<br class="">
> > > ><br class="">
> > > > IIRC, the original switch had between 20 and 25 cases.<br class="">
> > ><br class="">
> > ><br class="">
> > > I'm curious what those 20-25 cases were - do you have a copy/roughly describe their contents? Because while 'const' does print nicely, (& volatile would be similar) I'm not sure what the other 10 or so cases might be and whether that's a reasonable way to print them.<br class="">
> ><br class="">
> ><br class="">
> > Here's the list of cases I had originally:<br class="">
> ><br class="">
> > case DW_TAG_array_type:<br class="">
> > case DW_TAG_base_type:<br class="">
> > case DW_TAG_class_type:<br class="">
> > case DW_TAG_const_type:<br class="">
> > case DW_TAG_enumeration_type:<br class="">
> > case DW_TAG_file_type:<br class="">
> > case DW_TAG_interface_type:<br class="">
> > case DW_TAG_packed_type:<br class="">
> > case DW_TAG_pointer_type:<br class="">
> > case DW_TAG_ptr_to_member_type:<br class="">
> > case DW_TAG_reference_type:<br class="">
> > case DW_TAG_restrict_type:<br class="">
> > case DW_TAG_set_type:<br class="">
> > case DW_TAG_shared_type:<br class="">
> > case DW_TAG_string_type<br class="">
> > case DW_TAG_structure_type:<br class="">
> > case DW_TAG_subrange_type:<br class="">
> > case DW_TAG_subroutine_type:<br class="">
> > case DW_TAG_thrown_type:<br class="">
> > case DW_TAG_union_type:<br class="">
> > case DW_TAG_unspecified_type:<br class="">
> > case DW_TAG_volatile_type:<br class="">
> ><br class="">
><br class="">
><br class="">
> Ah, thanks!<br class="">
><br class="">
> I feel like maybe this should be examined more closely (an example of how each of these would be printed would be ideal, though that might be a bit much) - for example I don't think it makes sense to print out subroutine types like "int subroutine" (rather than "int(float, double)", say) which I /think/ is how they might look based on the current code)<br class="">
<br class="">
<br class="">
Generally agreed, but I think it might make sense to improve this in separate follow-on patches on a case-by-case basis. Getting the pretty-printing entirely right would mean that we would have to implement different pretty-printers for each DW_LANG_foo, since e.g., a C function type would have to be rendered very differently from the same DWARF type-representation in an. e.g., Swift or Fortran context. And even if we choose to always render types as C types it is unclear what to do with types such as DW_TAG_set_type.<br class="">
<br class="">
<br class="">
Repository:<br class="">
rL LLVM<br class="">
<br class="">
<a href="https://reviews.llvm.org/D36993" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D36993</a><br class="">
<br class="">
<br class="">
<br class="">
</blockquote></div>
</div></blockquote></div></div></blockquote></div></div>
</div></blockquote></div></div></blockquote></div></div>
</div></blockquote></div><br class=""></body></html>