Hi Greg,
I have this issue that I suspect is a bug in lldb’s handling of DW_OP_deref.
I wasn’t able to craft an easy C++ testcase, so I’ll start from my
motivating (swift) example.
Given the following code:
func use<T>(_ t : T) {}
func single<T>(_ t : T) {
let x = t
use(x)
}
let s = "hello"
single(s)
The IR emitted for the local binding `x` in `single<T>` is an alloca
containing the address of `x`. Hence, the DWARF, correctly contains a
DW_OP_deref expression, i.e.:
0x000000da: TAG_variable [9]
AT_location( fbreg -16, deref )
AT_name( "x" )
AT_decl_file(
"/Users/dcci/work/swift/build/Ninja-RelWithDebInfoAssert+stdlib-RelWithDebInfo/swift-macosx-x86_64/bin/pat.swift"
)
AT_decl_line( 4 )
AT_type( {0x00000204} ( $sxD ) )
When I debug this with lldb, I expect lldb to print the value that’s
pointed by %rbp - 16,
i.e.
(lldb) register read $rbp
rbp = 0x00007ffeefbff860
(lldb) mem read 0x00007ffeefbff850
0x7ffeefbff850: 10 f8 bf ef fe 7f 00 00 b8 32 4d 00 01 00 00 00
.????...?2M.....
0x7ffeefbff860: c0 f8 bf ef fe 7f 00 00 64 09 00 00 01 00 00 00
?????...d.......
So, the value that I expected to be printed is 0x7ffeefbff810.
What I instead see in the debugger is:
(T) x = <read memory from 0xe500000000000000 failed (0 of 16 bytes read)>
The value `0xe500000000000000` happens to be the value that’s pointed
by the address 0x7ffeefbff810, that is:
(lldb) mem read 0x7ffeefbff810
0x7ffeefbff810: 00 00 00 00 00 00 00 e5 68 65 6c 6c 6f 00 00 00
.......?hello...
0x7ffeefbff820: 05 00 00 00 00 00 00 00 40 32 4d 00 01 00 00 00
........@2M.....
Is this an expected behavior? I did expect DW_OP_deref to just do a
single dereference and not two. It looks like when we call
`UpdateValue()` in lldb we do have the correct value in `m_value`, but
GetPointerValue() ends up printing the value that’s *pointed by*
what’s in `m_value`, i.e.
m_integer = {
U = {
VAL = 0x00007ffeefbff810
pVal = 0x00007ffeefbff810
}
as this is a LoadAddress. Greg, as you wrote this code (and touched it
last), what do you expect to be the correct semantic here?
Removing a dereference from DW_OP_deref in the DWARFASTParser works
around the issue, but I’m fairly sure it’s the incorrect fix. Are we
maybe setting the value type incorrectly?
Best,
—
Davide
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
