[lldb-dev] [Bug 43126] New: [lldb] Print command reports incorrect struct field value
https://bugs.llvm.org/show_bug.cgi?id=43126
Bug ID: 43126
Summary: [lldb] Print command reports incorrect struct field
value
Product: lldb
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: orlando.hy...@sony.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
Created attachment 22433
--> https://bugs.llvm.org/attachment.cgi?id=22433&action=edit
bug reproducer
Summary:
lldb is reporting a local struct field as '0' when the correct value (200) has
not been described by any DWARF after compiling the attachment 'bug.cpp' at O2.
This bug was found using dexter[0].
llvm (lldb and clang) version this bug was reported with*:
git 91824678868
svn 369769
*not necessarily when it was introduced.
With the attached test case, variable basket.bananas is incorrectly
reported as '0' between lines [22, 25] when compiled at O2:
```
$ clang -g -O2 bug.cpp
$ lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) b foo
Breakpoint 1: where = a.out`foo(Box const&) + 1 at bug.cpp:18:19, address =
0x00400491
(lldb) b 22
Breakpoint 2: where = a.out`foo(Box const&) + 16 at bug.cpp:22:3, address =
0x004004a0
(lldb) b 25
Breakpoint 3: where = a.out`foo(Box const&) + 26 at bug.cpp:25:3, address =
0x004004aa
(lldb) process launch
Process 22427 launched: 'a.out' (x86_64)
Process 22427 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00400491 a.out`foo(box=0x7fffe038) at
bug.cpp:18:19
15 __attribute__((noinline))
16 void foo(const Box& box)
17 {
-> 18 Basket basket = box.baskets[2];
19 do_something(basket.apples); // DexLabel('a')
20
21 basket.apples = 55;
(lldb) p box
(const Box) $0 = {
baskets = {
[0] = (apples = 1, bananas = 2)
[1] = (apples = 10, bananas = 20)
[2] = (apples = 100, bananas = 200)
}
}
(lldb) c
Process 22427 resuming
Process 22427 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 2.1
frame #0: 0x004004a0 a.out`foo(box=) at bug.cpp:22:3
19 do_something(basket.apples); // DexLabel('a')
20
21 basket.apples = 55;
-> 22 do_something(basket.apples); // DexLabel('b')
23
24 basket.apples = basket.bananas;
25 do_something(basket.apples); // DexLabel('c')
(lldb) p basket
(Basket) $1 = (apples = 55, bananas = 0)
(lldb) c
Process 22427 resuming
Process 22427 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 3.1
frame #0: 0x004004aa a.out`foo(box=) at bug.cpp:25:3
22 do_something(basket.apples); // DexLabel('b')
23
24 basket.apples = basket.bananas;
-> 25 do_something(basket.apples); // DexLabel('c')
26 }
27
28
(lldb) p basket
(Basket) $2 = (apples = 55, bananas = 0)
```
The DWARF doesn't describe basket.bananas at all. The only reference to basket
is as follows:
```
$ llvm-dwarfdump --name=basket a.out
a.out: file format ELF64-x86-64
0x0087: DW_TAG_variable
DW_AT_location(0x0023
[0x004004a0, 0x004004af): DW_OP_constu 0x37,
DW_OP_stack_value, DW_OP_piece 0x2)
DW_AT_name("basket")
DW_AT_decl_file ("bug.cpp")
DW_AT_decl_line (18)
DW_AT_type(0x00ff "Basket")
```
The actual value of basket.bananas is 200 (as shown in the lldb session above
with command 'p box').
Given that the dwarf doesn't describe the basket.bananas at all I would expect
basket.bananas to be shown as 'optimized away' or something similar. However it
is handled it should not be showing '0'.
gdb says that basket.bananas is a 'synthetic pointer'. I'm not sure exactly
what this means or if it is the correct message for this scenario, but I
thought it was worth mentioning.
[0]: https://github.com/SNSystems/dexter
--
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Any plan to support to debug Webassembly file?
You would need to implement an ObjectFile and SymbolFile plugin for your .wasm files for lldb to make a Target for them. Jim > On Aug 26, 2019, at 6:27 PM, Terry Guo via lldb-dev > wrote: > > Hi Raphael, > > Thanks for your recommendation. How about the very first step which > enables LLDB to recognize the wasm bytecode via commands like "lldb > my.wasm" or "file my.wasm" inside lldb? And IMHO the second step is to > enable LLDB to recognize the dwarf sections embedded in wasm bytecode > file. Do you have any suggestion where to start? I searched around and > couldn't find useful instructions/documentations for above two steps. > > BR, > Terry > > > On Mon, Aug 26, 2019 at 7:03 PM Raphael “Teemperor” Isemann > wrote: >> >> +lldb-dev >> >> On 26. Aug 2019, at 12:57, Raphael “Teemperor” Isemann >> wrote: >> >> If I understand correctly your VM is your own custom wasm interpreter/JIT? >> If yes, then I don’t think it is realistic that LLDB can ever support it out >> of the box. But you can write a LLDB plugin that calls your own >> interpreter-implementations of functions such as stepping/continue/settings >> breakpoints, etc. Quick google search shows this example of doing the same >> for the Ruby interpreter that hopefully illustrates what I mean: >> https://christoph.luppri.ch/articles/ruby/debugging-ruby-programs-on-osx-with-lldb/ >> >> - Raphael >> >> On 26. Aug 2019, at 12:37, Terry Guo wrote: >> >> Hi Raphael, >> >> Thanks. I mean the first case, attaching to my vm and then debugging via >> LLDB like setting breakpoint, single step or viewing the memory of wasm >> application. >> >> BR, >> Terry >> >> On Mon, Aug 26, 2019 at 5:59 PM Raphael “Teemperor” Isemann >> wrote: >>> >>> I’m not sure I understand what the question is. Do you want that LLDB >>> attachs to the wasm program running inside your VM and then debug the wasm >>> program via LLDB? Or that LLDB can run the wasm module itself like an >>> executable and then run it/step through it/inspect it/etc.? >>> >>> Cheers, >>> - Raphael >>> On 26. Aug 2019, at 11:47, Terry Guo via lldb-dev wrote: Hi there, I am working on a project which involves compiling C++ source file to Webassembly byte code file with LLVM. The LLVM works well and can generate wasm byte code file with DWARF debug sections like .debug_line. I can run the generated wasm file with my wasm virtual machine. However I find LLDB doesn't support debugging wasm file. Do we have plan to enable LLDB debugging wasm file? Thanks for any information. BR, Terry ___ 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 ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
