<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I added the VLA support to clang and lldb about a year ago, so you'll need fairly recent version of both for it to work.<div class=""><br class=""></div><div class="">-- adrian<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 17, 2020, at 12:25 PM, Levo DeLellis <<a href="mailto:levo.delellis@gmail.com" class="">levo.delellis@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">It looks like I wasn't careful and mixed version. I compiled with clang-9 but used lldb-6. Surprisingly this was the only error I notice when mixing these version. I could swear I tried compiling with clang-6. I'd double check but it appears that installing lldb-9 removed lldb(-6) from my system</div><div class="">Thanks for pointing me in the right direction</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 17, 2020 at 11:18 AM Adrian Prantl <<a href="mailto:aprantl@apple.com" class="">aprantl@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">That is interesting. According to LLDB's test/lang/c/vla/* frame variable for a VLA is supposed to work. Frame variable is also supposed to hide the __vla_expr0 artificial helper variable. Is this an older LLDB from your system or an LLDB you built from source? If yes, would you mind filing a bugreport about this?<br class="">
<br class="">
thanks,<br class="">
adrian<br class="">
<br class="">
> On Feb 15, 2020, at 8:17 AM, Levo DeLellis <<a href="mailto:levo.delellis@gmail.com" target="_blank" class="">levo.delellis@gmail.com</a>> wrote:<br class="">
> <br class="">
> Thanks for the suggestions but it doesn't appear to be working correctly for me. I tried building the below after seeing the results with "clang -g -std=c99 test.c" and got the same result<br class="">
> <br class="">
> LLDB thinks MyArray is 81 elements long even though 81 and 80 doesn't show up anywhere in the llvm-ir (I tried again using an llvm ir file made by clang -g -std=c99 test.c -S -emit-llvm and clang -g test.ll)<br class="">
> <br class="">
> $ cat test.c<br class="">
> int foo(int s) {<br class="">
> int MyArray[s];<br class="">
> int i;<br class="">
> for (i = 0; i < s; ++i)<br class="">
> MyArray[i] = s;<br class="">
> return 0;<br class="">
> }<br class="">
> <br class="">
> int main(){<br class="">
> foo(5);<br class="">
> return 0;<br class="">
> }<br class="">
> $ clang -g test.c <br class="">
> $ lldb ./a.out <br class="">
> (lldb) target create "./a.out"<br class="">
> Current executable set to './a.out' (x86_64).<br class="">
> (lldb) break set -f test.c -l 6<br class="">
> Breakpoint 1: where = a.out`foo + 101 at test.c:7, address = 0x0000000000400505<br class="">
> (lldb) r<br class="">
> Process 3205 launched: './a.out' (x86_64)<br class="">
> Process 3205 stopped<br class="">
> * thread #1, name = 'a.out', stop reason = breakpoint 1.1<br class="">
> frame #0: 0x0000000000400505 a.out`foo(s=5) at test.c:7<br class="">
> 4 for (i = 0; i < s; ++i)<br class="">
> 5 MyArray[i] = s;<br class="">
> 6 return 0;<br class="">
> -> 7 }<br class="">
> 8 <br class="">
> 9 int main(){<br class="">
> 10 foo(5);<br class="">
> (lldb) frame variable<br class="">
> (int) s = 5<br class="">
> (unsigned long) __vla_expr0 = 5<br class="">
> (int) i = 5<br class="">
> (int [81]) MyArray = {<br class="">
> [0] = 5<br class="">
> [1] = 5<br class="">
> [2] = 5<br class="">
> [3] = 5<br class="">
> [4] = 5<br class="">
> [5] = 0<br class="">
> [6] = -136481184<br class="">
> [7] = 32767<br class="">
> [8] = -8408<br class="">
> [9] = 32767<br class="">
> [10] = -8544<br class="">
> [11] = 32767<br class="">
> [12] = 1<br class="">
> [13] = 5<br class="">
> [14] = 5<br class="">
> [15] = 0<br class="">
> [16] = -8512<br class="">
> [17] = 32767<br class="">
> [18] = 0<br class="">
> [19] = 5<br class="">
> [20] = -8432<br class="">
> [21] = 32767<br class="">
> [22] = 4195641<br class="">
> [23] = 0<br class="">
> [24] = -8208<br class="">
> [25] = 32767<br class="">
> [26] = 0<br class="">
> [27] = 0<br class="">
> [28] = 4195664<br class="">
> [29] = 0<br class="">
> [30] = -140485737<br class="">
> [31] = 32767<br class="">
> [32] = 0<br class="">
> [33] = 32<br class="">
> [34] = -8200<br class="">
> [35] = 32767<br class="">
> [36] = 0<br class="">
> [37] = 1<br class="">
> [38] = 4195616<br class="">
> [39] = 0<br class="">
> [40] = 0<br class="">
> [41] = 0<br class="">
> [42] = -1953144313<br class="">
> [43] = 1284291557<br class="">
> [44] = 4195248<br class="">
> [45] = 0<br class="">
> [46] = -8208<br class="">
> [47] = 32767<br class="">
> [48] = 0<br class="">
> [49] = 0<br class="">
> [50] = 0<br class="">
> [51] = 0<br class="">
> [52] = 1064657415<br class="">
> [53] = -1284291430<br class="">
> [54] = 933978631<br class="">
> [55] = -1284287451<br class="">
> [56] = 0<br class="">
> [57] = 32767<br class="">
> [58] = 0<br class="">
> [59] = 0<br class="">
> [60] = 0<br class="">
> [61] = 0<br class="">
> [62] = -136423629<br class="">
> [63] = 32767<br class="">
> [64] = -136530376<br class="">
> [65] = 32767<br class="">
> [66] = 386784<br class="">
> [67] = 0<br class="">
> [68] = 0<br class="">
> [69] = 0<br class="">
> [70] = 0<br class="">
> [71] = 0<br class="">
> [72] = 0<br class="">
> [73] = 0<br class="">
> [74] = 4195248<br class="">
> [75] = 0<br class="">
> [76] = -8208<br class="">
> [77] = 32767<br class="">
> [78] = 4195290<br class="">
> [79] = 0<br class="">
> [80] = -8216<br class="">
> }<br class="">
> <br class="">
> <br class="">
> On Thu, Feb 13, 2020 at 3:53 PM Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank" class="">aprantl@apple.com</a>> wrote:<br class="">
> Take a look at the IR clang produces for C99 variable-length arrays.<br class="">
> <br class="">
> -- adrian<br class="">
> <br class="">
>> On Feb 13, 2020, at 10:03 AM, Levo DeLellis via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">
>> <br class="">
>> Hi. I searched and the closest thing I could find was this <a href="http://lists.llvm.org/pipermail/llvm-dev/2018-February/121348.html" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/pipermail/llvm-dev/2018-February/121348.html</a><br class="">
>> <br class="">
>> Currently a known sized array looks and debugs as expected. I use llvm.dbg.declare with DICompositeType tag: DW_TAG_array_type and the size field. In my language arrays are always passed around with a pointer and size pair. I'd like debugging to show up as nicely instead of a pointer addr with no information about the elements. How would I do this? I don't use the C API, I output llvm-ir directly. I was hoping I can call llvm.dbg.declare/addr/value to specify the pointer, name and size of the variable but I really have no idea how to pass the size to the debugger.<br class="">
>> <br class="">
>> _______________________________________________<br class="">
>> LLVM Developers mailing list<br class="">
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
> <br class="">
<br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>