Re: [lldb-dev] What are the 'rules' to play nice with lldb-9?
Thanks this has been very helpful On Mon, Mar 2, 2020 at 4:02 PM Adrian Prantl wrote: > > > > On Feb 25, 2020, at 5:29 PM, Levo DeLellis via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > I'm thoroughly confused so I may say incorrect thing. I don't expect any > replies to this entire post but bits would be helpful. I'll double check if > you need me to be specific since it's likely I remember or ran something > wrong. For my language I output llvm-ir directly so I may generate llvm-ir > that the llvm api does not and I may create very specific ir if I need to. > > > > I noticed a number of things. When I declare something with > llvm.dbg.declare it doesn't happen where I declare it but at the start of > the function? I put my alloca's at the start of the function like llvm > recommends so I have invalid pointers and invalid array sizes which causes > vscode to crash. Which is fine I'm sure I can write null and say the size > is 0 before the first line of the function. > > These are really LLVM questions. Basically: > > - if you can see the variable with dwarfdump and it doesn't show up in > LLDB, you should ask on lldb-dev > - if you can't see the variable with dwarfdump, you should ask on llvm-dev > > A golden rule of thumb is to look at what clang is doing and copy that. > > The location of a dbg.declare is mostly irrelevant, since there can only > be one dbg.declare per variable and it is valid throughout the entire scope. > > > I thought maybe I can use llvm.dbg.addr to work around the problem but I > never got it working in the way I hoped (Does it execute at the start of > the function? which explains why my unexpected results). > > I don't understand the question here. It would be helpful to post a > minimal example, and look at the output of -print-after-all to see how it > is transformed by the various passes, so you can ask a more directed > question. > > > I manage to have some good results with llvm.dbg.value. I noticed if I > put a value in a local variable and use `llvm.dbg.value(i64 %abc` there's a > high likelihood it will have an incorrect value or will be wrong once I > step through more code. However i64 1234 always seem to work. > > > > How should I tell the debugger about my variables? This page says you > are "transitioning away from" llvm.dbg.declare > https://llvm.org/docs/SourceLevelDebugging.html I see llvm.dbg.addr says > to only use it once and I had some luck with llvm.dbg.value. How do I > decide when to use llvm.dbg.value vs llvm.dbg.addr? May I use > llvm.dbg.value on a variable that I didn't specific with llvm.dbg.addr? > (for example a const value in a variable that has no address)? What about > an array passed in from a function? Do I need to store the pointer and or > length to a variable to give it an address before the debugger can > understand it? > > If your variables "live" on the stack, such as in clang -O0 code, you > should use one dbg.declare per variable. Otherwise you'll need at least one > dbg.value per SSA value that carries a variable value. > > > > > Is it possible to say ignore my variable until I hit this specific? > > My language uses constructors so I often have to execute code before > pointers become valid. > > Yes, dbg.value(undef, ...) followed by another dbg.value will do that > explicitly. > > You can not achieve this with dbg.declare because it is global. > > > The language also cleans up so on a return statement as a 'hack' I > execute `br false, label %dummy123, label %dummy123, !dbg > !123\ndummy123:\n` so the user can see the variables before the cleanup > happens/pointers get freed. I mentioned earlier when using vscode having > invalid array pointer and invalid size (very large number) made vscode > crash. I'm not sure what happened but I had lldb-mi-9 take up many gb > (30gb+) in some situations so it may not be a literal crash in the process > but locks up and do undesirable behavior > > > > I don't expect to get all the answers but maybe a piece here and there > will help. Should I continue to use llvm.dbg.declare for now with lldb 9? > or should I use llvm.dbg.addr and llvm.dbg.value? > > Depends on the kind of code you generate. > > > Should I always initialize my variables to 0? (so I don't crash vscode > when it uses lldb-mi-9) Is there a way I can say ignore this variable until > I hit line X where I know the memory will be initialized fully? Do I need > to worry about the order I initialize variables or the order I call > llvm.dbg.addr? (I remember, call llvm.dbg.addr once per variable) > > > > Thank you for reading and thank you for any help > > > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Is bitcast breaking lldb a bug?
I took a moment to look at dwarfdump and it seems like it's LLVM that's
causing the problem.
On Mon, Mar 2, 2020 at 4:04 PM Adrian Prantl wrote:
> Does this still reproduce with lldb compiled from the current state of the
> git repository (ToT)?
>
> How do you know that it is LLDB loosing the variable and not clang? Does
> clang produce a location for the variable when you look at the dwarfdump
> output?
>
> -- adrian
>
> On Feb 26, 2020, at 3:31 AM, Levo DeLellis via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> This feels like a bug to me. Yesterday I was asking what the rules were
> because it felt like things change and break randomly. Now I have a good
> example. (link to my email yesterday
> http://lists.llvm.org/pipermail/lldb-dev/2020-February/015989.html)
>
> Take this example source file
>
> int main() {
> int dummy = 25;
> short wtf[dummy];
> memset(wtf, 0, dummy*sizeof(*wtf));
> return 0;
> }
>
> Now emit the llvm-ir so we can edit it
>
> clang -g test.c -S -emit-llvm
>
> Before line 21 write this line
>
> %z8 = bitcast i16* %8 to i16*
>
> Change the `metadata i16* %8` to `metadata i16* %z8`. Compile it then
> debug line 4 `clang -g wtf.ll` `lldb-9 ./a.out` `break set -f test.c -l 4`
> `r` `frame variable`
>
> You'll see the array doesn't show up. If you change %z8 back to %8 it will
> reappear. Is this a bug or can I not use bitcast when I'm trying to do
> things with llvm.dbg.declare/addr/value?
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Is bitcast breaking lldb a bug?
To answer your question, I have no idea. I have limited knowledge of DWARF,
LLDB and LLVM. I haven't tried to compile llvm, lldb or anything (meaning I
only tried in llvm 9 and lldb 9). I been working on my language far to much
to be looking at anything else and this isn't really blocking my progress.
On Mon, Mar 2, 2020 at 4:04 PM Adrian Prantl wrote:
> Does this still reproduce with lldb compiled from the current state of the
> git repository (ToT)?
>
> How do you know that it is LLDB loosing the variable and not clang? Does
> clang produce a location for the variable when you look at the dwarfdump
> output?
>
> -- adrian
>
> On Feb 26, 2020, at 3:31 AM, Levo DeLellis via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> This feels like a bug to me. Yesterday I was asking what the rules were
> because it felt like things change and break randomly. Now I have a good
> example. (link to my email yesterday
> http://lists.llvm.org/pipermail/lldb-dev/2020-February/015989.html)
>
> Take this example source file
>
> int main() {
> int dummy = 25;
> short wtf[dummy];
> memset(wtf, 0, dummy*sizeof(*wtf));
> return 0;
> }
>
> Now emit the llvm-ir so we can edit it
>
> clang -g test.c -S -emit-llvm
>
> Before line 21 write this line
>
> %z8 = bitcast i16* %8 to i16*
>
> Change the `metadata i16* %8` to `metadata i16* %z8`. Compile it then
> debug line 4 `clang -g wtf.ll` `lldb-9 ./a.out` `break set -f test.c -l 4`
> `r` `frame variable`
>
> You'll see the array doesn't show up. If you change %z8 back to %8 it will
> reappear. Is this a bug or can I not use bitcast when I'm trying to do
> things with llvm.dbg.declare/addr/value?
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Is bitcast breaking lldb a bug?
This feels like a bug to me. Yesterday I was asking what the rules were
because it felt like things change and break randomly. Now I have a good
example. (link to my email yesterday
http://lists.llvm.org/pipermail/lldb-dev/2020-February/015989.html)
Take this example source file
int main() {
int dummy = 25;
short wtf[dummy];
memset(wtf, 0, dummy*sizeof(*wtf));
return 0;
}
Now emit the llvm-ir so we can edit it
clang -g test.c -S -emit-llvm
Before line 21 write this line
%z8 = bitcast i16* %8 to i16*
Change the `metadata i16* %8` to `metadata i16* %z8`. Compile it then debug
line 4 `clang -g wtf.ll` `lldb-9 ./a.out` `break set -f test.c -l 4` `r`
`frame variable`
You'll see the array doesn't show up. If you change %z8 back to %8 it will
reappear. Is this a bug or can I not use bitcast when I'm trying to do
things with llvm.dbg.declare/addr/value?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] What are the 'rules' to play nice with lldb-9?
I'm thoroughly confused so I may say incorrect thing. I don't expect any replies to this entire post but bits would be helpful. I'll double check if you need me to be specific since it's likely I remember or ran something wrong. For my language I output llvm-ir directly so I may generate llvm-ir that the llvm api does not and I may create very specific ir if I need to. I noticed a number of things. When I declare something with llvm.dbg.declare it doesn't happen where I declare it but at the start of the function? I put my alloca's at the start of the function like llvm recommends so I have invalid pointers and invalid array sizes which causes vscode to crash. Which is fine I'm sure I can write null and say the size is 0 before the first line of the function. I thought maybe I can use llvm.dbg.addr to work around the problem but I never got it working in the way I hoped (Does it execute at the start of the function? which explains why my unexpected results). I manage to have some good results with llvm.dbg.value. I noticed if I put a value in a local variable and use `llvm.dbg.value(i64 %abc` there's a high likelihood it will have an incorrect value or will be wrong once I step through more code. However i64 1234 always seem to work. How should I tell the debugger about my variables? This page says you are "transitioning away from" llvm.dbg.declare https://llvm.org/docs/SourceLevelDebugging.html I see llvm.dbg.addr says to only use it once and I had some luck with llvm.dbg.value. How do I decide when to use llvm.dbg.value vs llvm.dbg.addr? May I use llvm.dbg.value on a variable that I didn't specific with llvm.dbg.addr? (for example a const value in a variable that has no address)? What about an array passed in from a function? Do I need to store the pointer and or length to a variable to give it an address before the debugger can understand it? Is it possible to say ignore my variable until I hit this specific? My language uses constructors so I often have to execute code before pointers become valid. The language also cleans up so on a return statement as a 'hack' I execute `br false, label %dummy123, label %dummy123, !dbg !123\ndummy123:\n` so the user can see the variables before the cleanup happens/pointers get freed. I mentioned earlier when using vscode having invalid array pointer and invalid size (very large number) made vscode crash. I'm not sure what happened but I had lldb-mi-9 take up many gb (30gb+) in some situations so it may not be a literal crash in the process but locks up and do undesirable behavior I don't expect to get all the answers but maybe a piece here and there will help. Should I continue to use llvm.dbg.declare for now with lldb 9? or should I use llvm.dbg.addr and llvm.dbg.value? Should I always initialize my variables to 0? (so I don't crash vscode when it uses lldb-mi-9) Is there a way I can say ignore this variable until I hit line X where I know the memory will be initialized fully? Do I need to worry about the order I initialize variables or the order I call llvm.dbg.addr? (I remember, call llvm.dbg.addr once per variable) Thank you for reading and thank you for any help ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Have the debugger show an away with a dynamic size?
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 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
> __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?
>
> thanks,
> adrian
>
> > On Feb 15, 2020, at 8:17 AM, Levo DeLellis
> 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' (x86_64).
> > (lldb) break set -f test.c -l 6
> > Breakpoint 1: where = a.out`foo + 101 at test.c:7, address =
> 0x00400505
> > (lldb) r
> > Process 3205 launched: './a.out' (x86_64)
> > Process 3205 stopped
> > * thread #1, name = 'a.out', stop reason = breakpoint 1.1
> > frame #0: 0x00400505 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) __vla_expr0 = 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 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-...@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
> >>
> >> 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.
> >>
> >> ___
> >> LLVM Developers mailing list
> >> llvm-...@lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Does LLDB work on windows?
I had LLDB working without any effort on linux however I can't seem to get
it working on windows. On this page titled LLDB Status
https://lldb.llvm.org/status.html it says LLDB is working on Windows
(i386). I'm unsure if this means win32 apps, release or OS. I executed the
below using llvm 64bit binary then tried again after uninstalling llvm and
using the win32 binary
LLDB can't seem to find my source file location. Doing a quick search and
looking in https://lldb.llvm.org/lldb-gdb.html I tried using `settings set
target.source-map MYPATH` but it didn't seem to help. `source list` gives
me nothing. I'm using llvm 6. Specifically this build
http://releases.llvm.org/6.0.0/LLVM-6.0.0-win32.exe
$ cat a.c
#include
int main() {
puts("Hello");
return 0;
}
$ clang -g -m32 a.c
$ ./a.exe
Hello
$ lldb a.exe
(lldb) target create "a.exe"
Current executable set to 'a.exe' (i686).
b main
(lldb) b main
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
r
(lldb) r
Process 2908 launching
(lldb) Process 2908 launched: 'C:\Users\LD\Desktop\test\a.exe' (i686)
Hello
Process 2908 exited with status = 0 (0x)
(lldb) exit
(lldb) exit
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
