<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 14, 2019 at 1:33 PM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 14, 2019 at 1:27 PM Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Nov 14, 2019, at 1:21 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
> <br>
> Hey folks,<br>
> <br>
> Would you all mind having a bit of a design discussion around the feature both at the DWARF level and the LLVM implementation? It seems like what's currently being proposed/reviewed (based on the DWARF feature as spec'd) is a pretty big change & I'm not sure I understand the motivation, exactly.<br>
> <br>
> The core point of my confusion: Why does describing the thing a pointer points to require describing a named variable that it points to? What if it doesn't point to a named variable? <br>
<br>
Without having looked at the motivational text when the feature was proposed to DWARF, my assumption was that this is similar to how bounds for variable-length arrays are implemented, where a (potentially) artificial variable is created by the compiler in order to have something to refer to.</blockquote><div><br>I /sort/ of see that case as a bit different, because the array type needs to refer back into the function potentially (to use frame-relative, etc). I could think of other ways to do that in hindsight (like putting the array type definition inside the function to begin with & having the count describe the location directly, for instance).<br></div></div></div></blockquote><div><br>Hey, what'd you know, GCC actually produces what I described:<br><font face="monospace"><br>  DW_TAG_array_type [6] *<br>    DW_AT_type [DW_FORM_ref4]       (cu + 0x0069 => {0x00000069} "int")<br>    DW_AT_sibling [DW_FORM_ref4]    (cu + 0x0083 => {0x00000083})<br><br>    DW_TAG_subrange_type [7]  <br>      DW_AT_type [DW_FORM_ref4]     (cu + 0x0083 => {0x00000083} "long unsigned int")<br>      DW_AT_upper_bound [DW_FORM_exprloc]   (DW_OP_fbreg -40, DW_OP_deref)</font><br><br>No artificial variable the way Clang does it:<br><br><font face="monospace">  DW_TAG_subprogram<br>    DW_TAG_variable [4]  <br>                  DW_AT_location [DW_FORM_exprloc]      (DW_OP_fbreg -24)<br>                  DW_AT_name [DW_FORM_strp]     ( .debug_str[0x000000a6] = "__vla_expr0")<br>                  DW_AT_type [DW_FORM_ref4]     (cu + 0x0074 => {0x00000074} "long unsigned int")<br>                  DW_AT_artificial [DW_FORM_flag_present]       (true)<br><br>    DW_TAG_variable<br>      ...<br>      DW_AT_type [DW_FORM_ref4]     (cu + 0x007b => {0x0000007b} "int[]")<br><br>  DW_TAG_array_type [7] *<br>    DW_AT_type [DW_FORM_ref4]       (cu + 0x006d => {0x0000006d} "int")<br><br>  DW_TAG_subrange_type [8]  <br>    DW_AT_type [DW_FORM_ref4]     (cu + 0x008b => {0x0000008b} "__ARRAY_SIZE_TYPE__")<br>    DW_AT_lower_bound [DW_FORM_data1]     (0x00)<br>    DW_AT_count [DW_FORM_ref4]    (cu + 0x0051 => {0x00000051})</font><br> <br>Might be nice to tidy that up some time. GCC's been doing this even in DWARF-2 mode (where it just uses FORM_black for the upper bound, and as far back as GCC 6.0 at least.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> In retrospect I find the entire specification of DW_OP_implicit_pointer to be strangely specific/limited (why one hard-coded offset instead of an arbitrary expression?), but that ship has sailed for DWARF 5 and I'm to blame for not voicing that concern earlier.<br></blockquote><div><br></div><div>Sure, but we don't have to implement it if we don't find it to be super useful/worthwhile, right? (if something else would be particularly more general/useful we could instead implement that as an extension, though of course there's cost to that in terms of consumer support, etc)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
-- adrian<br>
<br>
> <br>
> Seems like there should be a way to describe that situation - and that doing so would be a more general solution than one limited to only describing pointers that point to named variables. And would be a simpler implementation in LLVM - without having to deconstruct variables during optimizations, etc, to track one variable's value being concretely related to another variable's value.<br>
> <br>
> - David<br>
<br>
</blockquote></div></div>
</blockquote></div></div>