Compare commits
No commits in common. "e834ef4aaed44d1d26b99f5cd58cf329d811b262" and "0171106eeec41c2b8933ff429a476265fc1c226b" have entirely different histories.
e834ef4aae
...
0171106eee
11 changed files with 261 additions and 299 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
|
||||
an example of debugging GDB itself (using `debuginfod`) on Debian:
|
||||
|
||||
```console
|
||||
```
|
||||
$ HOME=/tmp DEBUGINFOD_URLS=https://debuginfod.debian.net gdb -q gdb
|
||||
Reading symbols from 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
|
||||
do the job for us (in this example `$PWD` is `/tmp/`):
|
||||
|
||||
```console
|
||||
```
|
||||
$ HOME=/tmp DEBUGINFOD_URLS=https://debuginfod.debian.net gdb -q gdb
|
||||
Reading symbols from gdb...
|
||||
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
|
||||
to do is set the following environment variable in your shell:
|
||||
|
||||
```bash
|
||||
```
|
||||
DEBUGINFOD_URLS="https://debuginfod.debian.net"
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -122,9 +122,8 @@ 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
|
||||
the previous step) and type:
|
||||
|
||||
```console
|
||||
> crossystem dev_boot_usb=1 dev_boot_legacy=1
|
||||
```
|
||||
#!bash
|
||||
> crossystem dev_boot_usb=1 dev_boot_legacy=1
|
||||
|
||||
And that's it!
|
||||
|
||||
|
|
@ -150,9 +149,8 @@ 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
|
||||
give you a command prompt (`boot:`), and you just need to type:
|
||||
|
||||
```console
|
||||
boot: linux mem=1980M
|
||||
```
|
||||
#!bash
|
||||
boot: linux mem=1980M
|
||||
|
||||
And that's it, things should work.
|
||||
|
||||
|
|
@ -222,18 +220,16 @@ 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
|
||||
you time, this is what I have now in my `/etc/default/grub` file:
|
||||
|
||||
```console
|
||||
GRUB_CMDLINE_LINUX="tpm_tis.force=1 tpm_tis.interrupts=0 ..."
|
||||
```
|
||||
#!bash
|
||||
GRUB_CMDLINE_LINUX="tpm_tis.force=1 tpm_tis.interrupts=0 ..."
|
||||
|
||||
The final `...` means that you should keep whatever was there before you
|
||||
included those parameters, of course. Also, after you edit this file,
|
||||
you need to regenerate the GRUB configuration file on `/boot`. Run the
|
||||
following command as `root`:
|
||||
|
||||
```console
|
||||
> grub2-mkconfig -o /boot/grub2/grub.cfg
|
||||
```
|
||||
#!bash
|
||||
> grub2-mkconfig -o /boot/grub2/grub.cfg
|
||||
|
||||
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
|
||||
|
|
@ -251,36 +247,33 @@ because the system is using the touchpad and the touchscreen to
|
|||
determine whether it should resume from suspend or not. So basically
|
||||
what you have to do is to disable those sources of events:
|
||||
|
||||
```console
|
||||
echo TPAD > /proc/acpi/wakeup
|
||||
echo TSCR > /proc/acpi/wakeup
|
||||
```
|
||||
#!bash
|
||||
echo TPAD > /proc/acpi/wakeup
|
||||
echo TSCR > /proc/acpi/wakeup
|
||||
|
||||
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
|
||||
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:
|
||||
|
||||
```console
|
||||
> cat /etc/rc.d/rc.local
|
||||
#!/bin/bash
|
||||
#!bash
|
||||
> cat /etc/rc.d/rc.local
|
||||
#!/bin/bash
|
||||
|
||||
suspend_tricks()
|
||||
{
|
||||
echo TPAD > /proc/acpi/wakeup
|
||||
echo TSCR > /proc/acpi/wakeup
|
||||
}
|
||||
suspend_tricks()
|
||||
{
|
||||
echo TPAD > /proc/acpi/wakeup
|
||||
echo TSCR > /proc/acpi/wakeup
|
||||
}
|
||||
|
||||
suspend_tricks
|
||||
suspend_tricks
|
||||
|
||||
exit 0
|
||||
```
|
||||
exit 0
|
||||
|
||||
Don't forget to make this file executable:
|
||||
|
||||
```console
|
||||
> chmod +x /etc/rc.d/rc.local
|
||||
```
|
||||
#!bash
|
||||
> chmod +x /etc/rc.d/rc.local
|
||||
|
||||
Conclusion
|
||||
----------
|
||||
|
|
|
|||
|
|
@ -30,26 +30,24 @@ systems, you can obtain this header file by installing the package
|
|||
|
||||
Here's a simple example of an application with a one-argument probe:
|
||||
|
||||
```c
|
||||
#include <sys/sdt.h>
|
||||
#!c
|
||||
#include <sys/sdt.h>
|
||||
|
||||
int
|
||||
main (int argc, char *argv[])
|
||||
{
|
||||
int a = 10;
|
||||
int
|
||||
main (int argc, char *argv[])
|
||||
{
|
||||
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
|
||||
contains one argument. You can now compile the program:
|
||||
|
||||
```console
|
||||
$ gcc test_program.c -o test_program
|
||||
```
|
||||
#!bash
|
||||
$ gcc test_program.c -o test_program
|
||||
|
||||
Now you must be thinking: "*Wait, wait... Didn't you just forget to link
|
||||
this program against some SystemTap-specific library or something?*" And
|
||||
|
|
@ -61,16 +59,15 @@ 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
|
||||
use `readelf` command:
|
||||
|
||||
```console
|
||||
$ readelf -x .note.stapsdt ./test_program
|
||||
#!bash
|
||||
$ readelf -x .note.stapsdt ./test_program
|
||||
|
||||
Hex dump of section '.note.stapsdt':
|
||||
0x00000000 08000000 3a000000 03000000 73746170 ....:.......stap
|
||||
0x00000010 73647400 86044000 00000000 88054000 sdt...@.......@.
|
||||
0x00000020 00000000 00000000 00000000 74657374 ............test
|
||||
0x00000030 5f70726f 6772616d 006d795f 70726f62 _program.my_prob
|
||||
0x00000040 65002d34 402d3428 25726270 29000000 e.-4@-4(%rbp)...
|
||||
```
|
||||
Hex dump of section '.note.stapsdt':
|
||||
0x00000000 08000000 3a000000 03000000 73746170 ....:.......stap
|
||||
0x00000010 73647400 86044000 00000000 88054000 sdt...@.......@.
|
||||
0x00000020 00000000 00000000 00000000 74657374 ............test
|
||||
0x00000030 5f70726f 6772616d 006d795f 70726f62 _program.my_prob
|
||||
0x00000040 65002d34 402d3428 25726270 29000000 e.-4@-4(%rbp)...
|
||||
|
||||
*(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
|
||||
|
|
@ -78,10 +75,9 @@ see an output from this* `readelf` *command.)*
|
|||
|
||||
You can also use SystemTap to perform this verification:
|
||||
|
||||
```console
|
||||
$ stap -L 'process("./test_program").mark("*")'
|
||||
process("./test_program").mark("my_probe") $arg1:long
|
||||
```
|
||||
#!bash
|
||||
$ stap -L 'process("./test_program").mark("*")'
|
||||
process("./test_program").mark("my_probe") $arg1:long
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -33,10 +33,9 @@ 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
|
||||
(use the `-g` flag on `GCC`), and do something like:
|
||||
|
||||
```console
|
||||
$ 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
|
||||
```
|
||||
#!bash
|
||||
$ 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
|
||||
|
||||
And that's it. You can read SystemTap's documentation, or
|
||||
[this](http://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps)
|
||||
|
|
@ -49,19 +48,18 @@ 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
|
||||
remember it:
|
||||
|
||||
```c
|
||||
#include <sys/sdt.h>
|
||||
#!c
|
||||
#include <sys/sdt.h>
|
||||
|
||||
int
|
||||
main (int argc, char *argv[])
|
||||
{
|
||||
int a = 10;
|
||||
int
|
||||
main (int argc, char *argv[])
|
||||
{
|
||||
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
|
||||
order to show more features. But for now, it will do.
|
||||
|
|
@ -70,16 +68,15 @@ 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
|
||||
example.
|
||||
|
||||
```console
|
||||
$ gdb ./test_program
|
||||
GNU gdb (GDB) 7.5.50.20121014-cvs
|
||||
Copyright (C) 2012 Free Software Foundation, Inc.
|
||||
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
|
||||
...
|
||||
(gdb) info probes
|
||||
Provider Name Where Semaphore Object
|
||||
test_program my_probe 0x00000000004004ae /home/sergio/work/src/git/build/gdb/test_program
|
||||
```
|
||||
#!bash
|
||||
$ gdb ./test_program
|
||||
GNU gdb (GDB) 7.5.50.20121014-cvs
|
||||
Copyright (C) 2012 Free Software Foundation, Inc.
|
||||
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
|
||||
...
|
||||
(gdb) info probes
|
||||
Provider Name Where Semaphore Object
|
||||
test_program my_probe 0x00000000004004ae /home/sergio/work/src/git/build/gdb/test_program
|
||||
|
||||
Wow, it actually works! :-)
|
||||
|
||||
|
|
@ -94,10 +91,9 @@ use the `SDT` support.
|
|||
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.
|
||||
|
||||
```console
|
||||
(gdb) break -probe-stap my_probe
|
||||
Breakpoint 1 at 0x4004ae
|
||||
```
|
||||
#!bash
|
||||
(gdb) break -probe-stap my_probe
|
||||
Breakpoint 1 at 0x4004ae
|
||||
|
||||
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
|
||||
|
|
@ -116,13 +112,12 @@ the one reported by `break`: they should be the same.
|
|||
Ok, so now, with our `breakpoint` in place, let's run the program and
|
||||
see what happens.
|
||||
|
||||
```console
|
||||
(gdb) run
|
||||
Starting program: /home/sergio/work/src/git/build/gdb/test_program
|
||||
#!bash
|
||||
(gdb) run
|
||||
Starting program: /home/sergio/work/src/git/build/gdb/test_program
|
||||
|
||||
Breakpoint 1, main (argc=1, argv=0x7fffffffdf68) at /tmp/example-stap.c:8
|
||||
8 STAP_PROBE1 (test_program, my_probe, a);
|
||||
```
|
||||
Breakpoint 1, main (argc=1, argv=0x7fffffffdf68) at /tmp/example-stap.c:8
|
||||
8 STAP_PROBE1 (test_program, my_probe, a);
|
||||
|
||||
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
|
||||
|
|
@ -140,12 +135,11 @@ inspect the probe's arguments? Yes, let's do it now!
|
|||
Just remember that, in `SDT`'s parlance, the current probe's argument is
|
||||
`a`. So let's print its value.
|
||||
|
||||
```console
|
||||
(gdb) p $_probe_arg0
|
||||
$1 = 10
|
||||
(gdb) p a
|
||||
$2 = 10
|
||||
```
|
||||
#!bash
|
||||
(gdb) p $_probe_arg0
|
||||
$1 = 10
|
||||
(gdb) p a
|
||||
$2 = 10
|
||||
|
||||
*"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
|
||||
example program:
|
||||
|
||||
```c
|
||||
#include <sys/sdt.h>
|
||||
#!c
|
||||
#include <sys/sdt.h>
|
||||
|
||||
int
|
||||
main (int argc, char *argv[])
|
||||
{
|
||||
int a = 10;
|
||||
int
|
||||
main (int argc, char *argv[])
|
||||
{
|
||||
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.
|
||||
|
||||
|
|
@ -94,11 +94,10 @@ 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
|
||||
you have it installed, you can do:
|
||||
|
||||
```console
|
||||
$ gdbserver :3001 ./test_program
|
||||
Process ./test_program created; pid = 17793
|
||||
Listening on port 3001
|
||||
```
|
||||
#!bash
|
||||
$ gdbserver :3001 ./test_program
|
||||
Process ./test_program created; pid = 17793
|
||||
Listening on port 3001
|
||||
|
||||
The second argument passed to `gdbserver` instructs it to listen on the
|
||||
port 3001 of your loopback interface, a.k.a. `localhost`.
|
||||
|
|
@ -110,15 +109,14 @@ 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:
|
||||
|
||||
```console
|
||||
$ gdb ./test_program
|
||||
...
|
||||
(gdb) target remote :3001
|
||||
Remote debugging using :3001
|
||||
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
|
||||
0x0000003d60401530 in _start () from /lib64/ld-linux-x86-64.so.2
|
||||
```
|
||||
#!bash
|
||||
$ gdb ./test_program
|
||||
...
|
||||
(gdb) target remote :3001
|
||||
Remote debugging using :3001
|
||||
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
|
||||
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
|
||||
an argument the host and the port to which you want to connect. In our
|
||||
|
|
@ -137,10 +135,9 @@ Ok, so now it is time to start our *trace experiment*!
|
|||
|
||||
In your `GDB` prompt, put a `tracepoint` in the probe named `my_probe`:
|
||||
|
||||
```console
|
||||
(gdb) trace -probe-stap my_probe
|
||||
Tracepoint 1 at 0x4005a9
|
||||
```
|
||||
#!bash
|
||||
(gdb) trace -probe-stap my_probe
|
||||
Tracepoint 1 at 0x4005a9
|
||||
|
||||
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
|
||||
|
|
@ -155,14 +152,13 @@ For this example, we will use only the `collect` keyword, which tells
|
|||
`GDB` to... hm... collect something :-). In our case, it will collect
|
||||
the probe's first argument, or `$_probe_arg0`, as you may remember.
|
||||
|
||||
```console
|
||||
(gdb) actions
|
||||
Enter actions for tracepoint 1, one per line.
|
||||
End with a line saying just "end".
|
||||
>collect $_probe_arg0
|
||||
>end
|
||||
(gdb)
|
||||
```
|
||||
#!bash
|
||||
(gdb) actions
|
||||
Enter actions for tracepoint 1, one per line.
|
||||
End with a line saying just "end".
|
||||
>collect $_probe_arg0
|
||||
>end
|
||||
(gdb)
|
||||
|
||||
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
|
||||
|
|
@ -178,16 +174,15 @@ 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
|
||||
continue our program normally.
|
||||
|
||||
```console
|
||||
(gdb) tstart
|
||||
(gdb) continue
|
||||
Continuing.
|
||||
#!bash
|
||||
(gdb) tstart
|
||||
(gdb) continue
|
||||
Continuing.
|
||||
|
||||
Breakpoint 1, main (argc=1, argv=0x7fffffffde88) at /tmp/test_program.c:10
|
||||
10 return 0;
|
||||
(gdb) tstop
|
||||
(gdb)
|
||||
```
|
||||
Breakpoint 1, main (argc=1, argv=0x7fffffffde88) at /tmp/test_program.c:10
|
||||
10 return 0;
|
||||
(gdb) tstop
|
||||
(gdb)
|
||||
|
||||
Remember, `GDB` is **not** going to stop your program, because
|
||||
`tracepoints` are designed to not interfere with the execution of it.
|
||||
|
|
@ -198,13 +193,12 @@ Now, we will be able to examine what the `tracepoint` has collected.
|
|||
First, we will the `tfind` command to make sure the `tracepoint` has
|
||||
hit, and then we can inspect what we ordered it to collect:
|
||||
|
||||
```console
|
||||
(gdb) tfind start
|
||||
Found trace frame 0, tracepoint 1
|
||||
8 STAP_PROBE1 (test_program, my_probe, a);
|
||||
(gdb) p $_probe_arg0
|
||||
$1 = 10
|
||||
```
|
||||
#!bash
|
||||
(gdb) tfind start
|
||||
Found trace frame 0, tracepoint 1
|
||||
8 STAP_PROBE1 (test_program, my_probe, a);
|
||||
(gdb) p $_probe_arg0
|
||||
$1 = 10
|
||||
|
||||
And it works! Notice that we are printing the probe argument using the
|
||||
same notation as with `breakpoints`, even though we are not exactly
|
||||
|
|
|
|||
|
|
@ -47,9 +47,8 @@ to always encrypt the message to myself too.
|
|||
You basically have to edit your `$HOME/.gnupg/gpg.conf` file and put
|
||||
this setting there:
|
||||
|
||||
```console
|
||||
hidden-encrypt-to ID
|
||||
```
|
||||
#!bash
|
||||
hidden-encrypt-to ID
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -66,13 +66,11 @@ 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
|
||||
and found that it started with the following commit:
|
||||
|
||||
```
|
||||
commit f6aec96dce1ddbd8961a3aa8a2925db2021719bb
|
||||
Author: H.J. Lu <hjl.tools@gmail.com>
|
||||
Date: Tue Feb 27 11:34:20 2018 -0800
|
||||
commit f6aec96dce1ddbd8961a3aa8a2925db2021719bb
|
||||
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.
|
||||
So that means this is not GDB's problem, right?!? Hmm. No,
|
||||
|
|
@ -97,79 +95,75 @@ everything (code and data) was put together in the same memory
|
|||
region. What this means in practice is that, before, you would see
|
||||
something like this when you examined `/proc/PID/smaps`:
|
||||
|
||||
```
|
||||
00400000-00401000 r-xp 00000000 fc:01 798593 /file
|
||||
Size: 4 kB
|
||||
KernelPageSize: 4 kB
|
||||
MMUPageSize: 4 kB
|
||||
Rss: 4 kB
|
||||
Pss: 4 kB
|
||||
Shared_Clean: 0 kB
|
||||
Shared_Dirty: 0 kB
|
||||
Private_Clean: 0 kB
|
||||
Private_Dirty: 4 kB
|
||||
Referenced: 4 kB
|
||||
Anonymous: 4 kB
|
||||
LazyFree: 0 kB
|
||||
AnonHugePages: 0 kB
|
||||
ShmemPmdMapped: 0 kB
|
||||
Shared_Hugetlb: 0 kB
|
||||
Private_Hugetlb: 0 kB
|
||||
Swap: 0 kB
|
||||
SwapPss: 0 kB
|
||||
Locked: 0 kB
|
||||
THPeligible: 0
|
||||
VmFlags: rd ex mr mw me dw sd
|
||||
```
|
||||
00400000-00401000 r-xp 00000000 fc:01 798593 /file
|
||||
Size: 4 kB
|
||||
KernelPageSize: 4 kB
|
||||
MMUPageSize: 4 kB
|
||||
Rss: 4 kB
|
||||
Pss: 4 kB
|
||||
Shared_Clean: 0 kB
|
||||
Shared_Dirty: 0 kB
|
||||
Private_Clean: 0 kB
|
||||
Private_Dirty: 4 kB
|
||||
Referenced: 4 kB
|
||||
Anonymous: 4 kB
|
||||
LazyFree: 0 kB
|
||||
AnonHugePages: 0 kB
|
||||
ShmemPmdMapped: 0 kB
|
||||
Shared_Hugetlb: 0 kB
|
||||
Private_Hugetlb: 0 kB
|
||||
Swap: 0 kB
|
||||
SwapPss: 0 kB
|
||||
Locked: 0 kB
|
||||
THPeligible: 0
|
||||
VmFlags: rd ex mr mw me dw sd
|
||||
|
||||
And now, you will see two memory regions instead, like this:
|
||||
|
||||
```
|
||||
00400000-00401000 r--p 00000000 fc:01 799548 /file
|
||||
Size: 4 kB
|
||||
KernelPageSize: 4 kB
|
||||
MMUPageSize: 4 kB
|
||||
Rss: 4 kB
|
||||
Pss: 4 kB
|
||||
Shared_Clean: 0 kB
|
||||
Shared_Dirty: 0 kB
|
||||
Private_Clean: 4 kB
|
||||
Private_Dirty: 0 kB
|
||||
Referenced: 4 kB
|
||||
Anonymous: 0 kB
|
||||
LazyFree: 0 kB
|
||||
AnonHugePages: 0 kB
|
||||
ShmemPmdMapped: 0 kB
|
||||
Shared_Hugetlb: 0 kB
|
||||
Private_Hugetlb: 0 kB
|
||||
Swap: 0 kB
|
||||
SwapPss: 0 kB
|
||||
Locked: 0 kB
|
||||
THPeligible: 0
|
||||
VmFlags: rd mr mw me dw sd
|
||||
00401000-00402000 r-xp 00001000 fc:01 799548 /file
|
||||
Size: 4 kB
|
||||
KernelPageSize: 4 kB
|
||||
MMUPageSize: 4 kB
|
||||
Rss: 4 kB
|
||||
Pss: 4 kB
|
||||
Shared_Clean: 0 kB
|
||||
Shared_Dirty: 0 kB
|
||||
Private_Clean: 0 kB
|
||||
Private_Dirty: 4 kB
|
||||
Referenced: 4 kB
|
||||
Anonymous: 4 kB
|
||||
LazyFree: 0 kB
|
||||
AnonHugePages: 0 kB
|
||||
ShmemPmdMapped: 0 kB
|
||||
Shared_Hugetlb: 0 kB
|
||||
Private_Hugetlb: 0 kB
|
||||
Swap: 0 kB
|
||||
SwapPss: 0 kB
|
||||
Locked: 0 kB
|
||||
THPeligible: 0
|
||||
VmFlags: rd ex mr mw me dw sd
|
||||
```
|
||||
00400000-00401000 r--p 00000000 fc:01 799548 /file
|
||||
Size: 4 kB
|
||||
KernelPageSize: 4 kB
|
||||
MMUPageSize: 4 kB
|
||||
Rss: 4 kB
|
||||
Pss: 4 kB
|
||||
Shared_Clean: 0 kB
|
||||
Shared_Dirty: 0 kB
|
||||
Private_Clean: 4 kB
|
||||
Private_Dirty: 0 kB
|
||||
Referenced: 4 kB
|
||||
Anonymous: 0 kB
|
||||
LazyFree: 0 kB
|
||||
AnonHugePages: 0 kB
|
||||
ShmemPmdMapped: 0 kB
|
||||
Shared_Hugetlb: 0 kB
|
||||
Private_Hugetlb: 0 kB
|
||||
Swap: 0 kB
|
||||
SwapPss: 0 kB
|
||||
Locked: 0 kB
|
||||
THPeligible: 0
|
||||
VmFlags: rd mr mw me dw sd
|
||||
00401000-00402000 r-xp 00001000 fc:01 799548 /file
|
||||
Size: 4 kB
|
||||
KernelPageSize: 4 kB
|
||||
MMUPageSize: 4 kB
|
||||
Rss: 4 kB
|
||||
Pss: 4 kB
|
||||
Shared_Clean: 0 kB
|
||||
Shared_Dirty: 0 kB
|
||||
Private_Clean: 0 kB
|
||||
Private_Dirty: 4 kB
|
||||
Referenced: 4 kB
|
||||
Anonymous: 4 kB
|
||||
LazyFree: 0 kB
|
||||
AnonHugePages: 0 kB
|
||||
ShmemPmdMapped: 0 kB
|
||||
Shared_Hugetlb: 0 kB
|
||||
Private_Hugetlb: 0 kB
|
||||
Swap: 0 kB
|
||||
SwapPss: 0 kB
|
||||
Locked: 0 kB
|
||||
THPeligible: 0
|
||||
VmFlags: rd ex mr mw me dw sd
|
||||
|
||||
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
|
||||
|
|
@ -246,8 +240,9 @@ Linux also makes these checks, by the way.
|
|||
The patch, finally
|
||||
------------------
|
||||
|
||||
I submitted [the
|
||||
patch](https://sourceware.org/ml/gdb-patches/2019-04/msg00479.html) to
|
||||
I
|
||||
submitted
|
||||
[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
|
||||
nits).
|
||||
|
||||
|
|
@ -258,7 +253,8 @@ 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,
|
||||
as well as the one reported against Fedora GDB.
|
||||
|
||||
The patch has been
|
||||
The patch has
|
||||
been
|
||||
[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.
|
||||
It wasn't possible to write a self-contained testcase for this
|
||||
|
|
|
|||
|
|
@ -180,12 +180,10 @@ 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
|
||||
`etc/gerrit.config`:
|
||||
|
||||
```ini
|
||||
[container]
|
||||
...
|
||||
javaOptions = "--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED"
|
||||
...
|
||||
```
|
||||
[container]
|
||||
...
|
||||
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
|
||||
set it up for OAuth2 authentication using Keycloak. This took a
|
||||
|
|
@ -200,54 +198,52 @@ causing a very strange error on Gerrit (as you can see, a
|
|||
`java.lang.StringIndexOutOfBoundsException`!), which didn't make
|
||||
sense. In the end, my Apache config file looks like this:
|
||||
|
||||
```apacheconf
|
||||
<VirtualHost *:80>
|
||||
ServerName gnutoolchain-gerrit.osci.io
|
||||
<VirtualHost *:80>
|
||||
ServerName gnutoolchain-gerrit.osci.io
|
||||
|
||||
RedirectPermanent / https://gnutoolchain-gerrit.osci.io/r/
|
||||
</VirtualHost>
|
||||
RedirectPermanent / https://gnutoolchain-gerrit.osci.io/r/
|
||||
</VirtualHost>
|
||||
|
||||
<VirtualHost *:443>
|
||||
ServerName gnutoolchain-gerrit.osci.io
|
||||
<VirtualHost *:443>
|
||||
ServerName gnutoolchain-gerrit.osci.io
|
||||
|
||||
RedirectPermanent / /r/
|
||||
RedirectPermanent / /r/
|
||||
|
||||
SSLEngine On
|
||||
SSLCertificateFile /path/to/cert.pem
|
||||
SSLCertificateKeyFile /path/to/privkey.pem
|
||||
SSLCertificateChainFile /path/to/chain.pem
|
||||
SSLEngine On
|
||||
SSLCertificateFile /path/to/cert.pem
|
||||
SSLCertificateKeyFile /path/to/privkey.pem
|
||||
SSLCertificateChainFile /path/to/chain.pem
|
||||
|
||||
# Good practices for SSL
|
||||
# taken from: <https://mozilla.github.io/server-side-tls/ssl-config-generator/>
|
||||
# Good practices for SSL
|
||||
# taken from: <https://mozilla.github.io/server-side-tls/ssl-config-generator/>
|
||||
|
||||
# intermediate configuration, tweak to your needs
|
||||
SSLProtocol all -SSLv3
|
||||
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
|
||||
SSLHonorCipherOrder on
|
||||
SSLCompression off
|
||||
SSLSessionTickets off
|
||||
# intermediate configuration, tweak to your needs
|
||||
SSLProtocol all -SSLv3
|
||||
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
|
||||
SSLHonorCipherOrder on
|
||||
SSLCompression off
|
||||
SSLSessionTickets off
|
||||
|
||||
# OCSP Stapling, only in httpd 2.3.3 and later
|
||||
#SSLUseStapling on
|
||||
#SSLStaplingResponderTimeout 5
|
||||
#SSLStaplingReturnResponderErrors off
|
||||
#SSLStaplingCache shmcb:/var/run/ocsp(128000)
|
||||
# OCSP Stapling, only in httpd 2.3.3 and later
|
||||
#SSLUseStapling on
|
||||
#SSLStaplingResponderTimeout 5
|
||||
#SSLStaplingReturnResponderErrors off
|
||||
#SSLStaplingCache shmcb:/var/run/ocsp(128000)
|
||||
|
||||
# HSTS (mod_headers is required) (15768000 seconds = 6 months)
|
||||
Header always set Strict-Transport-Security "max-age=15768000"
|
||||
# HSTS (mod_headers is required) (15768000 seconds = 6 months)
|
||||
Header always set Strict-Transport-Security "max-age=15768000"
|
||||
|
||||
ProxyRequests Off
|
||||
ProxyVia Off
|
||||
ProxyPreserveHost On
|
||||
<Proxy *>
|
||||
Require all granted
|
||||
</Proxy>
|
||||
ProxyRequests Off
|
||||
ProxyVia Off
|
||||
ProxyPreserveHost On
|
||||
<Proxy *>
|
||||
Require all granted
|
||||
</Proxy>
|
||||
|
||||
AllowEncodedSlashes On
|
||||
ProxyPass /r/ http://127.0.0.1:8081/ nocanon
|
||||
#ProxyPassReverse /r/ http://127.0.0.1:8081/r/
|
||||
</VirtualHost>
|
||||
```
|
||||
AllowEncodedSlashes On
|
||||
ProxyPass /r/ http://127.0.0.1:8081/ nocanon
|
||||
#ProxyPassReverse /r/ http://127.0.0.1:8081/r/
|
||||
</VirtualHost>
|
||||
|
||||
I confess I was almost giving up Keycloak when I finally found
|
||||
the problem...
|
||||
|
|
@ -263,12 +259,10 @@ gerrit that the user was already logged in, and gerrit would
|
|||
automatically log the user in again! I was able to solve this by
|
||||
redirecting the user to Keycloak's logout page, like this:
|
||||
|
||||
```ini
|
||||
[auth]
|
||||
...
|
||||
logoutUrl = https://keycloak-url:port/auth/realms/REALM/protocol/openid-connect/logout?redirect_uri=https://gerrit-url/
|
||||
...
|
||||
```
|
||||
[auth]
|
||||
...
|
||||
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
|
||||
gerrit itself. I don't know if I'll write a post about that, but let
|
||||
|
|
|
|||
|
|
@ -156,11 +156,10 @@ 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
|
||||
source code in order to provide the database name/file):
|
||||
|
||||
```console
|
||||
$> perl j2to1.pl jabberd14-dir/
|
||||
Converting user@host...
|
||||
$>
|
||||
```
|
||||
#!bash
|
||||
$> perl j2to1.pl jabberd14-dir/
|
||||
Converting user@host...
|
||||
$>
|
||||
|
||||
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/`.
|
||||
|
|
@ -172,9 +171,8 @@ 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
|
||||
XEP-0227 XML file that will be imported into Prosody.
|
||||
|
||||
```console
|
||||
$> ./sleekmigrate.py -j /path/to/jabberd14-dir/
|
||||
```
|
||||
#!bash
|
||||
$> ./sleekmigrate.py -j /path/to/jabberd14-dir/
|
||||
|
||||
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
|
||||
|
|
@ -196,17 +194,15 @@ 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
|
||||
Prosody source code directory, and do:
|
||||
|
||||
```console
|
||||
$> apt-get build-dep prosody && ./configure --ostype=debian && make
|
||||
```
|
||||
#!bash
|
||||
$> apt-get build-dep prosody && ./configure --ostype=debian && make
|
||||
|
||||
Only after I did that I could finally run the conversion script
|
||||
successfully. The script is locate inside the `tools/` directory. To run
|
||||
it:
|
||||
|
||||
```console
|
||||
$> cd tools && lua ./xep227toprosody.lua /path/to/227.xml
|
||||
```
|
||||
#!bash
|
||||
$> cd tools && lua ./xep227toprosody.lua /path/to/227.xml
|
||||
|
||||
And yay! I **finally** had everything imported into Prosody!!!! Then it
|
||||
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
|
||||
the first endpoint. Something like the following should do:
|
||||
|
||||
```ini
|
||||
```nil
|
||||
[Interface]
|
||||
PrivateKey = PRIVATE_KEY_HERE
|
||||
Address = 10.0.0.1/32
|
||||
|
|
@ -73,7 +73,7 @@ A few interesting points to note:
|
|||
|
||||
At your home, you will configure the peer:
|
||||
|
||||
```ini
|
||||
```nil
|
||||
[Interface]
|
||||
PrivateKey = PRIVATE_KEY_HERE
|
||||
Address = 10.0.0.2/32
|
||||
|
|
|
|||
Loading…
Reference in a new issue