[lldb-dev] Is bitcast breaking lldb a bug?

[Adrian Prantl via lldb-dev]

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 at 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 at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20200302/909f514a/attachment.html>