LLDB Python/C++ binding set Breakpoint at (PIC) Addr

Question

I am trying set a breakpoint at an address that I got by object-dumping my binary. So my main starts at 0x0000000100000f10 <_main>:

By using the example here and replacing

main_bp = target.BreakpointCreateByName ("main", target.GetExecutable().GetFilename())

with

main_bp = target.BreakpointCreateByAddress(0x0000000100000f10)

I get process.state = 10 (== lldb.eStateExited) after I launched the target, so it did not hit my breakpoint. I assume this is because the binary isn't actually at this location (PIC).

By using lldb directly

$ lldb a.out
(lldb) b *0x0000000100000f10
(lldb) r

It stops at the right position. So how do I reproduce the behaviour of the 'real' lldb with the python bindings?

lldb version: lldb-340.4.110 (lldb provided by Xcode)
OS: Mac (Yosemite)
Python 2.7.10

Answer 1

Looks like LaunchSimple doesn't set the "lldb.eLaunchFlagDisableASLR" flag in the SBLaunchInfo options. You can test this by also setting the symbolic "main" breakpoint. I did hit that breakpoint, but when I checked the address of the breakpoint it was NOT the address of the main symbol as recorded in the binary. That is because the binary slid at launch (that's what ASLR does.)

That seems like a bug to me since the default LaunchInfo options DO disable ASLR, please file it with the bugzilla at lldb.llvm.org.

If I use the more complete launch API:

launch_info = lldb.SBLaunchInfo(None)
launch_info.SetExecutableFile (lldb.SBFileSpec(exe), True)

error = lldb.SBError()
process = target.Launch (launch_info, error)

Then - at least for me - the binary does not slide, and I hit the by address breakpoint I set on the address of the main symbol.

Note, setting breakpoints by the pre-load address will only work for the main executable. Most libraries are built zero-based, and so they have to slide or they would load on top of one another. With ASLR off, the libraries will end up at the same address run-to-run, but they will slide by some amount.

Jonas also asked how to resolve the address in the running program by hand, which you can do as follows.

First, terminology: the lldb terms for the "before running" and "while running" addresses for the same location in a binary is "file" and "load" address respectively. Also lldb calls all the loadable binaries in your program "modules"...

So if you have a numerical (lldb::addr_t) file address which you want to resolve in a module from somewhere, you do that in two steps. First turn the file address into an SBAddress using the SBModule::ResolveFileAddress API. You can find the module using SBTarget::FindModule . Then, once the program is running and has loaded the module you are interested in, you can use the SBAddress::GetLoadAddress to get the load address, and use that to set the breakpoint.

The only bad part of this is that you won't be able to get the load address till the program is running (obviously) so you'll have to have another way to stop the program before you hit the address you want to break on. Usually you can do something like put a breakpoint on main and then do this work. Of course, if you wanted to resolve the address of main this way you're out of luck. But presumably you have something more interesting than main in view...

This should be easier, since there should be an API to set a by-address breakpoint using the SBAddress you got above. Then lldb could do the job of resolving it for you when its underlying module gets loaded. I've already got a bug for that, just haven't gotten to it yet. Mostly folks set breakpoints on symbols or source locations, so the by address breakpoints haven't gotten as much attention.