<div dir="ltr"><div>Thanks this has been very helpful</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 2, 2020 at 4:02 PM Adrian Prantl <<a href="mailto:aprantl@apple.com">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 Feb 25, 2020, at 5:29 PM, Levo DeLellis via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
<br>
These are really LLVM questions. Basically:<br>
<br>
- if you can see the variable with dwarfdump and it doesn't show up in LLDB, you should ask on lldb-dev<br>
- if you can't see the variable with dwarfdump, you should ask on llvm-dev<br>
<br>
A golden rule of thumb is to look at what clang is doing and copy that.<br>
<br>
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.<br>
<br>
> 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).<br>
<br>
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.<br>
<br>
> 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.<br>
> <br>
> How should I tell the debugger about my variables? This page says you are "transitioning away from" llvm.dbg.declare <a href="https://llvm.org/docs/SourceLevelDebugging.html" rel="noreferrer" target="_blank">https://llvm.org/docs/SourceLevelDebugging.html</a> 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? <br>
<br>
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.<br>
<br>
> <br>
> Is it possible to say ignore my variable until I hit this specific?<br>
> My language uses constructors so I often have to execute code before pointers become valid.<br>
<br>
Yes, dbg.value(undef, ...) followed by another dbg.value will do that explicitly.<br>
<br>
You can not achieve this with dbg.declare because it is global.<br>
<br>
> 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<br>
> <br>
> 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?<br>
<br>
Depends on the kind of code you generate.<br>
<br>
> 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)<br>
> <br>
> Thank you for reading and thank you for any help<br>
> <br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div>