[lldb-dev] "target modules load" and breakpoints not working correctly

[Greg Clayton via lldb-dev]

SectionLoadList::SetSectionLoadAddress() in SectionLoadList.cpp

> On Mar 18, 2016, at 1:54 PM, Ted Woodward <ted.woodward at codeaurora.org> wrote:
> 
> I don't see anything in the packet log that would cause the change. Most of the interesting packets (like qShlibInfoAddr, qProcessInfo or qHostInfo) return an empty reply.
> 
> Where should I set a breakpoint to see the load addresses moving?
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
> 
> 
> -----Original Message-----
> From: Greg Clayton [mailto:gclayton at apple.com] 
> Sent: Friday, March 18, 2016 3:12 PM
> To: Ted Woodward <ted.woodward at codeaurora.org>
> Cc: LLDB <lldb-dev at lists.llvm.org>
> Subject: Re: [lldb-dev] "target modules load" and breakpoints not working correctly
> 
> So you will need to find out who is sliding the shared library incorrectly. It might be a packet that is received through the GDB remote protocol, so there might be a bug in your GDB server.
> 
> Greg
> 
>> On Mar 18, 2016, at 11:45 AM, Ted Woodward <ted.woodward at codeaurora.org> wrote:
>> 
>> Your guess is right - the sections moved. Before attaching:
>> 
>> 0x00000008 code             [0x0000000000030000-0x0000000000068d5c)  0x00011000 0x00038d5c 0x00000006 dlopen..text
>> 
>> After attaching:
>> 
>> 0x00000008 code             [0x0000000000010000-0x0000000000048d5c)  0x00011000 0x00038d5c 0x00000006 dlopen..text
>> 
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
>> a Linux Foundation Collaborative Project
>> 
>> -----Original Message-----
>> From: Greg Clayton [mailto:gclayton at apple.com]
>> Sent: Thursday, March 17, 2016 12:44 PM
>> To: Ted Woodward <ted.woodward at codeaurora.org>
>> Cc: LLDB <lldb-dev at lists.llvm.org>
>> Subject: Re: [lldb-dev] "target modules load" and breakpoints not 
>> working correctly
>> 
>> Sounds like something is going wrong when resolving the address. I am guessing that your sections got unloaded when you attached to your GDB remote target. So try this:
>> 
>> (lldb) file u:\lldb_test\dlopen
>> Current executable set to 'u:\lldb_test\dlopen' (hexagon).
>> (lldb) target modules load -f dlopen -s 0x20000
>> (lldb) b main
>> Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address = 
>> 0x00030018
>> 
>> Note we got the address correct. Now do a:
>> 
>> (lldb) image dump sections dlopen
>> 
>> Check to make sure all addresses for the sections look good.
>> 
>> Now do:
>> 
>> (lldb) gdb-remote tedwood-ubuntu:5556
>> (lldb) image dump sections dlopen
>> 
>> I am guessing that the sections have been moved...
>> 
>> Let me know what you find.
>> 
>>> On Mar 16, 2016, at 4:28 PM, Ted Woodward via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>>> 
>>> I’m seeing 2 issues with “target modules load”:
>>> 
>>> 
>>> 
>>> Issue #1: load address is forgotten after a connect:
>>> 
>>> (lldb) file u:\lldb_test\dlopen
>>> Current executable set to 'u:\lldb_test\dlopen' (hexagon).
>>> (lldb) target modules load -f dlopen -s 0x20000
>>> (lldb) b main
>>> Breakpoint 1: where = dlopen`main + 24 at dlopen.c:26, address =
>>> 0x00030018
>>> (lldb) gdb-remote tedwood-ubuntu:5556
>>> 
>>> But it’s set the breakpoint at 0x10018 instead of 0x30018:
>>> ProcessGDBRemote::EnableBreakpointSite (size_id = 14) address =
>>> 0x10018 <  14> send packet: $Z0,10018,4#10
>>> <   4> read packet: $#00
>>> Software breakpoints are unsupported
>>> <  14> send packet: $Z1,10018,4#11
>>> <   6> read packet: $OK#9a
>>> 
>>> (lldb) br l
>>> Current breakpoints:
>>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>> 1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
>>> resolved, hit count = 0
>>> 
>>> 
>>> 
>>> 
>>> Issue #2: breakpoints on the remote server aren’t updated with a new load address, even though they’re updated in the breakpoint list:
>>> 
>>> (lldb) br l
>>> Current breakpoints:
>>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>> 1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00010018, 
>>> resolved, hit count = 0
>>> 
>>> (lldb) target modules load -f dlopen -s 0x20000
>>> (lldb) br l
>>> <   7> send packet: $p29#db
>>> <  12> read packet: $00100000#81
>>> <   7> send packet: $p1d#05
>>> <  12> read packet: $00000000#80
>>> Current breakpoints:
>>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>> 1.1: where = dlopen`main + 24 at dlopen.c:26, address = 0x00030018, 
>>> resolved, hit count = 0
>>> 
>>> (lldb) c
>>> Process 1 stopped
>>> * thread #1: tid = 0x0001, 0x00030018 dlopen`main(argc=1,
>>> argv=0x00052348) + 24 at dlopen.c:26, stop reason = breakpoint 1.1
>>>   frame #0: 0x00030018 dlopen`main(argc=1, argv=0x00052348) + 24 at
>>> dlopen.c:26
>>> 
>>> (lldb) re r pc
>>>     pc = 0x00010018  dlopen`main + 24 at dlopen.c:26
>>> 
>>> Note that lldb says it’s stopped at 0x30018, but it’s really stopped at 0x10018. It never sent a z packet to remove the breakpoint at 0x10018 or a Z packet to add one at 0x30018.
>>> 
>>> --
>>> Qualcomm Innovation Center, Inc.
>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora 
>>> Forum, a Linux Foundation Collaborative Project
>>> 
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 
>> 
> 
>