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 [<a href="https://github.com/xen2/lldb/commit/515956244784a9162183a6135068e893ba994532">https://github.com/xen2/lldb/commit/515956244784a9162183a6135068e893ba994532</a>], but it did very little actual work, and in particular does not seem to do anything related to what you are suggesting above.<br><div><br></div><div>As for adding new modules when they load, basically this is the entirety of what I do.</div><div><br></div><div><div><span style="line-height:1.5">    Error error;</span><br></div><div>    ModuleSP module = GetTarget().GetSharedModule(module_spec, &error);</div><div><span style="line-height:1.5">    module->SetLoadAddress(GetTarget(), module_addr, false, false);</span><br></div></div><div><br></div><div>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.</div><div><br></div><div>I guess can you elaborate a little bit on the interaction between the DynamicLoader plugin and the process plugin, and the responsibilities of each?</div><br><div class="gmail_quote">On Tue Dec 02 2014 at 1:07:35 PM <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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:<br>
<br>
m_process->GetTarget().<u></u>ModulesDidLoad(added_list);<br>
<br>
How are you adding new modules as they get loaded?<br>
<br>
Jim<br>
<br>
<br>
> On Dec 2, 2014, at 12:45 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> In my effort to get tests working on Windows, I've run across an issue with test\expression_command\<u></u>timeout\TestCallWithTimeout.py :: TestCallWithTimeout.<u></u>ExprCommandWithTimeoutsTestCas<u></u>e<br>
><br>
> 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::<u></u>ResolveBreakpointSite() contains this line:<br>
><br>
>     Process *process = m_owner.GetTarget().<u></u>GetProcessSP().get();<br>
>     if (process == NULL)<br>
>         return false;<br>
><br>
> 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.<br>
><br>
> Presumably this test works on other platforms, so any tips as to where I should look to track down this bug on Windows?<br>
> ______________________________<u></u>_________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div>