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?

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

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.

I took a moment to look at dwarfdump and it seems like it’s LLVM that’s causing the problem.