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:gclay...@apple.com] Sent: Friday, March 18, 2016 4:32 PM To: Ted Woodward <ted.woodw...@codeaurora.org> Cc: LLDB <lldb-dev@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.woodw...@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:gclay...@apple.com] > Sent: Friday, March 18, 2016 3:12 PM > To: Ted Woodward <ted.woodw...@codeaurora.org> > Cc: LLDB <lldb-dev@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.woodw...@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:gclay...@apple.com] >> Sent: Thursday, March 17, 2016 12:44 PM >> To: Ted Woodward <ted.woodw...@codeaurora.org> >> Cc: LLDB <lldb-dev@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@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@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> >> > > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
