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
