Add a post on gdb scripting
This commit is contained in:
parent
c941fe6ac5
commit
601c65e809
2 changed files with 258 additions and 0 deletions
BIN
images/roundedcorners.jpg
Normal file
BIN
images/roundedcorners.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 120 KiB |
258
posts/2021-11-13-gdb-scripting.md
Normal file
258
posts/2021-11-13-gdb-scripting.md
Normal file
|
|
@ -0,0 +1,258 @@
|
|||
---
|
||||
author: Sanchayan Maity
|
||||
title: Automate debugging using GDB scripting
|
||||
tags: linux, gdb, gdb scripting, gstreamer
|
||||
---
|
||||
|
||||
Recently I was working on a GStreamer
|
||||
[plugin](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/572)
|
||||
in Rust. The plugin basically rounds the corners of an incoming video,
|
||||
something akin to the `border-radius` property in CSS. Below is how it looks
|
||||
like when running on a video.
|
||||
|
||||
|
||||
|
||||
The GStreamer pipeline for the same.
|
||||
|
||||
```bash
|
||||
gst-launch-1.0 filesrc location=~/Downloads/bunny.mp4 ! decodebin ! videoconvert ! video/x-raw,format=I420 ! roundedcorners border-radius-px=100 ! video/x-raw,format=A420 ! videoconvert ! gtksink
|
||||
```
|
||||
|
||||
This was my first time working on a video plugin in GStreamer. Had a lot to
|
||||
learn on how to use the `BaseTransform` class from GStreamer, among other
|
||||
things. Without getting into the GStreamer specific details here, I basically
|
||||
ran into a problem for which I needed to do some debugging for figuring out
|
||||
what was going on in the internals of GStreamer.
|
||||
|
||||
Now, while I never had problems using GDB from the command line, but, the way I
|
||||
was using it earlier was just not good enough. I would start the pipeline, then
|
||||
attach gdb to a running process, place breakpoints by manually typing out the
|
||||
whole thing and then start. For one off debugging sessions, where may be you
|
||||
just want to quickly inspect the backtrace from a crash or may be look into a
|
||||
deadlock condition where your code hanged, this could be fine. However, when
|
||||
you have to repeat this multiple times, do a source code change, compile and
|
||||
then check again, it becomes frustrating.
|
||||
|
||||
## GDB Dashboard
|
||||
|
||||
Looking for a better way, I first stumbled on
|
||||
[gdb-dashboard](https://github.com/cyrus-and/gdb-dashboard).
|
||||
This is quite useful since it can give the needed information without having to
|
||||
type anything. Using gdb
|
||||
[hooks](https://git.sr.ht/~sanchayanmaity/dotfiles/tree/master/item/gdb/.gdbinit.d/hooks),
|
||||
the dashboard can be triggered when appropriate. See the rest of my
|
||||
[gdb configuration](https://git.sr.ht/~sanchayanmaity/dotfiles/tree/master/item/gdb/.gdbinit.d)
|
||||
to get an idea. I use this in scenarios like where code is stuck due to a
|
||||
deadlock, I need to look at the backtrace of a crash or any such one off simple
|
||||
investigation.
|
||||
|
||||
## Construct breakpoint command in neovim & copy to clipboard
|
||||
|
||||
The next small improvement I did was more specific to my use of neovim. Am
|
||||
generally navigating source code using neovim, which would be opened in one
|
||||
kitty tab and gdb would be running in terminal in next tab or a split. Wanted
|
||||
to be able to quickly place a breakpoint without having to type anything out on
|
||||
the gdb prompt. Wrote a small piece of vimscript code which generates the gdb
|
||||
command, I would have to type on the gdb prompt to enable a breakpoint,
|
||||
considering the current line and file on which my cursor is at in the source
|
||||
when opened in neovim.
|
||||
|
||||
```vimscript
|
||||
function! CopyBpLocToClipboard() abort
|
||||
let linenumber = line(".")
|
||||
let filepath = expand("%")
|
||||
let breakpoint = "break " . filepath . ":" . linenumber
|
||||
silent execute "!wl-copy " . breakpoint
|
||||
endfunction
|
||||
|
||||
nnoremap <silent> <Leader>yb :<C-U>call CopyBpLocToClipboard()<CR>
|
||||
```
|
||||
|
||||
So I can hit the key binding above and a command like below will be copied to
|
||||
the clipboard which I can paste on gdb prompt.
|
||||
|
||||
```bash
|
||||
break subprojects/gst-plugins-base/gst-libs/gst/video/video-frame.c:104
|
||||
```
|
||||
|
||||
Nifty!!!
|
||||
|
||||
## GDB scripting
|
||||
|
||||
Now imagine a scenario where may be one wants to look at multiple places in the
|
||||
source code and when the program is running, inspect certain variables or just
|
||||
print out a back trace each time a specific code point is reached.
|
||||
|
||||
The dumb way to do this and the way which I was also doing it earlier, was to
|
||||
load the executable in gdb or attach to a running process, place a break point,
|
||||
run, inspect the local variables or print stack trace, place the next break
|
||||
point and repeat this whole process. Just time consuming and a waste of time.
|
||||
|
||||
GDB can completely automate the above process. Let's see how.
|
||||
|
||||
Below is the `.gdbinit` file I came up with for my problem. This is what is
|
||||
called a command file by gdb.
|
||||
|
||||
```bash
|
||||
set confirm off
|
||||
set breakpoint pending on
|
||||
set logging on
|
||||
set logging overwrite on
|
||||
set print pretty on
|
||||
set pagination off
|
||||
break subprojects/gst-plugins-base/gst-libs/gst/video/video-frame.c:104 if meta->n_planes == 4
|
||||
break subprojects/gst-plugins-base/gst-libs/gst/video/gstvideometa.c:228
|
||||
break subprojects/gstreamer/gst/gstbuffer.c:1410
|
||||
break subprojects/gst-plugins-base/gst-libs/gst/video/gstvideometa.c:231
|
||||
break subprojects/gst-plugins-base/gst-libs/gst/video/gstvideometa.c:237
|
||||
break subprojects/gst-plugins-base/gst-libs/gst/video/video-frame.c:136
|
||||
|
||||
commands 1
|
||||
print i
|
||||
print *frame
|
||||
enable 2
|
||||
enable 3
|
||||
enable 4
|
||||
enable 5
|
||||
enable 6
|
||||
continue
|
||||
end
|
||||
commands 2
|
||||
print offset
|
||||
continue
|
||||
end
|
||||
commands 3
|
||||
print offset
|
||||
print size
|
||||
continue
|
||||
end
|
||||
commands 4
|
||||
print *(GstBufferImpl *)buffer
|
||||
print idx
|
||||
print length
|
||||
print skip
|
||||
continue
|
||||
end
|
||||
commands 5
|
||||
disable 2
|
||||
disable 3
|
||||
disable 4
|
||||
print *(GstBufferImpl *)buffer
|
||||
print info->data
|
||||
print skip
|
||||
print *data
|
||||
continue
|
||||
end
|
||||
commands 6
|
||||
print *frame
|
||||
quit
|
||||
end
|
||||
|
||||
disable 2
|
||||
disable 3
|
||||
disable 4
|
||||
disable 5
|
||||
disable 6
|
||||
run
|
||||
```
|
||||
|
||||
The command I was using to debug my GStreamer plugin in this pipeline with gdb.
|
||||
|
||||
```bash
|
||||
gdb --nx -x .gdbinit --args env RUST_BACKTRACE=1 GST_DEBUG=3,basetransform:6 GST_PLUGIN_PATH=$GST_PLUGIN_PATH:~/GitSources/gst-plugins-rs/target/debug gst-launch-1.0 filesrc location=~/Downloads/bunny.mp4 ! decodebin ! videoconvert ! video/x-raw,format=I420 ! roundedcorners border-radius-px=100 ! video/x-raw,format=A420 ! videoconvert ! gtksink
|
||||
```
|
||||
|
||||
In the command above, the `-x` parameter tells gdb to use the command file. The
|
||||
`--nx` flag tells gdb to not read any any `.gdbinit` files in any directory, as
|
||||
I did not want to use `gdb-dashboard` for this. `--args` is how I tell gdb what
|
||||
to run, which is my GStreamer pipeline. You can see `gdb --help` for details on
|
||||
the flags.
|
||||
|
||||
Now, let's understand what the command file does. The ones below are just some
|
||||
settings we want gdb to use. Note that we have turned on logging and pretty
|
||||
printing.
|
||||
|
||||
```bash
|
||||
set confirm off
|
||||
set breakpoint pending on
|
||||
set logging on
|
||||
set logging overwrite on
|
||||
set print pretty on
|
||||
set pagination off
|
||||
```
|
||||
|
||||
Next we specify the breakpoints. We have six breakpoints. These are the
|
||||
locations which were of interest to me.
|
||||
|
||||
```bash
|
||||
break subprojects/gst-plugins-base/gst-libs/gst/video/video-frame.c:104 if meta->n_planes == 4
|
||||
break subprojects/gst-plugins-base/gst-libs/gst/video/gstvideometa.c:228
|
||||
break subprojects/gstreamer/gst/gstbuffer.c:1410
|
||||
break subprojects/gst-plugins-base/gst-libs/gst/video/gstvideometa.c:231
|
||||
break subprojects/gst-plugins-base/gst-libs/gst/video/gstvideometa.c:237
|
||||
break subprojects/gst-plugins-base/gst-libs/gst/video/video-frame.c:136
|
||||
```
|
||||
|
||||
Breakpoints can be enabled conditionally. The `if meta->n_planes == 4` implies
|
||||
to consider this breakpoint only when we get a video frame with 4 planes.
|
||||
|
||||
We can now tell gdb what should it do when each of the breakpoint above is hit.
|
||||
|
||||
```bash
|
||||
commands 1
|
||||
print i
|
||||
print *frame
|
||||
enable 2
|
||||
enable 3
|
||||
enable 4
|
||||
enable 5
|
||||
enable 6
|
||||
continue
|
||||
end
|
||||
```
|
||||
|
||||
`commands 1` implies these are the commands for gdb to execute when breakpoint
|
||||
1 is hit. When breakpoint 1 is hit, it will print the value of `i` and `frame`.
|
||||
The other breakpoints get enabled only after the first one is hit. This is
|
||||
because at the end of command file, we have
|
||||
|
||||
```bash
|
||||
disable 2
|
||||
disable 3
|
||||
disable 4
|
||||
disable 5
|
||||
disable 6
|
||||
```
|
||||
|
||||
which tells gdb to start with these breakpoints disabled. They will get enabled
|
||||
only when we hit breakpoint 1. The `continue` just tells gdb to continue, as we
|
||||
do not want to stop on hitting a breakpoint and only want to inspect in the end
|
||||
using gdb log.
|
||||
|
||||
Similarly we have for other breakpoints.
|
||||
|
||||
The `run` at the end tells gdb to start running immediately. In normal usage
|
||||
one would have to explicitly type `run` on the gdb prompt to make gdb start
|
||||
debugging.
|
||||
|
||||
Now, since we turned on logging after running the below on the terminal
|
||||
|
||||
```bash
|
||||
gdb --nx -x .gdbinit --args env RUST_BACKTRACE=1 GST_DEBUG=3,basetransform:6 GST_PLUGIN_PATH=$GST_PLUGIN_PATH:~/GitSources/gst-plugins-rs/target/debug gst-launch-1.0 filesrc location=~/Downloads/bunny.mp4 ! decodebin ! videoconvert ! video/x-raw,format=I420 ! roundedcorners border-radius-px=100 ! video/x-raw,format=A420 ! videoconvert ! gtksink
|
||||
```
|
||||
|
||||
gdb will run the pipeline, considering the command file it was passed and log
|
||||
whatever it was asked to log when each breakpoint is encountered. And now since
|
||||
we had turned on logging and pretty printing, gdb will nicely log everything in
|
||||
default `gdb.txt` file. You can see the exact log text file
|
||||
[here](https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/572#note_1107146),
|
||||
where I have attached the `gdbinit` and the other two log files.
|
||||
|
||||
Now, one can comfortably look at this log and see what is going on. Once the
|
||||
command file is written, the whole debugging process is completely automated.
|
||||
Run, sit back and then look at the logs.
|
||||
|
||||
Using gdb is now a breeze and hassle free experience. Being able to automate
|
||||
and log the debugging process like this, also means you could share your
|
||||
command file and someone else can replicate this. Wish I would have learned
|
||||
this sooner.
|
||||
Loading…
Reference in a new issue