On 21.01.15 19:45, jing...@apple.com wrote:
> When I add a breakpoint like this then before I run the program it is not
> resolved, but then when I run it does get resolved and hit. For instance:
>
> > cat /tmp/address-bkpt.lldb
> break set -a 0x00007fff9223f050
> > lldb Sketch.app/ -S /tmp/address-bkpt.lldb
> (lldb) command source -s 1 '/tmp/address-bkpt.lldb'
> (lldb) target create "Sketch.app"
> Current executable set to 'Sketch.app' (x86_64).
> (lldb) break list
> Current breakpoints:
> 1: address = 0x00007fff9223f050, locations = 1
> 1.1: address = 0x00007fff9223f050, unresolved, hit count = 0
>
> (lldb) run
> Process 62885 launched: 'Sketch.app/Contents/MacOS/Sketch' (x86_64)
> Process 62885 stopped
> * thread #1: tid = 0x2447b6, function: objc_retain , stop reason = breakpoint
> 1.1
> frame #0: 0x00007fff9223f050 libobjc.A.dylib`objc_retain
> -> 0x7fff9223f050 <objc_retain>: xorl %eax, %eax
> 0x7fff9223f052 <objc_retain+2>: testq %rdi, %rdi
> 0x7fff9223f055 <objc_retain+5>: je 0x7fff9223f060 ;
> objc_retain + 16
> 0x7fff9223f057 <objc_retain+7>: testb $0x1, %dil
>
> Address breakpoints are funny before you run, since libraries haven't gotten
> their correct load addresses, and in fact quite often there's either nothing
> actually in the address where they WILL load, or many things, because most
> libraries on OS X are zero based.
>
> So I wouldn't worry too much about what it says before you run. If it isn't
> hitting the breakpoint once you actually run, however, that would be worth
> look into.
It isn't hitting the breakpoint after I "run". When the program is
running and I'm at the address of the breakpoint the breakpoint is still
marked as "unresolved". I wouldn't have asked if it would work correctly.
As you can see below I manually went to the address of the breakpoint
after "process launch --stop-at-entry" and the breakpoint is still not
resolved.
[lldb]> ni
Process 5666 stopped
* thread #1: tid = 0x45407, 0x00007fff5fc01031 dyld`_dyld_start + 49,
stop reason = instruction step over
frame #0: 0x00007fff5fc01031 dyld`_dyld_start + 49
-> 0x7fff5fc01031 <_dyld_start+49>: callq 0x7fff5fc01076 ;
dyldbootstrap::start(macho_header const*, int, char const**, long,
macho_header const*, unsigned long*)
0x7fff5fc01036 <_dyld_start+54>: movq -0x8(%rbp), %rdi
0x7fff5fc0103a <_dyld_start+58>: cmpq $0x0, %rdi
0x7fff5fc0103e <_dyld_start+62>: jne 0x7fff5fc01050 ;
_dyld_start + 80
[lldb]> br li
Current breakpoints:
1: address = 0x00007fff5fc01031, locations = 1
1.1: address = 0x00007fff5fc01031, unresolved, hit count = 0
After I stepped over the breakpoint it looks like this:
[lldb]> ni
Process 5666 stopped
* thread #1: tid = 0x45407, 0x00007fff5fc01036 dyld`_dyld_start + 54,
queue = 'com.apple.main-thread', stop reason = instruction step over
frame #0: 0x00007fff5fc01036 dyld`_dyld_start + 54
-> 0x7fff5fc01036 <_dyld_start+54>: movq -0x8(%rbp), %rdi
0x7fff5fc0103a <_dyld_start+58>: cmpq $0x0, %rdi
0x7fff5fc0103e <_dyld_start+62>: jne 0x7fff5fc01050 ;
_dyld_start + 80
0x7fff5fc01040 <_dyld_start+64>: movq %rbp, %rsp
[lldb]> br li
Current breakpoints:
1: address = 0x00007fff5fc01031, locations = 1, resolved = 1, hit count = 0
1.1: address = 0x00007fff5fc01031, resolved, hit count = 0
And I tried the same procedure as you with only one line in my txt file
and after I hit "run" on a simple "hello world" C program the program
exited with status 0 without hitting the breakpoint at 0x7fff5fc01031.
Christian
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
