[lldb-dev] Creating a breakpoint on a target with no process

[Zachary Turner]

+Virgile Bello <virgile.bello at gmail.com>​

Actually maybe Virgile can respond and explain the purpose of the
DynamicLoaderWindows plugin he's written here [
https://github.com/xen2/lldb/commit/515956244784a9162183a6135068e893ba994532].
The description of the plugin seems to indicate that it watches for Dynamic
Library loads and unloads, but it's not clear what the code itself does, or
how it's related to watching for DLL loads and unloads.

On Tue Dec 02 2014 at 1:15:29 PM Zachary Turner <zturner at google.com> wrote:

> I actually don't even have a dynamic loader plugin implemented at all.  I
> wasn't completely sure what the purpose of it was.  I saw that Virgile had
> implemented one in his original patch to get debugging working on Windows [
> https://github.com/xen2/lldb/commit/515956244784a9162183a6135068e893ba994532],
> but it did very little actual work, and in particular does not seem to do
> anything related to what you are suggesting above.
>
> As for adding new modules when they load, basically this is the entirety
> of what I do.
>
>     Error error;
>     ModuleSP module = GetTarget().GetSharedModule(module_spec, &error);
>     module->SetLoadAddress(GetTarget(), module_addr, false, false);
>
> However, as mentioned I don't do this from a DynamicLoader plugin.
> Instead I just run this code directly from the same background thread that
> gets other debug events from the process, such as thread creation,
> exceptions, etc.
>
> I guess can you elaborate a little bit on the interaction between the
> DynamicLoader plugin and the process plugin, and the responsibilities of
> each?
>
> On Tue Dec 02 2014 at 1:07:35 PM <jingham at apple.com> wrote:
>
>> It is the responsibility of the dynamic loader plugin to tell the
>> breakpoints to re-scan for new locations when shared libraries get added to
>> the process.  You should do this by collecting a list of the added
>> libraries, and calling:
>>
>> m_process->GetTarget().ModulesDidLoad(added_list);
>>
>> How are you adding new modules as they get loaded?
>>
>> Jim
>>
>>
>> > On Dec 2, 2014, at 12:45 PM, Zachary Turner <zturner at google.com> wrote:
>> >
>> > In my effort to get tests working on Windows, I've run across an issue
>> with test\expression_command\timeout\TestCallWithTimeout.py ::
>> TestCallWithTimeout.ExprCommandWithTimeoutsTestCase
>> >
>> > This test creates a target and immediately puts a breakpoint on it
>> before attempting to launch the process.  Is this something that is
>> supposed to work?  BreakpointLocation::ResolveBreakpointSite() contains
>> this line:
>> >
>> >     Process *process = m_owner.GetTarget().GetProcessSP().get();
>> >     if (process == NULL)
>> >         return false;
>> >
>> > So naturally the breakpoint site cannot be resolved because there is no
>> process.  The end result of this is that this breakpoint never gets hit and
>> the test fails.
>> >
>> > Presumably this test works on other platforms, so any tips as to where
>> I should look to track down this bug on Windows?
>> > _______________________________________________
>> > lldb-dev mailing list
>> > lldb-dev at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141202/527ec5d9/attachment.html>