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

[Levo DeLellis via lldb-dev]

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 <aprantl at 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 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)
>
> 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/9da5c592/attachment-0001.html>