[lldb-dev] Small fixes
Filipe Cabecinhas
filcab+lldb-dev at gmail.com
Wed Aug 10 15:52:19 PDT 2011
On that note, is there a reason for not resolving FileSpecs in the
ProcessLoad command?
line 1174 of CommandProcess.cpp:
FileSpec image_spec (image_path, false);
It seems to me that we would want to resolve the FileSpec and accept any
path starting with ~/, by changing the second parameter to true.
Regards,
Filipe
On Wed, Aug 10, 2011 at 14:47, Filipe Cabecinhas
<filcab+lldb-dev at gmail.com>wrote:
> Hi,
>
> 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.
>
> 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):
>
> (lldb) expr (void*)dlopen("/Users/filipe/src/tests/libmylib.d", 1)
> error: Execution was interrupted, reason: breakpoint site 10.
> The process has been returned to the state before execution.
> (lldb) process load ~/src/tests/libmylib.dyliasdasd
> error: failed to load '~/src/tests/libmylib.dyliasdasd': Execution was
> interrupted, reason: breakpoint site 12.
> The process has been returned to the state before execution.
> (lldb)
>
>
> Thanks for the help,
>
> Filipe
>
>
> On Wed, Aug 10, 2011 at 13:36, Filipe Cabecinhas <
> filcab+lldb-dev at gmail.com> wrote:
>
>> 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):
>>
>> Process 84650 resuming
>>
>> *<lldb.driver.main-thread> Target::CreateBreakpoint (internal = yes) =>
>> break_id = -8: address = 0x0000000100000d70*
>>
>> **
>>
>> **
>>
>> *<lldb.driver.main-thread> Target::RemoveBreakpointByID (break_id = -4,
>> internal = yes)*
>>
>> **
>>
>> *<lldb.driver.main-thread> Target::DisableBreakpointByID (break_id = -4,
>> internal = yes)*
>>
>> **
>>
>> *error: failed to load '~/src/tests/libmylib.dyld': Execution was
>> interrupted, reason: breakpoint site 8.*
>>
>> *The process has been returned to the state before execution.*
>>
>> *(lldb) *
>>
>> *
>> *
>>
>> 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):
>>
>> *
>> *
>>
>> *(lldb) expr (int)dlopen("/Users/filipe/src/tests/libmylib.dylib", 1)*
>>
>> **
>>
>> *<lldb.driver.main-thread> Target::CreateBreakpoint (internal = yes) =>
>> break_id = -9: address = 0x0000000100000d70*
>>
>> **
>>
>> **
>>
>> *<lldb.driver.main-thread> Target::RemoveBreakpointByID (break_id = -8,
>> internal = yes)*
>>
>> **
>>
>> *<lldb.driver.main-thread> Target::DisableBreakpointByID (break_id = -8,
>> internal = yes)*
>>
>> **
>>
>> *<lldb.process.internal-state(pid=84685)> Hit breakpoint location: -1.1:
>> *
>>
>> * module = /usr/lib/dyld*
>>
>> * symbol = gdb_image_notifier(dyld_image_mode, unsigned int,
>> dyld_image_info const*)*
>>
>> * address = 0x00007fff5fc0a2f2*
>>
>> * resolved = true*
>>
>> * hit count = 3 *
>>
>> *, continuing.*
>>
>> **
>>
>> *<lldb.process.internal-state(pid=84685)> Target::RemoveBreakpointByID
>> (break_id = -9, internal = yes)*
>>
>> **
>>
>> *<lldb.process.internal-state(pid=84685)> Target::DisableBreakpointByID
>> (break_id = -9, internal = yes)*
>>
>> **
>>
>> *(int) $2 = 1049248*
>>
>> *(lldb) *
>>
>>
>> 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)?
>>
>>
>> Thanks for the help,
>>
>>
>> Filipe
>>
>>
>> On Wed, Aug 10, 2011 at 10:55, Jim Ingham <jingham at apple.com> wrote:
>>
>>> 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.
>>>
>>> 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?)
>>>
>>> You can try turning on the lldb log for breakpoints to see what this
>>> breakpoint actually is:
>>>
>>> (lldb) log enable lldb breakpoint
>>>
>>> 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...
>>>
>>> Jim
>>>
>>> On Aug 10, 2011, at 9:59 AM, Filipe Cabecinhas wrote:
>>>
>>> > The problem is that I only placed one breakpoint, how can I have a
>>> "breakpoint site 3"? Here's my interaction with lldb:
>>> >
>>> > ➜ tests ±:(master) ! lldb ./a
>>> > Current executable set to './a' (x86_64).
>>> > (lldb) breakpoint set -n main
>>> > Breakpoint created: 1: name = 'main', locations = 1
>>> > (lldb) run
>>> > DynamicLoaderMacOSXDYLD::PrivateInitialize() process state = launching
>>> > DynamicLoaderMacOSXDYLD::SetNotificationBreakpoint() process state =
>>> launching
>>> > Process 81623 launched: '/Users/filipe/src/tests/a' (x86_64)
>>> > Process 81623 stopped
>>> > * thread #1: tid = 0x2d03, 0x0000000100000dd0 a`main + 32 at a.c:13,
>>> stop reason = breakpoint 1.1
>>> > frame #0: 0x0000000100000dd0 a`main + 32 at a.c:13
>>> > 10
>>> > 11 int main()
>>> > 12 {
>>> > -> 13 int i = ITERS, r = 0;
>>> > 14 clock_t start, end;
>>> > 15
>>> > 16 r = nyan(1);
>>> > (lldb) process load ~/src/tests/libmylib.dyld
>>> > error: failed to load '~/src/tests/libmylib.dyld': Execution was
>>> interrupted, reason: breakpoint site 3.
>>> > The process has been returned to the state before execution.
>>> > (lldb) breakpoint list --full
>>> > Current breakpoints:
>>> > 1: name = 'main', locations = 1, resolved = 1
>>> > 1.1: where = a`main + 32 at a.c:13, address = 0x0000000100000dd0,
>>> resolved, hit count = 1
>>> >
>>> >
>>> > Thanks for the help,
>>> >
>>> > Filipe
>>> >
>>> > On Tue, Aug 9, 2011 at 19:16, Greg Clayton <gclayton at apple.com> wrote:
>>> > Internal breakpoints have negative IDs, so this hit one of your
>>> breakpoints, breakpoint 3.
>>> >
>>> > Do a:
>>> >
>>> > (lldb) breakpoint list --full
>>> >
>>> > And see which breakpoint it is hitting.
>>> >
>>> >
>>> > On Aug 9, 2011, at 4:56 PM, Filipe Cabecinhas wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > 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".
>>> > >
>>> > > I am also not able to do a "process load mylib.dylib", where mylib
>>> has this table (I'm trying to redefine printf):
>>> > > ➜ tests ±:(master) ! nm -m libmylib.dylib
>>> > > 00000f60 (__TEXT,__text) external _printf
>>> > > 00000fa0 (__TEXT,__text) non-external _strlen
>>> > > (undefined) external _write$UNIX2003 (from libSystem)
>>> > > (undefined) external dyld_stub_binder (from libSystem)
>>> > >
>>> > > I get the error:
>>> > > error: failed to load '~/src/tests/libmylib.dyld': Execution was
>>> interrupted, reason: breakpoint site 3.
>>> > > The process has been returned to the state before execution.
>>> > >
>>> > > 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?
>>> > >
>>> > > Regards,
>>> > >
>>> > > Filipe
>>> > >
>>> > > On Tue, Aug 2, 2011 at 11:07, Filipe Cabecinhas <
>>> filcab+lldb-dev at gmail.com> wrote:
>>> > > Hi,
>>> > >
>>> > > Here are two small fixed:
>>> > >
>>> > > - Fixed ifdeffed code that only compiles when debugging with the
>>> DEBUG_STACK_FRAMES flag.
>>> > > - Makes CommandObjectThreadStepWithTypeAndScope.Execute() behave
>>> like what was described in the mailing list: If there is no selected thread,
>>> select the first one (index 0).
>>> > >
>>> > > Regards,nbsp; Filipe
>>> > >
>>> > >
>>> > >
>>> <fix-ifdeffed-code-stackframelist.patch><get-first-thread-if-no-selected-thread.patch><ProcessLoadError.patch>_______________________________________________
>>> > > lldb-dev mailing list
>>> > > lldb-dev at cs.uiuc.edu
>>> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>> >
>>> >
>>> > _______________________________________________
>>> > 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/20110810/da1e2c7f/attachment.html>
More information about the lldb-dev
mailing list