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

[Christian Mayer]

So with the current version of LLDB the source-before-file is worthless
for debugging a shared library? So this is acctually not a bug?

Is there a workaround to debug a shared library with the current version
of LLDB? Setting all breakpoints manually for each start is too much
work. If you must set the breakpoints manually the source-before-file is
worthless in my eyes. And even if I don't restart the LLDB itself and
only the program I would like to debug the breakpoints are again
unresolved after re-start.


What do you mean with

> since it knows the world is going to change out from under it

? The addresses of a loaded library doesn't change from run to run.

Christian


On 22.01.15 00:29, jingham at apple.com wrote:
> I didn't notice you were stopping early in dyld_start.  lldb doesn't try to resolve any breakpoints that haven't currently been resolved that early on, since it knows the world is going to change out from under it, so for 99.999% of all breakpoints that work will be wasted.  If you set breakpoints that are going to take after the first shared library loads are completed (which is what the example I showed does) then they will take successfully.  Actually, your address breakpoint in dyld_start took as well, it just did so after the first set of shared library loads, i.e. after the code you wanted to break on was run.
> 
> Feel free to file a bug about this.  Maybe we can do something like: if you specify the shared library to be the dynamic loader (through the -s option) we'll set that breakpoint when we stop on exec.
> 
> Jim
> 
> 
> 
> 
>> On Jan 21, 2015, at 3:08 PM, Christian Mayer <christian at fox21.at> wrote:
>>
>> 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
>