[lldb-dev] "target modules load" and breakpoints not working correctly
Ted Woodward via lldb-dev
lldb-dev at lists.llvm.org
Fri Mar 18 16:37:16 PDT 2016
I found why the load addresses are getting dropped. When I do "target modules load", it calls SectionLoadList::SetSectionLoadAddress(), setting the new load address for each section. Then when I attach, DynamicLoaderHexagonDYLD::DidAttach() calls DynamicLoaderHexagonDYLD::UpdateLoadedSections(), which calls Target::SetSectionLoadAddress() for each section, resetting the load address to the address in the relevant file.
If I remove the call to Target::SetSectionLoadAddress(), I can't hit breakpoints. So I need this, but I think I should only do this if the section isn't already loaded.
How do I tell if a section is already loaded?
--
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 4:32 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
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
>>
>>
>
>
More information about the lldb-dev
mailing list