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 <apra...@apple.com> 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
