[lldb-dev] "target modules load" and breakpoints not working correctly
Ted Woodward via lldb-dev
lldb-dev at lists.llvm.org
Fri Mar 18 13:54:10 PDT 2016
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
>
>
More information about the lldb-dev
mailing list