Hi,<div><br></div><div>I found my problem, and almost everything was my bad. I was giving "process load" a command relative to ~, which it wouldn't expand. dlopen must receive a full, absolute path, so ir would return null. Hence, the "process load" command would fail.</div>
<div><br></div><div>But there's a problem, here. We are not getting a decent error message when the file doesn't exist (my example in the previous mail had an error in the file extension). Neither when the call fails, or when the equivalent expr command fails (there I was expecting to get a $1 = 0x0):</div>
<div><br></div><div><div>(lldb) expr (void*)dlopen("/Users/filipe/src/tests/libmylib.d", 1)</div><div>error: Execution was interrupted, reason: breakpoint site 10.</div><div>The process has been returned to the state before execution.</div>
<div>(lldb) process load ~/src/tests/libmylib.dyliasdasd</div><div>error: failed to load '~/src/tests/libmylib.dyliasdasd': Execution was interrupted, reason: breakpoint site 12.</div><div>The process has been returned to the state before execution.</div>
<div>(lldb) </div></div><div><br></div><div><br></div><div>Thanks for the help,</div><div><br></div><div> Filipe</div><div><br><br><div class="gmail_quote">On Wed, Aug 10, 2011 at 13:36, Filipe Cabecinhas <span dir="ltr"><<a href="mailto:filcab%2Blldb-dev@gmail.com">filcab+lldb-dev@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Thanks for explaining that. I really have no ideia why it's failing. I'm getting this, on the breakpoint log (when issuing the "process load" command):<div>
<br></div><div>
<p>Process 84650 resuming</p>
<p><b><lldb.driver.main-thread> Target::CreateBreakpoint (internal = yes) => break_id = -8: address = 0x0000000100000d70</b></p>
<p><b></b><br></p>
<p><b></b><br></p>
<p><b><lldb.driver.main-thread> Target::RemoveBreakpointByID (break_id = -4, internal = yes)</b></p>
<p><b></b><br></p>
<p><b><lldb.driver.main-thread> Target::DisableBreakpointByID (break_id = -4, internal = yes)</b></p><div class="im">
<p><b></b><br></p>
<p><b>error: failed to load '~/src/tests/libmylib.dyld': Execution was interrupted, reason: breakpoint site 8.</b></p>
<p><b>The process has been returned to the state before execution.</b></p>
<p><b>(lldb) </b></p><p><b><br></b></p></div><p>I suppose that a line would be printed if a breakpoint was hit, which is even weirder. I've tried to dlopen that dylib with gdb (loading the program, stopping at the same spot, executing 'call dlopen(...)' like the call lldb does), and it works. Calling dlopen with an expr command on lldb also works, and that one triggers the dyld breakpoint site that you talked about (location -1.1):</p>
<p>
</p><p><b><br></b></p><p><b>(lldb) expr (int)dlopen("/Users/filipe/src/tests/libmylib.dylib", 1)</b></p>
<p><b></b><br></p>
<p><b><lldb.driver.main-thread> Target::CreateBreakpoint (internal = yes) => break_id = -9: address = 0x0000000100000d70</b></p>
<p><b></b><br></p>
<p><b></b><br></p>
<p><b><lldb.driver.main-thread> Target::RemoveBreakpointByID (break_id = -8, internal = yes)</b></p>
<p><b></b><br></p>
<p><b><lldb.driver.main-thread> Target::DisableBreakpointByID (break_id = -8, internal = yes)</b></p>
<p><b></b><br></p><p>
</p><p><b><lldb.process.internal-state(pid=84685)> Hit breakpoint location: -1.1: </b></p>
<p><b> module = /usr/lib/dyld</b></p>
<p><b> symbol = gdb_image_notifier(dyld_image_mode, unsigned int, dyld_image_info const*)</b></p>
<p><b> address = 0x00007fff5fc0a2f2</b></p>
<p><b> resolved = true</b></p>
<p><b> hit count = 3 </b></p>
<p><b>, continuing.</b></p>
<p><b></b><br></p>
<p><b><lldb.process.internal-state(pid=84685)> Target::RemoveBreakpointByID (break_id = -9, internal = yes)</b></p>
<p><b></b><br></p>
<p><b><lldb.process.internal-state(pid=84685)> Target::DisableBreakpointByID (break_id = -9, internal = yes)</b></p>
<p><b></b><br></p>
<p><b>(int) $2 = 1049248</b></p>
<p><b>(lldb) </b></p><p></p><p><br></p><p>Could this be an ordering issue, where the event that is broadcast from hitting the breakpoint site is not caught by the handler that we want (in the dyld), but by the handler set up by the Evaluate() method (I don't know much about the event system, so I may be way off)?</p>
<div class="im">
<p><br></p><p>Thanks for the help,</p><p><br></p><p> Filipe</p><p></p><br></div><div><div></div><div class="h5"><div class="gmail_quote">On Wed, Aug 10, 2011 at 10:55, Jim Ingham <span dir="ltr"><<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So just a little terminology to make things clear. lldb has "breakpoints" which are the object you actually make when you do "break set". Then each breakpoint can have a number of "breakpoint locations" which are the places that the breakpoint specification resolved to in your program. Finally, there are "breakpoint sites" which are places that we actually insert trap instructions to implement the breakpoint locations. Note that you could have many breakpoint locations with the same address, so all those locations would share one site. Having the sites as a separate list is very convenient internally, since they can be stored in a nice address sorted list, and it makes the lookup from "stop address" to breakpoint efficient.<br>
<br>
Anyway, so the "breakpoint site 3" output you are seeing generally only happens when we hit a breakpoint site but by the time we get to reporting it we can't find the breakpoint location corresponding to that site (maybe the breakpoint got deleted in the process of stopping?)<br>
<br>
You can try turning on the lldb log for breakpoints to see what this breakpoint actually is:<br>
<br>
(lldb) log enable lldb breakpoint<br>
<br>
Note also, lldb sets some breakpoints for its own purposes (for instance breakpoints on the dyld load notification routine so we can find out when new shared libraries get loaded.) That particular breakpoint - which you would have hit while loading your dylib - is set to auto-continue without informing the upper layers of lldb that it had been hit. So that shouldn't have interrupted the load command. Of course something might be wrong that is defeating that...<br>
<font color="#888888"><br>
Jim<br>
</font><div><div></div><div><br>
On Aug 10, 2011, at 9:59 AM, Filipe Cabecinhas wrote:<br>
<br>
> The problem is that I only placed one breakpoint, how can I have a "breakpoint site 3"? Here's my interaction with lldb:<br>
><br>
> ➜ tests ±:(master) ! lldb ./a<br>
> Current executable set to './a' (x86_64).<br>
> (lldb) breakpoint set -n main<br>
> Breakpoint created: 1: name = 'main', locations = 1<br>
> (lldb) run<br>
> DynamicLoaderMacOSXDYLD::PrivateInitialize() process state = launching<br>
> DynamicLoaderMacOSXDYLD::SetNotificationBreakpoint() process state = launching<br>
> Process 81623 launched: '/Users/filipe/src/tests/a' (x86_64)<br>
> Process 81623 stopped<br>
> * thread #1: tid = 0x2d03, 0x0000000100000dd0 a`main + 32 at a.c:13, stop reason = breakpoint 1.1<br>
> frame #0: 0x0000000100000dd0 a`main + 32 at a.c:13<br>
> 10<br>
> 11 int main()<br>
> 12 {<br>
> -> 13 int i = ITERS, r = 0;<br>
> 14 clock_t start, end;<br>
> 15<br>
> 16 r = nyan(1);<br>
> (lldb) process load ~/src/tests/libmylib.dyld<br>
> error: failed to load '~/src/tests/libmylib.dyld': Execution was interrupted, reason: breakpoint site 3.<br>
> The process has been returned to the state before execution.<br>
> (lldb) breakpoint list --full<br>
> Current breakpoints:<br>
> 1: name = 'main', locations = 1, resolved = 1<br>
> 1.1: where = a`main + 32 at a.c:13, address = 0x0000000100000dd0, resolved, hit count = 1<br>
><br>
><br>
> Thanks for the help,<br>
><br>
> Filipe<br>
><br>
> On Tue, Aug 9, 2011 at 19:16, Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br>
> Internal breakpoints have negative IDs, so this hit one of your breakpoints, breakpoint 3.<br>
><br>
> Do a:<br>
><br>
> (lldb) breakpoint list --full<br>
><br>
> And see which breakpoint it is hitting.<br>
><br>
><br>
> On Aug 9, 2011, at 4:56 PM, Filipe Cabecinhas wrote:<br>
><br>
> > Hi,<br>
> ><br>
> > It seems I forgot to include the patches in this message, sorry about that. I'm sending them now, along with a patch to report errors when doing a "process load".<br>
> ><br>
> > I am also not able to do a "process load mylib.dylib", where mylib has this table (I'm trying to redefine printf):<br>
> > ➜ tests ±:(master) ! nm -m libmylib.dylib<br>
> > 00000f60 (__TEXT,__text) external _printf<br>
> > 00000fa0 (__TEXT,__text) non-external _strlen<br>
> > (undefined) external _write$UNIX2003 (from libSystem)<br>
> > (undefined) external dyld_stub_binder (from libSystem)<br>
> ><br>
> > I get the error:<br>
> > error: failed to load '~/src/tests/libmylib.dyld': Execution was interrupted, reason: breakpoint site 3.<br>
> > The process has been returned to the state before execution.<br>
> ><br>
> > The error is from ClangUserExpression->Evaluate(). I suppose that breakpoint site is internal (I only have placed one breakpoint site, in main()). How can I know what is going on?<br>
> ><br>
> > Regards,<br>
> ><br>
> > Filipe<br>
> ><br>
> > On Tue, Aug 2, 2011 at 11:07, Filipe Cabecinhas <<a href="mailto:filcab%2Blldb-dev@gmail.com" target="_blank">filcab+lldb-dev@gmail.com</a>> wrote:<br>
> > Hi,<br>
> ><br>
> > Here are two small fixed:<br>
> ><br>
> > - Fixed ifdeffed code that only compiles when debugging with the DEBUG_STACK_FRAMES flag.<br>
> > - Makes CommandObjectThreadStepWithTypeAndScope.Execute() behave like what was described in the mailing list: If there is no selected thread, select the first one (index 0).<br>
> ><br>
> > Regards,nbsp; Filipe<br>
> ><br>
> ><br>
> > <fix-ifdeffed-code-stackframelist.patch><get-first-thread-if-no-selected-thread.patch><ProcessLoadError.patch>_______________________________________________<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/mailman/listinfo/lldb-dev</a><br>
><br>
><br>
> _______________________________________________<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/mailman/listinfo/lldb-dev</a><br>
<br>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>