[lldb-dev] Breakpoints from source-before-file are not working

Christian Mayer christian at fox21.at
Wed Jan 21 15:08:06 PST 2015


On 21.01.15 19:45, jingham at 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



More information about the lldb-dev mailing list