Process Handle in Lldbinit

process handle in lldbinit

One workaround for this is to take the set of commands you want to run in lldb after the file you are debugging is loaded, put them in a file, and run:

$ lldb -s <command file> <FileToBeDebugged>

Then if you like this and use it often, you can make a shell alias of part up to .

If you are using Xcode, a common trick is to set a breakpoint at main in your project, put the commands you want to run there, and then make it "auto-continue".

how to get current debugging process's info in __lldb_init_module?

In command-line lldb there are two stages of reading in init files.

The ~/.lldbinit is read in the first phase, before any targets get made. That way commands in it can condition the construction of the targets. So modules sourced there won't see any targets.

Then if there is a .lldbinit in the CWD, that will get sourced after any targets specified on the command line. So that will see the target.

The equivalent in Xcode (if you are using a fairly recent Xcode) is the lldbinit you can specify in the run scheme's options tab.

The other way to do this is to set an auto-continue breakpoint on main, and source your .lldbinit at that point. Note, if you want to use process handle there has to be a running process, so you need to do that in a breakpoint somewhere...

Permanently configuring LLDB (in Xcode 4.3.2) not to stop on signals

In case anyone else ever has this question, I finally solved it by adding a breakpoint in NSApplicationMain() (for plain C programs, main() would of course work as well).

I set the breakpoint action to process handle SIGUSR2 -n true -p true -s false, and enabled the "Automatically continue after evaluating" option.

If anyone has a more elegant solution, I'd be happy to hear.

How to tell LLDB debugger not to handle SIGBUS?

You can control how lldb intercepts/passes signals with the "process handle" command. For your case, you'd want to do

(lldb) pro hand -p true -s false SIGBUS
NAME        PASS   STOP   NOTIFY
==========  =====  =====  ======
SIGBUS      true   false  true 

now the signals will be passed to your process without lldb getting in the way. The "NOTIFY" field indicates whether lldb should print that the signal was received - the default is that it will be printed in the debugger console but that doesn't seem to be happening right now. But the signal is correctly passed along, which is the important bit.

How do you create a LLDB script to ignore SIGSEGV and SIGBUS

The way "process handle" works, you have to have a running process to attach the signal behaviors to; it doesn't adhere to the target. So you will need to do this once you have a process. The easiest way to do that is to set a breakpoint on main in your .lldbinit file, and add the commands to that breakpoint:

break set -n main -C "process handle..." -C "process handle..."

Breakpoints set in the .lldbinit file get inherited by all lldb debugging sessions. If you only want this to apply to your matlab debugging sessions, you could make a Python command that checks the name of your target executable and only does the process handle if it is matlab, and then runs the process handle commands. You could then call that Python command from the breakpoint as shown above.

LLDB Breakpoint Commands and Finish

You can't do this at present. The lldb command interpreter isn't re-entrant and since your finish could very well hit another breakpoint with its own commands lldb exits reading the first set of breakpoint commands when one of them continues.

You don't need to delete the return breakpoint in its commands, just make it a one shot breakpoint (break set -o true) and when it gets hit, it will just delete itself.

Note, if your program is multithreaded and you are stopping in code many threads are likely to pass through concurrently, you really need to make your return breakpoint thread-specific for the current thread. That's actually a little tricky to do in lldb command-line, but you can do it pretty easily using Python breakpoint callbacks:

https://lldb.llvm.org/use/python-reference.html#running-a-python-script-when-a-breakpoint-gets-hit

Project specific .lldbinit in current working directory not read by Xcode

There is now a "Xcode plugin to load project specific .lldbinit" at https://github.com/alloy/lldb-is-it-not

How to tell LLDB to pass signal onto program

Ah, then I don't think the problem was with breakpoints, but with whether your signal handler was actually getting called.

Most debuggers have some way to control what happens when a signal is received. In lldb this is done through the process handle command. For instance:

(lldb) process handle SIGSTOP
NAME         PASS   STOP   NOTIFY
===========  =====  =====  ======
SIGSTOP      false  true   true 

That means lldb will stop when your process is given a SIGSTOP, and will notify you about the SIGSTOP, but will NOT pass the SIGSTOP on to the program you are debugging (and thus your handler will not get called for SIGSTOP.) process handle with no arguments will give you the list of behaviors for all signals.

We don't pass SIGSTOP by default because it is used by the debugger for its own purposes, and so you might get calls to your handler that didn't come from "real" SIGSTOP's. The same is true, for the same reason, of SIGINT:

(lldb) process handle SIGINT
NAME         PASS   STOP   NOTIFY
===========  =====  =====  ======
SIGINT       false  true   true 

You can easily change this behavior, for instance for SIGINT:

(lldb) process handle SIGINT -p true
NAME         PASS   STOP   NOTIFY
===========  =====  =====  ======
SIGINT       true   true   true 

Then the debugger will pass the SIGINT on to the process, and it will stop in your handler.

Disable signals at LLDB initialization

At present the suggestion of doing this in a breakpoint command on main is the most elegant solution available.

gdb had this view of the world where all processes, no matter what system they might be on, magically responded to UNIX signals. So it made sense to say what was going to happen when the process got a SIGINT, say, before you even had a process. In lldb, the process, when it gets created, will tell us what its signals are and their default behaviors. That's lovely, except it means now there is no natural place to store configuration options for signal behaviors before you have a process. This is just something that has to get added.

The ability to trigger off of "process life-cycle events", not just "process launch" but "process exit" and "shared library load" etc would be a great addition. This feature is something it would be great to file an enhancement request (http://bugreport.apple.com/) for, since bugs like that act as votes for features.

BTW, target.process.extra-startup-command does something entirely different. It allows you to prepend some commands to the sequence lldb sends to its debug agent (e.g. debugserver) before we start running. Its main use is to turn on more debugserver logging.

---

Related Topics