I want some commands to be automatically executed each time the program stops, just like what display does with x. How do I do that?
Here's the easy way I found out:
define hook-stop
...commands to be executed when execution stops
end
Refer to this page for details: http://sourceware.org/gdb/current/onlinedocs/gdb/Hooks.html#Hooks
Another "new" way to do it is with the Python Event interface:
def stop_handler (event):
print "event type: stop"
gdb.events.stop.connect (stop_handler)
which will trigger the stop_handler function each the the inferior stops.
There are two other similar events type:
events.cont
events.exited
respectively triggered when the inferior is continued or exists.
Related
I know how to create/modify a breakpoint to stop only on a specific thread using breakpoint modify <breakpoint-id> -T <thread-name>, but can I do it the other way around, preventing the breakpoint to stop on a specific thread?
I have a log thread that use the same function I'm trying to debug on other threads and it's annoying to have to let it continue every time it hits.
You can do this sort of thing using the lldb Python API and Python breakpoint callbacks. The callback returns a "should stop" value, i.e. if it returns True, you stop at the breakpoint, and False you continue.
So for instance:
(lldb) breakpoint command add -s python -o 'return frame.thread.name != "MyThread"'
is what you wanted. Note, in this example, I didn't provide a breakpoint ID. In lldb that means "act on the last set breakpoint". But you can also supply the breakpoint ID if the one you want to add the command to doesn't happen to be the last breakpoint you set. And if you want to add it to multiple breakpoints, you can specify a breakpoint ID list.
There's more on the API's and the callback format here:
https://lldb.llvm.org/python_api.html
https://lldb.llvm.org/use/python-reference.html#running-a-python-script-when-a-breakpoint-gets-hit
Note, however, that breakpoints with should-stop callbacks will force a stop every time the breakpoint is hit. lldb auto-continues pretty quickly, so for many applications this isn't a problem. But just getting from the stop over to the debugger and back is not cheap, so if your breakpoint is in a work loop and getting hit hundreds of thousands of times a second, this is going to slow down the run. If that ends up being a problem and you control your source code, tricks like the one Eljay suggested in the comments can be really handy.
Is there a way to attach a print statement to the call of a function? I would like to debug a x64 program with nested loops and logic and it would be faster to see the sequence of function calls by printing them as they occur, rather than setting breakpoints.
Can this be done with a post hook in gdb or a different technique?
Is there a way to attach a print statement to the call of a function?
Yes: attach a breakpoint to every function you want to trace, and attach commands to each of these breakpoints:
(gdb) break foo
(gdb) commands $bpnum
continue
end
Now every time foo is called, GDB will print the usual "Breakpoint N ..." message, and then continue.
Obviously you could print additional info (argument values, call stack, thread-id, etc.).
You will probably want to set height 0 to disable pagination. You will also probably want to log this to a file (see set logging file, set logging on, etc.)
Is there a way to execute a script every time the program stops?
I need to do something like this:
Var.Set \myvar=list[Id]
where list and Id are variables from the program.
However when the Id changes \myvar doesn't change, it remains with the value which corresponds to the old Id.
This is why I want to run a script that does that command every time a program stops from running.
To run a script every time the program stops use the command ON or GLOBALON. ON is suitable when there is still an active PRACTICE script controlling your test case. GLOBALON is suitable if you want a reaction on an event until you disable it again.
General syntax is:
ON|GLOBALON <event> <action>
where "event" can be PBREAK for "program-break" and "action" can be "DO <script.cmm>" to execute an individual script on the event.
Putting all together you get:
GLOBALON PBREAK DO syncmyvar.cmm
where script syncmyvar.cmm contains your command Var.Set \myvar=list[Id]
To disable the event handler on a program break use
GLOBALON PBREAK inherit
If I understand your use case correctly, you'd like to execute the command Var.Set \myvar=list[Id] every time Id changes. In this case I would consider to use a write-breakpoint with a command action. E.g. like this:
Var.Break.Set Id /Write /CMD "Var.Set \myvar=list[Id]" /RESUME
However this gives a quite different behavior: With this breakpoint, you application gets stopped shortly for every write access to Id and \myvar is always in sync with Id, while with GLOBALON PBREAK DO syncmyvar.cmm the variable \myvar gets only updated when the application completely stops.
I'm currently in the process of building a small shell within C++.
A user may enter a job at the prompt such as exe1 && exe2 &. Similar to the BASH shell, I will only execute exe2 if exe1 exits successfully. In addition, the entire job must be performed in the background (as specified by the trailing & operator).
Right now, I have a jobManager which handles execution of jobs and a job structure which contains the job's executable and their individual arguments / conditions. A job is started by calling fork() and then calling execvp() with the proper arguments. When a job ends, I have a signal handler for SIGCHLD, in which I perform wait() to determine which process has just ended. When exe1 ends, I observe its exit code and make a determination as to whether I should proceed to launch exe2.
My concern is how do I launch exe2. I am concerned that if I use my jobManager start function from the context of my SIGCHLD handler, I could end up with too many SIGCHLD handler functions hanging out on the stack (if there were 10 conditional executions, for instance). In addition, it just doesn't seem like a good idea to be starting the next execution from the signal handler, even if it is occurring indirectly. (I tried doing something similar 1.5 years ago when I was just learning about signal handling -- I seem to recall it failing on me).
All of the above needs to be able to occur in the background and I want to avoid having the jobManager sitting in a busy wait just waiting for exe1 to return. I would also prefer to not have a separate thread sitting around just waiting to start the execution of another process. However, instructing my jobManager to begin execution of the next process from the SIGCHLD handler seems like poor code.
Any feedback is appriciated.
I see two ways:
1)Replace you sighandler with loop that call "sigwait" (see man 3 sigwait)
then in loop
2)before start create pipe, and in mainloop of your program use "select" on pipe handle to wait
events. In signal handler write to pipe, and in mainloop handle situation.
Hmmm that's a good one.
What about forking twice, once per process? The first one runs, and the second one stops. In the parent SIGCHLD handler, send a SIGCONT to the second child, if appropriate, which then goes off and runs the job. Naturally, you SIGKILL the second one if the first one shouldn't run, which should be safe because you won't really have set anything up.
How does that sound? You'll have a process sitting around doing nothing, but it shouldn't be for very long.
I am using GDB to understand a C++ program. I put a break in the middle of the running which turns to be something like:
break main.cpp:500
and I would like to see which functions have been called before. I tried "backtrace" but it shows only info about main, as previous calls to previous functions have already finished.
My question is how can I get (with GDB or another method) the info about which functions have been called before this point, even if the call has been returned.
Thanks
A gdb script might be a solution for your problem.
Create a script that puts break point to each possibly called function.
At break prints the stack with 'bt' and continue the execution.
You should put an other break point to main.cpp:500 to quit from debugging.
b 'main.cpp::500'
commands 1
detach
quit
end
break 'A::f1()'
break 'A::f2()'
while true
continue
bt
end
You can start the script like this:
gdb --command ./gdbscript.gdb fpmanager
If you have too much possibly called function you can grep the code to find all.