> On Jan 21, 2015, at 5:06 PM, Christian Mayer <christ...@fox21.at> wrote: > > 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?
Two things here. First of all, up till very recently lldb didn't support setting breakpoints before you have a target. That was a known bug, which I fixed a short while ago (but there hasn't been a new release of the tools from Apple since that fix went in.) Sorry I didn't mention that, I assumed from the fact that you were building TOT lldb to test this that you knew that. That this didn't work up till now was clearly a bug, that's why I fixed it. With TOT lldb, however this does work, as I showed in the example I sent. You sent another example, for which thanks, BTW. I explained that the reason that example didn't work was you were trying to set a breakpoint in code that ran before ANY shared libraries are mapped into the program. So while your example showed a small set of code for which "source-before-file" breakpoints don't work, that code is not in shared libraries, it is in the loader, and at such an early stage that nothing of any importance has happened in the program yet. AND I said that was a bug, please file it. So this comment seems totally off base. > > 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. "unresolved" means that though lldb knows what address the breakpoint should be at, it wasn't able to put the breakpoint there yet. After a restart, all breakpoints are expected to be unresolved - since the libraries in question haven't been mapped into the address space of the program, and will remain so till the relevant library gets mapped in. > > > 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. That's actually not true. If ASLR is on, then libraries load in different orders from run to run. And even if you turn ASLR off - which the debugger does by default - though all the directly loaded shared libraries will end up in the same place from run to run, the addresses of any libraries that are loaded later on as a result of user actions (e.g. hit Print in some OS X application and a bunch of shared libraries will get loaded) depend on the order of those actions. Anyway, that's interesting maybe, but not really the point. At the beginning of _dyld_start, none of the shared libraries are mapped into the address space of the program. Since we need to write traps into the breakpoint memory locations in order to set breakpoints, we're going to fail until dyld gets a chance to map them in. The only thing that's been mapped in is the loader itself. Jim > > 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
