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 > <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
