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

[Greg Clayton via lldb-dev]

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
> 
>