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, jing...@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 <christ...@fox21.at> wrote: >> >> 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
