[llvm-dev] Have the debugger show an away with a dynamic size? (original) (raw)
Adrian Prantl via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 17 12:27:58 PST 2020
- Previous message: [llvm-dev] Have the debugger show an away with a dynamic size?
- Next message: [llvm-dev] [RFC] Extension to TableGen's AssemblerPredicates to support combining features with ORs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
-- adrian
On Feb 17, 2020, at 12:25 PM, Levo DeLellis <levo.delellis at gmail.com> wrote:
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 Thanks for pointing me in the right direction On Mon, Feb 17, 2020 at 11:18 AM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: _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 vlaexpr0 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? thanks, adrian > On Feb 15, 2020, at 8:17 AM, Levo DeLellis <levo.delellis at gmail.com <mailto:levo.delellis at gmail.com>> wrote: > > 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 > > 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) > > $ cat test.c > int foo(int s) { > int MyArray[s]; > int i; > for (i = 0; i < s; ++i)_ _> MyArray[i] = s; > return 0; > } > > int main(){ > foo(5); > return 0; > } > $ clang -g test.c > $ lldb ./a.out > (lldb) target create "./a.out" > Current executable set to './a.out' (x8664). > (lldb) break set -f test.c -l 6 > Breakpoint 1: where = a.out
foo + 101 at test.c:7, address = 0x0000000000400505_ _> (lldb) r_ _> Process 3205 launched: './a.out' (x8664)_ _> Process 3205 stopped_ _> * thread #1, name = 'a.out', stop reason = breakpoint 1.1_ _> frame #0: 0x0000000000400505 a.out
foo(s=5) at test.c:7 > 4 for (i = 0; i < s; ++i)_ _> 5 MyArray[i] = s; > 6 return 0; > -> 7 } > 8 > 9 int main(){ > 10 foo(5); > (lldb) frame variable > (int) s = 5 _> (unsigned long) vlaexpr0 = 5 > (int) i = 5 > (int [81]) MyArray = { > [0] = 5 > [1] = 5 > [2] = 5 > [3] = 5 > [4] = 5 > [5] = 0 > [6] = -136481184 > [7] = 32767 > [8] = -8408 > [9] = 32767 > [10] = -8544 > [11] = 32767 > [12] = 1 > [13] = 5 > [14] = 5 > [15] = 0 > [16] = -8512 > [17] = 32767 > [18] = 0 > [19] = 5 > [20] = -8432 > [21] = 32767 > [22] = 4195641 > [23] = 0 > [24] = -8208 > [25] = 32767 > [26] = 0 > [27] = 0 > [28] = 4195664 > [29] = 0 > [30] = -140485737 > [31] = 32767 > [32] = 0 > [33] = 32 > [34] = -8200 > [35] = 32767 > [36] = 0 > [37] = 1 > [38] = 4195616 > [39] = 0 > [40] = 0 > [41] = 0 > [42] = -1953144313 > [43] = 1284291557 > [44] = 4195248 > [45] = 0 > [46] = -8208 > [47] = 32767 > [48] = 0 > [49] = 0 > [50] = 0 > [51] = 0 > [52] = 1064657415 > [53] = -1284291430 > [54] = 933978631 > [55] = -1284287451 > [56] = 0 > [57] = 32767 > [58] = 0 > [59] = 0 > [60] = 0 > [61] = 0 > [62] = -136423629 > [63] = 32767 > [64] = -136530376 > [65] = 32767 > [66] = 386784 > [67] = 0 > [68] = 0 > [69] = 0 > [70] = 0 > [71] = 0 > [72] = 0 > [73] = 0 > [74] = 4195248 > [75] = 0 > [76] = -8208 > [77] = 32767 > [78] = 4195290 > [79] = 0 > [80] = -8216 > } > > > On Thu, Feb 13, 2020 at 3:53 PM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > Take a look at the IR clang produces for C99 variable-length arrays. > > -- adrian > >> On Feb 13, 2020, at 10:03 AM, Levo DeLellis via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi. I searched and the closest thing I could find was this http://lists.llvm.org/pipermail/llvm-dev/2018-February/121348.html <http://lists.llvm.org/pipermail/llvm-dev/2018-February/121348.html> >> >> Currently a known sized array looks and debugs as expected. I use llvm.dbg.declare with DICompositeType tag: DWTAGarraytype 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. >> _>> ________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200217/450c833d/attachment.html>
- Previous message: [llvm-dev] Have the debugger show an away with a dynamic size?
- Next message: [llvm-dev] [RFC] Extension to TableGen's AssemblerPredicates to support combining features with ORs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]