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

[Zachary Turner]

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/6ee07c1b/attachment.html>