Fix code highlighting on all posts
This commit is contained in:
parent
0171106eee
commit
cb2a0bcfff
10 changed files with 299 additions and 261 deletions
|
@ -96,7 +96,7 @@ consumed by GDB nor `debuginfod` (for a good example of a distribution
|
||||||
that does that, see Fedora's `debugsource` packages). Let me show you
|
that does that, see Fedora's `debugsource` packages). Let me show you
|
||||||
an example of debugging GDB itself (using `debuginfod`) on Debian:
|
an example of debugging GDB itself (using `debuginfod`) on Debian:
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ HOME=/tmp DEBUGINFOD_URLS=https://debuginfod.debian.net gdb -q gdb
|
$ HOME=/tmp DEBUGINFOD_URLS=https://debuginfod.debian.net gdb -q gdb
|
||||||
Reading symbols from gdb...
|
Reading symbols from gdb...
|
||||||
Downloading separate debug info for /tmp/gdb...
|
Downloading separate debug info for /tmp/gdb...
|
||||||
|
@ -176,7 +176,7 @@ package. Notice that the last directory's name in both paths is the
|
||||||
same, so in this case we can use GDB's `set substitute-path` command
|
same, so in this case we can use GDB's `set substitute-path` command
|
||||||
do the job for us (in this example `$PWD` is `/tmp/`):
|
do the job for us (in this example `$PWD` is `/tmp/`):
|
||||||
|
|
||||||
```
|
```console
|
||||||
$ HOME=/tmp DEBUGINFOD_URLS=https://debuginfod.debian.net gdb -q gdb
|
$ HOME=/tmp DEBUGINFOD_URLS=https://debuginfod.debian.net gdb -q gdb
|
||||||
Reading symbols from gdb...
|
Reading symbols from gdb...
|
||||||
Reading symbols from /tmp/.cache/debuginfod_client/02046bac4352940d19d9164bab73b2f5cefc8c73/debuginfo...
|
Reading symbols from /tmp/.cache/debuginfod_client/02046bac4352940d19d9164bab73b2f5cefc8c73/debuginfo...
|
||||||
|
@ -224,7 +224,7 @@ whether she wants to use our service by default.
|
||||||
If you would like to start using the service right now, all you have
|
If you would like to start using the service right now, all you have
|
||||||
to do is set the following environment variable in your shell:
|
to do is set the following environment variable in your shell:
|
||||||
|
|
||||||
```
|
```bash
|
||||||
DEBUGINFOD_URLS="https://debuginfod.debian.net"
|
DEBUGINFOD_URLS="https://debuginfod.debian.net"
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
|
@ -122,8 +122,9 @@ We're almost there! The last step before you boot your Fedora LiveUSB is
|
||||||
to actually enable SeaBIOS. Just go inside your superuser shell (from
|
to actually enable SeaBIOS. Just go inside your superuser shell (from
|
||||||
the previous step) and type:
|
the previous step) and type:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
> crossystem dev_boot_usb=1 dev_boot_legacy=1
|
> crossystem dev_boot_usb=1 dev_boot_legacy=1
|
||||||
|
```
|
||||||
|
|
||||||
And that's it!
|
And that's it!
|
||||||
|
|
||||||
|
@ -149,8 +150,9 @@ You can solve that by passing the `mem` parameter to Linux. So, when
|
||||||
GRUB complains that it was unable to load the specified image, it will
|
GRUB complains that it was unable to load the specified image, it will
|
||||||
give you a command prompt (`boot:`), and you just need to type:
|
give you a command prompt (`boot:`), and you just need to type:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
boot: linux mem=1980M
|
boot: linux mem=1980M
|
||||||
|
```
|
||||||
|
|
||||||
And that's it, things should work.
|
And that's it, things should work.
|
||||||
|
|
||||||
|
@ -220,16 +222,18 @@ bug](https://bugzilla.redhat.com/show_bug.cgi?id=1045821#c63)), I found
|
||||||
out about a few Linux flags that I could provide in boot time. To save
|
out about a few Linux flags that I could provide in boot time. To save
|
||||||
you time, this is what I have now in my `/etc/default/grub` file:
|
you time, this is what I have now in my `/etc/default/grub` file:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
GRUB_CMDLINE_LINUX="tpm_tis.force=1 tpm_tis.interrupts=0 ..."
|
GRUB_CMDLINE_LINUX="tpm_tis.force=1 tpm_tis.interrupts=0 ..."
|
||||||
|
```
|
||||||
|
|
||||||
The final `...` means that you should keep whatever was there before you
|
The final `...` means that you should keep whatever was there before you
|
||||||
included those parameters, of course. Also, after you edit this file,
|
included those parameters, of course. Also, after you edit this file,
|
||||||
you need to regenerate the GRUB configuration file on `/boot`. Run the
|
you need to regenerate the GRUB configuration file on `/boot`. Run the
|
||||||
following command as `root`:
|
following command as `root`:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
> grub2-mkconfig -o /boot/grub2/grub.cfg
|
> grub2-mkconfig -o /boot/grub2/grub.cfg
|
||||||
|
```
|
||||||
|
|
||||||
Then, after I rebooted the system, I found that only adding those flags
|
Then, after I rebooted the system, I found that only adding those flags
|
||||||
was still not enough. I saw a bunch of errors on `dmesg`, which showed
|
was still not enough. I saw a bunch of errors on `dmesg`, which showed
|
||||||
|
@ -247,33 +251,36 @@ because the system is using the touchpad and the touchscreen to
|
||||||
determine whether it should resume from suspend or not. So basically
|
determine whether it should resume from suspend or not. So basically
|
||||||
what you have to do is to disable those sources of events:
|
what you have to do is to disable those sources of events:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
echo TPAD > /proc/acpi/wakeup
|
echo TPAD > /proc/acpi/wakeup
|
||||||
echo TSCR > /proc/acpi/wakeup
|
echo TSCR > /proc/acpi/wakeup
|
||||||
|
```
|
||||||
|
|
||||||
And voilà! Now everything should work as expected :-). You might want to
|
And voilà! Now everything should work as expected :-). You might want to
|
||||||
issue those commands every time you boot the system, in order to get
|
issue those commands every time you boot the system, in order to get
|
||||||
suspend to work every time, of course. To do that, you can create a
|
suspend to work every time, of course. To do that, you can create a
|
||||||
`/etc/rc.d/rc.local`, which gets executed when the system starts:
|
`/etc/rc.d/rc.local`, which gets executed when the system starts:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
> cat /etc/rc.d/rc.local
|
> cat /etc/rc.d/rc.local
|
||||||
#!/bin/bash
|
#!/bin/bash
|
||||||
|
|
||||||
suspend_tricks()
|
suspend_tricks()
|
||||||
{
|
{
|
||||||
echo TPAD > /proc/acpi/wakeup
|
echo TPAD > /proc/acpi/wakeup
|
||||||
echo TSCR > /proc/acpi/wakeup
|
echo TSCR > /proc/acpi/wakeup
|
||||||
}
|
}
|
||||||
|
|
||||||
suspend_tricks
|
suspend_tricks
|
||||||
|
|
||||||
exit 0
|
exit 0
|
||||||
|
```
|
||||||
|
|
||||||
Don't forget to make this file executable:
|
Don't forget to make this file executable:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
> chmod +x /etc/rc.d/rc.local
|
> chmod +x /etc/rc.d/rc.local
|
||||||
|
```
|
||||||
|
|
||||||
Conclusion
|
Conclusion
|
||||||
----------
|
----------
|
||||||
|
|
|
@ -30,24 +30,26 @@ systems, you can obtain this header file by installing the package
|
||||||
|
|
||||||
Here's a simple example of an application with a one-argument probe:
|
Here's a simple example of an application with a one-argument probe:
|
||||||
|
|
||||||
#!c
|
```c
|
||||||
#include <sys/sdt.h>
|
#include <sys/sdt.h>
|
||||||
|
|
||||||
int
|
int
|
||||||
main (int argc, char *argv[])
|
main (int argc, char *argv[])
|
||||||
{
|
{
|
||||||
int a = 10;
|
int a = 10;
|
||||||
|
|
||||||
STAP_PROBE1 (test_program, my_probe, a);
|
STAP_PROBE1 (test_program, my_probe, a);
|
||||||
|
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
|
```
|
||||||
|
|
||||||
As you can see, this is a very simple program with one probe, which
|
As you can see, this is a very simple program with one probe, which
|
||||||
contains one argument. You can now compile the program:
|
contains one argument. You can now compile the program:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
$ gcc test_program.c -o test_program
|
$ gcc test_program.c -o test_program
|
||||||
|
```
|
||||||
|
|
||||||
Now you must be thinking: "*Wait, wait... Didn't you just forget to link
|
Now you must be thinking: "*Wait, wait... Didn't you just forget to link
|
||||||
this program against some SystemTap-specific library or something?*" And
|
this program against some SystemTap-specific library or something?*" And
|
||||||
|
@ -59,15 +61,16 @@ As Tom said in [his blog post](http://tromey.com/blog/?p=687), this is
|
||||||
If you want to make sure your probe was inserted in the binary, you can
|
If you want to make sure your probe was inserted in the binary, you can
|
||||||
use `readelf` command:
|
use `readelf` command:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
$ readelf -x .note.stapsdt ./test_program
|
$ readelf -x .note.stapsdt ./test_program
|
||||||
|
|
||||||
Hex dump of section '.note.stapsdt':
|
Hex dump of section '.note.stapsdt':
|
||||||
0x00000000 08000000 3a000000 03000000 73746170 ....:.......stap
|
0x00000000 08000000 3a000000 03000000 73746170 ....:.......stap
|
||||||
0x00000010 73647400 86044000 00000000 88054000 sdt...@.......@.
|
0x00000010 73647400 86044000 00000000 88054000 sdt...@.......@.
|
||||||
0x00000020 00000000 00000000 00000000 74657374 ............test
|
0x00000020 00000000 00000000 00000000 74657374 ............test
|
||||||
0x00000030 5f70726f 6772616d 006d795f 70726f62 _program.my_prob
|
0x00000030 5f70726f 6772616d 006d795f 70726f62 _program.my_prob
|
||||||
0x00000040 65002d34 402d3428 25726270 29000000 e.-4@-4(%rbp)...
|
0x00000040 65002d34 402d3428 25726270 29000000 e.-4@-4(%rbp)...
|
||||||
|
```
|
||||||
|
|
||||||
*(I will think about writing an explanation on how the probes are laid
|
*(I will think about writing an explanation on how the probes are laid
|
||||||
out on the binary, but for now you just have to care if you actually
|
out on the binary, but for now you just have to care if you actually
|
||||||
|
@ -75,9 +78,10 @@ see an output from this* `readelf` *command.)*
|
||||||
|
|
||||||
You can also use SystemTap to perform this verification:
|
You can also use SystemTap to perform this verification:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
$ stap -L 'process("./test_program").mark("*")'
|
$ stap -L 'process("./test_program").mark("*")'
|
||||||
process("./test_program").mark("my_probe") $arg1:long
|
process("./test_program").mark("my_probe") $arg1:long
|
||||||
|
```
|
||||||
|
|
||||||
So far, so good. If you see an output like the one above, it means your
|
So far, so good. If you see an output like the one above, it means your
|
||||||
probe is correctly inserted. You could obviously use SystemTap to
|
probe is correctly inserted. You could obviously use SystemTap to
|
||||||
|
|
|
@ -33,9 +33,10 @@ It is not the goal of this post to explain it in detail, but you might
|
||||||
want to give it a try by compiling your binary with debuginfo support
|
want to give it a try by compiling your binary with debuginfo support
|
||||||
(use the `-g` flag on `GCC`), and do something like:
|
(use the `-g` flag on `GCC`), and do something like:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
$ stap -e 'probe process("/bin/foo").function("name") { log($$parms) }' -c /bin/foo
|
$ stap -e 'probe process("/bin/foo").function("name") { log($$parms) }' -c /bin/foo
|
||||||
$ stap -e 'probe process("/bin/foo").statement("*@file.c:443") { log($$vars) }' -c /bin/foo
|
$ stap -e 'probe process("/bin/foo").statement("*@file.c:443") { log($$vars) }' -c /bin/foo
|
||||||
|
```
|
||||||
|
|
||||||
And that's it. You can read SystemTap's documentation, or
|
And that's it. You can read SystemTap's documentation, or
|
||||||
[this](http://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps)
|
[this](http://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps)
|
||||||
|
@ -48,18 +49,19 @@ Well, now let's get to the interesting part. It is time to make `GDB`
|
||||||
work with the `SDT` probe that we have put in our example code. Let's
|
work with the `SDT` probe that we have put in our example code. Let's
|
||||||
remember it:
|
remember it:
|
||||||
|
|
||||||
#!c
|
```c
|
||||||
#include <sys/sdt.h>
|
#include <sys/sdt.h>
|
||||||
|
|
||||||
int
|
int
|
||||||
main (int argc, char *argv[])
|
main (int argc, char *argv[])
|
||||||
{
|
{
|
||||||
int a = 10;
|
int a = 10;
|
||||||
|
|
||||||
STAP_PROBE1 (test_program, my_probe, a);
|
STAP_PROBE1 (test_program, my_probe, a);
|
||||||
|
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
|
```
|
||||||
|
|
||||||
It is a very simple example, and we will have to extend it later in
|
It is a very simple example, and we will have to extend it later in
|
||||||
order to show more features. But for now, it will do.
|
order to show more features. But for now, it will do.
|
||||||
|
@ -68,15 +70,16 @@ The first thing to do is to open `GDB` (with SystemTap support, of
|
||||||
course!), and check to see if it can actually see probe inserted in our
|
course!), and check to see if it can actually see probe inserted in our
|
||||||
example.
|
example.
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
$ gdb ./test_program
|
$ gdb ./test_program
|
||||||
GNU gdb (GDB) 7.5.50.20121014-cvs
|
GNU gdb (GDB) 7.5.50.20121014-cvs
|
||||||
Copyright (C) 2012 Free Software Foundation, Inc.
|
Copyright (C) 2012 Free Software Foundation, Inc.
|
||||||
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
|
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
|
||||||
...
|
...
|
||||||
(gdb) info probes
|
(gdb) info probes
|
||||||
Provider Name Where Semaphore Object
|
Provider Name Where Semaphore Object
|
||||||
test_program my_probe 0x00000000004004ae /home/sergio/work/src/git/build/gdb/test_program
|
test_program my_probe 0x00000000004004ae /home/sergio/work/src/git/build/gdb/test_program
|
||||||
|
```
|
||||||
|
|
||||||
Wow, it actually works! :-)
|
Wow, it actually works! :-)
|
||||||
|
|
||||||
|
@ -91,9 +94,10 @@ use the `SDT` support.
|
||||||
Anyway, now it is time to start using this support. The first thing I
|
Anyway, now it is time to start using this support. The first thing I
|
||||||
want to show you is how to put a breakpoint in a probe.
|
want to show you is how to put a breakpoint in a probe.
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
(gdb) break -probe-stap my_probe
|
(gdb) break -probe-stap my_probe
|
||||||
Breakpoint 1 at 0x4004ae
|
Breakpoint 1 at 0x4004ae
|
||||||
|
```
|
||||||
|
|
||||||
That's all! We have chosen to extend the `break` command in order to
|
That's all! We have chosen to extend the `break` command in order to
|
||||||
support the new `-probe-stap` parameter. If you're wondering *... why
|
support the new `-probe-stap` parameter. If you're wondering *... why
|
||||||
|
@ -112,12 +116,13 @@ the one reported by `break`: they should be the same.
|
||||||
Ok, so now, with our `breakpoint` in place, let's run the program and
|
Ok, so now, with our `breakpoint` in place, let's run the program and
|
||||||
see what happens.
|
see what happens.
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
(gdb) run
|
(gdb) run
|
||||||
Starting program: /home/sergio/work/src/git/build/gdb/test_program
|
Starting program: /home/sergio/work/src/git/build/gdb/test_program
|
||||||
|
|
||||||
Breakpoint 1, main (argc=1, argv=0x7fffffffdf68) at /tmp/example-stap.c:8
|
Breakpoint 1, main (argc=1, argv=0x7fffffffdf68) at /tmp/example-stap.c:8
|
||||||
8 STAP_PROBE1 (test_program, my_probe, a);
|
8 STAP_PROBE1 (test_program, my_probe, a);
|
||||||
|
```
|
||||||
|
|
||||||
As you can see, `GDB` stopped at the exact location of the probe.
|
As you can see, `GDB` stopped at the exact location of the probe.
|
||||||
Therefore, you are now able to put marks (i.e., probes) in your source
|
Therefore, you are now able to put marks (i.e., probes) in your source
|
||||||
|
@ -135,11 +140,12 @@ inspect the probe's arguments? Yes, let's do it now!
|
||||||
Just remember that, in `SDT`'s parlance, the current probe's argument is
|
Just remember that, in `SDT`'s parlance, the current probe's argument is
|
||||||
`a`. So let's print its value.
|
`a`. So let's print its value.
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
(gdb) p $_probe_arg0
|
(gdb) p $_probe_arg0
|
||||||
$1 = 10
|
$1 = 10
|
||||||
(gdb) p a
|
(gdb) p a
|
||||||
$2 = 10
|
$2 = 10
|
||||||
|
```
|
||||||
|
|
||||||
*"Hey, captain, it seems the boat really floats!"*
|
*"Hey, captain, it seems the boat really floats!"*
|
||||||
|
|
||||||
|
|
|
@ -59,19 +59,19 @@ Ok, so now we have to learn how to put `tracepoints` in our code, and
|
||||||
how to define actions for them. But before that, let's remember our
|
how to define actions for them. But before that, let's remember our
|
||||||
example program:
|
example program:
|
||||||
|
|
||||||
#!c
|
```c
|
||||||
#include <sys/sdt.h>
|
#include <sys/sdt.h>
|
||||||
|
|
||||||
int
|
int
|
||||||
main (int argc, char *argv[])
|
main (int argc, char *argv[])
|
||||||
{
|
{
|
||||||
int a = 10;
|
int a = 10;
|
||||||
|
|
||||||
STAP_PROBE1 (test_program, my_probe, a);
|
STAP_PROBE1 (test_program, my_probe, a);
|
||||||
|
|
||||||
return 0;
|
return 0;
|
||||||
}
|
}
|
||||||
|
```
|
||||||
|
|
||||||
Very simple, isn't it? Ok, to the `tracepoints` now, my friends.
|
Very simple, isn't it? Ok, to the `tracepoints` now, my friends.
|
||||||
|
|
||||||
|
@ -94,10 +94,11 @@ First of all, make sure you have `gdbserver` installed. If you use
|
||||||
Fedora, the package name you will have to install is `gdb-gdbserver`. If
|
Fedora, the package name you will have to install is `gdb-gdbserver`. If
|
||||||
you have it installed, you can do:
|
you have it installed, you can do:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
$ gdbserver :3001 ./test_program
|
$ gdbserver :3001 ./test_program
|
||||||
Process ./test_program created; pid = 17793
|
Process ./test_program created; pid = 17793
|
||||||
Listening on port 3001
|
Listening on port 3001
|
||||||
|
```
|
||||||
|
|
||||||
The second argument passed to `gdbserver` instructs it to listen on the
|
The second argument passed to `gdbserver` instructs it to listen on the
|
||||||
port 3001 of your loopback interface, a.k.a. `localhost`.
|
port 3001 of your loopback interface, a.k.a. `localhost`.
|
||||||
|
@ -109,14 +110,15 @@ for new connections to arrive. Don't worry, we will connect to it soon!
|
||||||
|
|
||||||
Now, go to another terminal and start `GDB` with our program:
|
Now, go to another terminal and start `GDB` with our program:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
$ gdb ./test_program
|
$ gdb ./test_program
|
||||||
...
|
...
|
||||||
(gdb) target remote :3001
|
(gdb) target remote :3001
|
||||||
Remote debugging using :3001
|
Remote debugging using :3001
|
||||||
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
|
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
|
||||||
Loaded symbols for /lib64/ld-linux-x86-64.so.2
|
Loaded symbols for /lib64/ld-linux-x86-64.so.2
|
||||||
0x0000003d60401530 in _start () from /lib64/ld-linux-x86-64.so.2
|
0x0000003d60401530 in _start () from /lib64/ld-linux-x86-64.so.2
|
||||||
|
```
|
||||||
|
|
||||||
The command you have to use inside `GDB` is `target remote`. It takes as
|
The command you have to use inside `GDB` is `target remote`. It takes as
|
||||||
an argument the host and the port to which you want to connect. In our
|
an argument the host and the port to which you want to connect. In our
|
||||||
|
@ -135,9 +137,10 @@ Ok, so now it is time to start our *trace experiment*!
|
||||||
|
|
||||||
In your `GDB` prompt, put a `tracepoint` in the probe named `my_probe`:
|
In your `GDB` prompt, put a `tracepoint` in the probe named `my_probe`:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
(gdb) trace -probe-stap my_probe
|
(gdb) trace -probe-stap my_probe
|
||||||
Tracepoint 1 at 0x4005a9
|
Tracepoint 1 at 0x4005a9
|
||||||
|
```
|
||||||
|
|
||||||
As you can see, the `trace` command takes exactly the same arguments as
|
As you can see, the `trace` command takes exactly the same arguments as
|
||||||
the `break` command. Thus, you need to use the `-probe-stap` modified in
|
the `break` command. Thus, you need to use the `-probe-stap` modified in
|
||||||
|
@ -152,13 +155,14 @@ For this example, we will use only the `collect` keyword, which tells
|
||||||
`GDB` to... hm... collect something :-). In our case, it will collect
|
`GDB` to... hm... collect something :-). In our case, it will collect
|
||||||
the probe's first argument, or `$_probe_arg0`, as you may remember.
|
the probe's first argument, or `$_probe_arg0`, as you may remember.
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
(gdb) actions
|
(gdb) actions
|
||||||
Enter actions for tracepoint 1, one per line.
|
Enter actions for tracepoint 1, one per line.
|
||||||
End with a line saying just "end".
|
End with a line saying just "end".
|
||||||
>collect $_probe_arg0
|
>collect $_probe_arg0
|
||||||
>end
|
>end
|
||||||
(gdb)
|
(gdb)
|
||||||
|
```
|
||||||
|
|
||||||
Simple as that. Finally, we have to define a `breakpoint` in the last
|
Simple as that. Finally, we have to define a `breakpoint` in the last
|
||||||
instruction of our program, because it is necessary to keep it running
|
instruction of our program, because it is necessary to keep it running
|
||||||
|
@ -174,15 +178,16 @@ Ok, time to run our trace experiment. First, we must issue a `tstart` to
|
||||||
tell `GDB` to start monitoring the `tracepoints`. And then, we can
|
tell `GDB` to start monitoring the `tracepoints`. And then, we can
|
||||||
continue our program normally.
|
continue our program normally.
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
(gdb) tstart
|
(gdb) tstart
|
||||||
(gdb) continue
|
(gdb) continue
|
||||||
Continuing.
|
Continuing.
|
||||||
|
|
||||||
Breakpoint 1, main (argc=1, argv=0x7fffffffde88) at /tmp/test_program.c:10
|
Breakpoint 1, main (argc=1, argv=0x7fffffffde88) at /tmp/test_program.c:10
|
||||||
10 return 0;
|
10 return 0;
|
||||||
(gdb) tstop
|
(gdb) tstop
|
||||||
(gdb)
|
(gdb)
|
||||||
|
```
|
||||||
|
|
||||||
Remember, `GDB` is **not** going to stop your program, because
|
Remember, `GDB` is **not** going to stop your program, because
|
||||||
`tracepoints` are designed to not interfere with the execution of it.
|
`tracepoints` are designed to not interfere with the execution of it.
|
||||||
|
@ -193,12 +198,13 @@ Now, we will be able to examine what the `tracepoint` has collected.
|
||||||
First, we will the `tfind` command to make sure the `tracepoint` has
|
First, we will the `tfind` command to make sure the `tracepoint` has
|
||||||
hit, and then we can inspect what we ordered it to collect:
|
hit, and then we can inspect what we ordered it to collect:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
(gdb) tfind start
|
(gdb) tfind start
|
||||||
Found trace frame 0, tracepoint 1
|
Found trace frame 0, tracepoint 1
|
||||||
8 STAP_PROBE1 (test_program, my_probe, a);
|
8 STAP_PROBE1 (test_program, my_probe, a);
|
||||||
(gdb) p $_probe_arg0
|
(gdb) p $_probe_arg0
|
||||||
$1 = 10
|
$1 = 10
|
||||||
|
```
|
||||||
|
|
||||||
And it works! Notice that we are printing the probe argument using the
|
And it works! Notice that we are printing the probe argument using the
|
||||||
same notation as with `breakpoints`, even though we are not exactly
|
same notation as with `breakpoints`, even though we are not exactly
|
||||||
|
|
|
@ -47,8 +47,9 @@ to always encrypt the message to myself too.
|
||||||
You basically have to edit your `$HOME/.gnupg/gpg.conf` file and put
|
You basically have to edit your `$HOME/.gnupg/gpg.conf` file and put
|
||||||
this setting there:
|
this setting there:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
hidden-encrypt-to ID
|
hidden-encrypt-to ID
|
||||||
|
```
|
||||||
|
|
||||||
That's it. Now, whenever I send an encrypted message, GnuPG encrypts it
|
That's it. Now, whenever I send an encrypted message, GnuPG encrypts it
|
||||||
for me as well, so I just need to go to my “Sent/” folder, and decrypt
|
for me as well, so I just need to go to my “Sent/” folder, and decrypt
|
||||||
|
|
|
@ -66,11 +66,13 @@ the binutils guys to fix it, which meant less work for us :-).
|
||||||
With a lot of help from Keith Seitz, I was able to bisect the problem
|
With a lot of help from Keith Seitz, I was able to bisect the problem
|
||||||
and found that it started with the following commit:
|
and found that it started with the following commit:
|
||||||
|
|
||||||
commit f6aec96dce1ddbd8961a3aa8a2925db2021719bb
|
```
|
||||||
Author: H.J. Lu <hjl.tools@gmail.com>
|
commit f6aec96dce1ddbd8961a3aa8a2925db2021719bb
|
||||||
Date: Tue Feb 27 11:34:20 2018 -0800
|
Author: H.J. Lu <hjl.tools@gmail.com>
|
||||||
|
Date: Tue Feb 27 11:34:20 2018 -0800
|
||||||
|
|
||||||
ld: Add --enable-separate-code
|
ld: Add --enable-separate-code
|
||||||
|
```
|
||||||
|
|
||||||
This is a commit that touches the linker, which is part of binutils.
|
This is a commit that touches the linker, which is part of binutils.
|
||||||
So that means this is not GDB's problem, right?!? Hmm. No,
|
So that means this is not GDB's problem, right?!? Hmm. No,
|
||||||
|
@ -95,75 +97,79 @@ everything (code and data) was put together in the same memory
|
||||||
region. What this means in practice is that, before, you would see
|
region. What this means in practice is that, before, you would see
|
||||||
something like this when you examined `/proc/PID/smaps`:
|
something like this when you examined `/proc/PID/smaps`:
|
||||||
|
|
||||||
00400000-00401000 r-xp 00000000 fc:01 798593 /file
|
```
|
||||||
Size: 4 kB
|
00400000-00401000 r-xp 00000000 fc:01 798593 /file
|
||||||
KernelPageSize: 4 kB
|
Size: 4 kB
|
||||||
MMUPageSize: 4 kB
|
KernelPageSize: 4 kB
|
||||||
Rss: 4 kB
|
MMUPageSize: 4 kB
|
||||||
Pss: 4 kB
|
Rss: 4 kB
|
||||||
Shared_Clean: 0 kB
|
Pss: 4 kB
|
||||||
Shared_Dirty: 0 kB
|
Shared_Clean: 0 kB
|
||||||
Private_Clean: 0 kB
|
Shared_Dirty: 0 kB
|
||||||
Private_Dirty: 4 kB
|
Private_Clean: 0 kB
|
||||||
Referenced: 4 kB
|
Private_Dirty: 4 kB
|
||||||
Anonymous: 4 kB
|
Referenced: 4 kB
|
||||||
LazyFree: 0 kB
|
Anonymous: 4 kB
|
||||||
AnonHugePages: 0 kB
|
LazyFree: 0 kB
|
||||||
ShmemPmdMapped: 0 kB
|
AnonHugePages: 0 kB
|
||||||
Shared_Hugetlb: 0 kB
|
ShmemPmdMapped: 0 kB
|
||||||
Private_Hugetlb: 0 kB
|
Shared_Hugetlb: 0 kB
|
||||||
Swap: 0 kB
|
Private_Hugetlb: 0 kB
|
||||||
SwapPss: 0 kB
|
Swap: 0 kB
|
||||||
Locked: 0 kB
|
SwapPss: 0 kB
|
||||||
THPeligible: 0
|
Locked: 0 kB
|
||||||
VmFlags: rd ex mr mw me dw sd
|
THPeligible: 0
|
||||||
|
VmFlags: rd ex mr mw me dw sd
|
||||||
|
```
|
||||||
|
|
||||||
And now, you will see two memory regions instead, like this:
|
And now, you will see two memory regions instead, like this:
|
||||||
|
|
||||||
00400000-00401000 r--p 00000000 fc:01 799548 /file
|
```
|
||||||
Size: 4 kB
|
00400000-00401000 r--p 00000000 fc:01 799548 /file
|
||||||
KernelPageSize: 4 kB
|
Size: 4 kB
|
||||||
MMUPageSize: 4 kB
|
KernelPageSize: 4 kB
|
||||||
Rss: 4 kB
|
MMUPageSize: 4 kB
|
||||||
Pss: 4 kB
|
Rss: 4 kB
|
||||||
Shared_Clean: 0 kB
|
Pss: 4 kB
|
||||||
Shared_Dirty: 0 kB
|
Shared_Clean: 0 kB
|
||||||
Private_Clean: 4 kB
|
Shared_Dirty: 0 kB
|
||||||
Private_Dirty: 0 kB
|
Private_Clean: 4 kB
|
||||||
Referenced: 4 kB
|
Private_Dirty: 0 kB
|
||||||
Anonymous: 0 kB
|
Referenced: 4 kB
|
||||||
LazyFree: 0 kB
|
Anonymous: 0 kB
|
||||||
AnonHugePages: 0 kB
|
LazyFree: 0 kB
|
||||||
ShmemPmdMapped: 0 kB
|
AnonHugePages: 0 kB
|
||||||
Shared_Hugetlb: 0 kB
|
ShmemPmdMapped: 0 kB
|
||||||
Private_Hugetlb: 0 kB
|
Shared_Hugetlb: 0 kB
|
||||||
Swap: 0 kB
|
Private_Hugetlb: 0 kB
|
||||||
SwapPss: 0 kB
|
Swap: 0 kB
|
||||||
Locked: 0 kB
|
SwapPss: 0 kB
|
||||||
THPeligible: 0
|
Locked: 0 kB
|
||||||
VmFlags: rd mr mw me dw sd
|
THPeligible: 0
|
||||||
00401000-00402000 r-xp 00001000 fc:01 799548 /file
|
VmFlags: rd mr mw me dw sd
|
||||||
Size: 4 kB
|
00401000-00402000 r-xp 00001000 fc:01 799548 /file
|
||||||
KernelPageSize: 4 kB
|
Size: 4 kB
|
||||||
MMUPageSize: 4 kB
|
KernelPageSize: 4 kB
|
||||||
Rss: 4 kB
|
MMUPageSize: 4 kB
|
||||||
Pss: 4 kB
|
Rss: 4 kB
|
||||||
Shared_Clean: 0 kB
|
Pss: 4 kB
|
||||||
Shared_Dirty: 0 kB
|
Shared_Clean: 0 kB
|
||||||
Private_Clean: 0 kB
|
Shared_Dirty: 0 kB
|
||||||
Private_Dirty: 4 kB
|
Private_Clean: 0 kB
|
||||||
Referenced: 4 kB
|
Private_Dirty: 4 kB
|
||||||
Anonymous: 4 kB
|
Referenced: 4 kB
|
||||||
LazyFree: 0 kB
|
Anonymous: 4 kB
|
||||||
AnonHugePages: 0 kB
|
LazyFree: 0 kB
|
||||||
ShmemPmdMapped: 0 kB
|
AnonHugePages: 0 kB
|
||||||
Shared_Hugetlb: 0 kB
|
ShmemPmdMapped: 0 kB
|
||||||
Private_Hugetlb: 0 kB
|
Shared_Hugetlb: 0 kB
|
||||||
Swap: 0 kB
|
Private_Hugetlb: 0 kB
|
||||||
SwapPss: 0 kB
|
Swap: 0 kB
|
||||||
Locked: 0 kB
|
SwapPss: 0 kB
|
||||||
THPeligible: 0
|
Locked: 0 kB
|
||||||
VmFlags: rd ex mr mw me dw sd
|
THPeligible: 0
|
||||||
|
VmFlags: rd ex mr mw me dw sd
|
||||||
|
```
|
||||||
|
|
||||||
A few minor things have changed, but the most important of them is the
|
A few minor things have changed, but the most important of them is the
|
||||||
fact that, before, the whole memory region **had** anonymous data in
|
fact that, before, the whole memory region **had** anonymous data in
|
||||||
|
@ -240,9 +246,8 @@ Linux also makes these checks, by the way.
|
||||||
The patch, finally
|
The patch, finally
|
||||||
------------------
|
------------------
|
||||||
|
|
||||||
I
|
I submitted [the
|
||||||
submitted
|
patch](https://sourceware.org/ml/gdb-patches/2019-04/msg00479.html) to
|
||||||
[the patch](https://sourceware.org/ml/gdb-patches/2019-04/msg00479.html) to
|
|
||||||
the mailing list, and it was approved fairly quickly (with a few minor
|
the mailing list, and it was approved fairly quickly (with a few minor
|
||||||
nits).
|
nits).
|
||||||
|
|
||||||
|
@ -253,8 +258,7 @@ interesting to come up with a solution that extended the work I did a
|
||||||
few years ago. I was also able to close a few bug reports upstream,
|
few years ago. I was also able to close a few bug reports upstream,
|
||||||
as well as the one reported against Fedora GDB.
|
as well as the one reported against Fedora GDB.
|
||||||
|
|
||||||
The patch has
|
The patch has been
|
||||||
been
|
|
||||||
[pushed](https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=57e5e645010430b3d73f8c6a757d09f48dc8f8d5),
|
[pushed](https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=57e5e645010430b3d73f8c6a757d09f48dc8f8d5),
|
||||||
and is also present at the latest version of Fedora GDB for Rawhide.
|
and is also present at the latest version of Fedora GDB for Rawhide.
|
||||||
It wasn't possible to write a self-contained testcase for this
|
It wasn't possible to write a self-contained testcase for this
|
||||||
|
|
|
@ -180,10 +180,12 @@ Java 8, but unlike Keycloak, it doesn't work out of the box with
|
||||||
OpenJDK 11. I had to make a small but important addition in the file
|
OpenJDK 11. I had to make a small but important addition in the file
|
||||||
`etc/gerrit.config`:
|
`etc/gerrit.config`:
|
||||||
|
|
||||||
[container]
|
```ini
|
||||||
|
[container]
|
||||||
...
|
...
|
||||||
javaOptions = "--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED"
|
javaOptions = "--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED"
|
||||||
...
|
...
|
||||||
|
```
|
||||||
|
|
||||||
After that, I was able to start gerrit. And then I started trying to
|
After that, I was able to start gerrit. And then I started trying to
|
||||||
set it up for OAuth2 authentication using Keycloak. This took a
|
set it up for OAuth2 authentication using Keycloak. This took a
|
||||||
|
@ -198,13 +200,14 @@ causing a very strange error on Gerrit (as you can see, a
|
||||||
`java.lang.StringIndexOutOfBoundsException`!), which didn't make
|
`java.lang.StringIndexOutOfBoundsException`!), which didn't make
|
||||||
sense. In the end, my Apache config file looks like this:
|
sense. In the end, my Apache config file looks like this:
|
||||||
|
|
||||||
<VirtualHost *:80>
|
```apacheconf
|
||||||
|
<VirtualHost *:80>
|
||||||
ServerName gnutoolchain-gerrit.osci.io
|
ServerName gnutoolchain-gerrit.osci.io
|
||||||
|
|
||||||
RedirectPermanent / https://gnutoolchain-gerrit.osci.io/r/
|
RedirectPermanent / https://gnutoolchain-gerrit.osci.io/r/
|
||||||
</VirtualHost>
|
</VirtualHost>
|
||||||
|
|
||||||
<VirtualHost *:443>
|
<VirtualHost *:443>
|
||||||
ServerName gnutoolchain-gerrit.osci.io
|
ServerName gnutoolchain-gerrit.osci.io
|
||||||
|
|
||||||
RedirectPermanent / /r/
|
RedirectPermanent / /r/
|
||||||
|
@ -243,7 +246,8 @@ sense. In the end, my Apache config file looks like this:
|
||||||
AllowEncodedSlashes On
|
AllowEncodedSlashes On
|
||||||
ProxyPass /r/ http://127.0.0.1:8081/ nocanon
|
ProxyPass /r/ http://127.0.0.1:8081/ nocanon
|
||||||
#ProxyPassReverse /r/ http://127.0.0.1:8081/r/
|
#ProxyPassReverse /r/ http://127.0.0.1:8081/r/
|
||||||
</VirtualHost>
|
</VirtualHost>
|
||||||
|
```
|
||||||
|
|
||||||
I confess I was almost giving up Keycloak when I finally found
|
I confess I was almost giving up Keycloak when I finally found
|
||||||
the problem...
|
the problem...
|
||||||
|
@ -259,10 +263,12 @@ gerrit that the user was already logged in, and gerrit would
|
||||||
automatically log the user in again! I was able to solve this by
|
automatically log the user in again! I was able to solve this by
|
||||||
redirecting the user to Keycloak's logout page, like this:
|
redirecting the user to Keycloak's logout page, like this:
|
||||||
|
|
||||||
[auth]
|
```ini
|
||||||
|
[auth]
|
||||||
...
|
...
|
||||||
logoutUrl = https://keycloak-url:port/auth/realms/REALM/protocol/openid-connect/logout?redirect_uri=https://gerrit-url/
|
logoutUrl = https://keycloak-url:port/auth/realms/REALM/protocol/openid-connect/logout?redirect_uri=https://gerrit-url/
|
||||||
...
|
...
|
||||||
|
```
|
||||||
|
|
||||||
After that, it was already possible to start worrying about configure
|
After that, it was already possible to start worrying about configure
|
||||||
gerrit itself. I don't know if I'll write a post about that, but let
|
gerrit itself. I don't know if I'll write a post about that, but let
|
||||||
|
|
|
@ -156,10 +156,11 @@ here](http://sergiodj.net/~sergio/jabberd2-migration/j2to1.txt). Save
|
||||||
the file as `j2to1.pl`, and run the script (don't forget to edit the
|
the file as `j2to1.pl`, and run the script (don't forget to edit the
|
||||||
source code in order to provide the database name/file):
|
source code in order to provide the database name/file):
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
$> perl j2to1.pl jabberd14-dir/
|
$> perl j2to1.pl jabberd14-dir/
|
||||||
Converting user@host...
|
Converting user@host...
|
||||||
$>
|
$>
|
||||||
|
```
|
||||||
|
|
||||||
This will convert the database from Jabberd2 to Jabberd14, and put the
|
This will convert the database from Jabberd2 to Jabberd14, and put the
|
||||||
XML file of each Jabber user in the server into `jabberd14-dir/host/`.
|
XML file of each Jabber user in the server into `jabberd14-dir/host/`.
|
||||||
|
@ -171,8 +172,9 @@ page](https://github.com/Kev/sleekmigrate) on how to set it up, you can
|
||||||
run it on your Jabberd14 data directory in order to finally generate a
|
run it on your Jabberd14 data directory in order to finally generate a
|
||||||
XEP-0227 XML file that will be imported into Prosody.
|
XEP-0227 XML file that will be imported into Prosody.
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
$> ./sleekmigrate.py -j /path/to/jabberd14-dir/
|
$> ./sleekmigrate.py -j /path/to/jabberd14-dir/
|
||||||
|
```
|
||||||
|
|
||||||
This should create a file called `227.xml` on your current directory,
|
This should create a file called `227.xml` on your current directory,
|
||||||
which is the exported version of the Jabberd14 data directory. As a side
|
which is the exported version of the Jabberd14 data directory. As a side
|
||||||
|
@ -194,15 +196,17 @@ working. I also had to build some POSIX module of Prosody in order to
|
||||||
make everything work. To do that, unpack the `tar.gz` file, go to the
|
make everything work. To do that, unpack the `tar.gz` file, go to the
|
||||||
Prosody source code directory, and do:
|
Prosody source code directory, and do:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
$> apt-get build-dep prosody && ./configure --ostype=debian && make
|
$> apt-get build-dep prosody && ./configure --ostype=debian && make
|
||||||
|
```
|
||||||
|
|
||||||
Only after I did that I could finally run the conversion script
|
Only after I did that I could finally run the conversion script
|
||||||
successfully. The script is locate inside the `tools/` directory. To run
|
successfully. The script is locate inside the `tools/` directory. To run
|
||||||
it:
|
it:
|
||||||
|
|
||||||
#!bash
|
```console
|
||||||
$> cd tools && lua ./xep227toprosody.lua /path/to/227.xml
|
$> cd tools && lua ./xep227toprosody.lua /path/to/227.xml
|
||||||
|
```
|
||||||
|
|
||||||
And yay! I **finally** had everything imported into Prosody!!!! Then it
|
And yay! I **finally** had everything imported into Prosody!!!! Then it
|
||||||
was just a matter of finishing the server configuration, initializing
|
was just a matter of finishing the server configuration, initializing
|
||||||
|
|
|
@ -42,7 +42,7 @@ little configuration.
|
||||||
On the server side (i.e., VPS or dedicated server), you will create
|
On the server side (i.e., VPS or dedicated server), you will create
|
||||||
the first endpoint. Something like the following should do:
|
the first endpoint. Something like the following should do:
|
||||||
|
|
||||||
```nil
|
```ini
|
||||||
[Interface]
|
[Interface]
|
||||||
PrivateKey = PRIVATE_KEY_HERE
|
PrivateKey = PRIVATE_KEY_HERE
|
||||||
Address = 10.0.0.1/32
|
Address = 10.0.0.1/32
|
||||||
|
@ -73,7 +73,7 @@ A few interesting points to note:
|
||||||
|
|
||||||
At your home, you will configure the peer:
|
At your home, you will configure the peer:
|
||||||
|
|
||||||
```nil
|
```ini
|
||||||
[Interface]
|
[Interface]
|
||||||
PrivateKey = PRIVATE_KEY_HERE
|
PrivateKey = PRIVATE_KEY_HERE
|
||||||
Address = 10.0.0.2/32
|
Address = 10.0.0.2/32
|
||||||
|
|
Loading…
Reference in a new issue