If you call SetExecutableModule while a process is running, we probably need to
ask the dynamic loader plug-in to update the loaded shared libraries. We might
actually need to clear the dynamic loader and let the process load a new one
since some dynamic loaders might use the executable to figure out if the
dynamic loader should be loaded. It might be better to add a new function to
Process.cpp:
void
Process::ExecutableChanged()
{
// Called when the executable is changed while a process is running.
// Let the dynamic loader reload itself in case a different dynamic loader
// might be selected with a different main executable.
m_dyld_ap.reset();
DynamicLoader *dyld = GetDynamicLoader();
if (dyld)
dyld->DidAttach();
}
This way even if breakpoints did get unresolved, the should get set again when
the dynamic loader loads the shared libraries.
Thoughts Jim?
> On Nov 16, 2016, at 2:25 PM, Ted Woodward via lldb-dev
> <[email protected]> wrote:
>
>
> I tried having SetExecutableModule call ModuleDidLoad after appending the
> executable to m_images, but it didn't work. It eventually drills down to call
> GetSectionLoadList, which is empty. Probably because the module list got
> cleared. Any thoughts on how to clean up the new module list, and add the
> breakpoints back?
>
> That leads me to think that other modules besides the executable would just
> be lost.
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]]
>> Sent: Wednesday, November 16, 2016 2:12 PM
>> To: Ted Woodward <[email protected]>
>> Cc: LLDB <[email protected]>
>> Subject: Re: [lldb-dev] "image search-paths add" removes all breakpoints
>> from remote server
>>
>>
>>> On Nov 16, 2016, at 12:03 PM, Ted Woodward via lldb-dev <lldb-
>> [email protected]> wrote:
>>>
>>> Is “image search-paths add” supposed to remove all breakpoints from the
>> remote server? I don’t think it should be doing this.
>>>
>>> PathMappingList::Append calls Target::ImageSearchPathsChanged, which
>> calls Target::SetExecutableModule, which calls Target::ClearModules, which
>> removes the breakpoints. But SetExecutableModule doesn’t restore the
>> breakpoints.
>>>
>>>
>>>
>>> This test I use top-of-tree lldb, built on Ubuntu 12 with a native target.
>> Packet log edited to remove chaff.
>>>
>>> (lldb) log enable gdb-remote packets
>>> (lldb) process launch –s
>>> Process 18766 launched: '/usr2/tedwood/lldb_test/factlin' (x86_64)
>>> (lldb) process status
>>> Process 18766 stopped
>>> * thread #1, name = 'factlin', stop reason = signal SIGSTOP
>>> frame #0: 0x00007ffff7ddb6b0
>>> -> 0x7ffff7ddb6b0: movq %rsp, %rdi
>>> 0x7ffff7ddb6b3: callq 0x7ffff7ddf010
>>> 0x7ffff7ddb6b8: movq %rax, %r12
>>> 0x7ffff7ddb6bb: movl 0x2215ff(%rip), %eax
>>> (lldb) b main
>>> < 15> send packet: $Z0,400586,1#4a
>>> < 6> read packet: $OK#9a
>>> Breakpoint 1: where = factlin`main + 22 at factorial.c:32, address =
>>> 0x0000000000400586
>>> (lldb) br l
>>> Current breakpoints:
>>> 1: name = 'main', locations = 1, resolved = 1, hit count = 0
>>> 1.1: where = factlin`main + 22 at factorial.c:32, address =
>>> 0x0000000000400586, resolved, hit count = 0
>>> (lldb) image search-paths add /local /tmp < 15> send packet:
>>> $z0,400586,1#6a
>>> < 6> read packet: $OK#9a
>>> < 15> send packet: $z0,400410,1#5c
>>> < 6> read packet: $OK#9a
>>> (lldb) br l
>>> Current breakpoints:
>>> 1: name = 'main', locations = 1
>>> 1.1: where = factlin`main + 22 at factorial.c:32, address =
>>> factlin[0x0000000000400586], unresolved, hit count = 0
>>> (lldb) c
>>> < 5> send packet: $c#63
>>> Process 18766 resuming
>>> Factorial of 10 is 3628800
>>> < 7> read packet: $W00#b7
>>> Process 18766 exited with status = 0 (0x00000000)
>>
>> This is a distinction without much difference, but the break list output is
>> actually telling you somebody forgot to re-install the breakpoints. Note the
>> state went from resolved (i.e. there is a site in the targeted process for
>> this
>> breakpoint location) to unresolved. Still a bug, but the breakpoints aren't
>> lying to you...
>>
>> When you added search paths, all the breakpoints needed to be re-set, since
>> the symbol world might have changed. But apparently only the removal part
>> is getting done.
>>
>> Jim
>>
>>
>>>
>>> As you can see, the breakpoint at main was removed on lldb-server, but
>> shows as active in the breakpoint list. When I continue, the breakpoint isn’t
>> hit, and the target runs to completion.
>>>
>>> --
>>> 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
>>> [email protected]
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
