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
|
||||
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,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
|
||||
the previous step) and type:
|
||||
|
||||
#!bash
|
||||
> crossystem dev_boot_usb=1 dev_boot_legacy=1
|
||||
```console
|
||||
> crossystem dev_boot_usb=1 dev_boot_legacy=1
|
||||
```
|
||||
|
||||
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
|
||||
give you a command prompt (`boot:`), and you just need to type:
|
||||
|
||||
#!bash
|
||||
boot: linux mem=1980M
|
||||
```console
|
||||
boot: linux mem=1980M
|
||||
```
|
||||
|
||||
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
|
||||
you time, this is what I have now in my `/etc/default/grub` file:
|
||||
|
||||
#!bash
|
||||
GRUB_CMDLINE_LINUX="tpm_tis.force=1 tpm_tis.interrupts=0 ..."
|
||||
```console
|
||||
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`:
|
||||
|
||||
#!bash
|
||||
> grub2-mkconfig -o /boot/grub2/grub.cfg
|
||||
```console
|
||||
> 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
|
||||
|
|
@ -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
|
||||
what you have to do is to disable those sources of events:
|
||||
|
||||
#!bash
|
||||
echo TPAD > /proc/acpi/wakeup
|
||||
echo TSCR > /proc/acpi/wakeup
|
||||
```console
|
||||
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:
|
||||
|
||||
#!bash
|
||||
> cat /etc/rc.d/rc.local
|
||||
#!/bin/bash
|
||||
```console
|
||||
> cat /etc/rc.d/rc.local
|
||||
#!/bin/bash
|
||||
|
||||
suspend_tricks()
|
||||
{
|
||||
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:
|
||||
|
||||
#!bash
|
||||
> chmod +x /etc/rc.d/rc.local
|
||||
```console
|
||||
> chmod +x /etc/rc.d/rc.local
|
||||
```
|
||||
|
||||
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:
|
||||
|
||||
#!c
|
||||
#include <sys/sdt.h>
|
||||
```c
|
||||
#include <sys/sdt.h>
|
||||
|
||||
int
|
||||
main (int argc, char *argv[])
|
||||
{
|
||||
int
|
||||
main (int argc, char *argv[])
|
||||
{
|
||||
int a = 10;
|
||||
|
||||
STAP_PROBE1 (test_program, my_probe, a);
|
||||
|
||||
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:
|
||||
|
||||
#!bash
|
||||
$ gcc test_program.c -o test_program
|
||||
```console
|
||||
$ 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
|
||||
|
|
@ -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
|
||||
use `readelf` command:
|
||||
|
||||
#!bash
|
||||
$ readelf -x .note.stapsdt ./test_program
|
||||
```console
|
||||
$ readelf -x .note.stapsdt ./test_program
|
||||
|
||||
Hex dump of section '.note.stapsdt':
|
||||
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
|
||||
|
|
@ -75,9 +78,10 @@ see an output from this* `readelf` *command.)*
|
|||
|
||||
You can also use SystemTap to perform this verification:
|
||||
|
||||
#!bash
|
||||
$ stap -L 'process("./test_program").mark("*")'
|
||||
process("./test_program").mark("my_probe") $arg1:long
|
||||
```console
|
||||
$ 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,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
|
||||
(use the `-g` flag on `GCC`), and do something like:
|
||||
|
||||
#!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
|
||||
```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
|
||||
```
|
||||
|
||||
And that's it. You can read SystemTap's documentation, or
|
||||
[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
|
||||
remember it:
|
||||
|
||||
#!c
|
||||
#include <sys/sdt.h>
|
||||
```c
|
||||
#include <sys/sdt.h>
|
||||
|
||||
int
|
||||
main (int argc, char *argv[])
|
||||
{
|
||||
int
|
||||
main (int argc, char *argv[])
|
||||
{
|
||||
int a = 10;
|
||||
|
||||
STAP_PROBE1 (test_program, my_probe, a);
|
||||
|
||||
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.
|
||||
|
|
@ -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
|
||||
example.
|
||||
|
||||
#!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
|
||||
```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
|
||||
```
|
||||
|
||||
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
|
||||
want to show you is how to put a breakpoint in a probe.
|
||||
|
||||
#!bash
|
||||
(gdb) break -probe-stap my_probe
|
||||
Breakpoint 1 at 0x4004ae
|
||||
```console
|
||||
(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
|
||||
|
|
@ -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
|
||||
see what happens.
|
||||
|
||||
#!bash
|
||||
(gdb) run
|
||||
Starting program: /home/sergio/work/src/git/build/gdb/test_program
|
||||
```console
|
||||
(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
|
||||
|
|
@ -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
|
||||
`a`. So let's print its value.
|
||||
|
||||
#!bash
|
||||
(gdb) p $_probe_arg0
|
||||
$1 = 10
|
||||
(gdb) p a
|
||||
$2 = 10
|
||||
```console
|
||||
(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
|
||||
main (int argc, char *argv[])
|
||||
{
|
||||
int a = 10;
|
||||
|
||||
STAP_PROBE1 (test_program, my_probe, a);
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
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
|
||||
you have it installed, you can do:
|
||||
|
||||
#!bash
|
||||
$ gdbserver :3001 ./test_program
|
||||
Process ./test_program created; pid = 17793
|
||||
Listening on port 3001
|
||||
```console
|
||||
$ 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`.
|
||||
|
|
@ -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:
|
||||
|
||||
#!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
|
||||
```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
|
||||
```
|
||||
|
||||
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
|
||||
|
|
@ -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`:
|
||||
|
||||
#!bash
|
||||
(gdb) trace -probe-stap my_probe
|
||||
Tracepoint 1 at 0x4005a9
|
||||
```console
|
||||
(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
|
||||
|
|
@ -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
|
||||
the probe's first argument, or `$_probe_arg0`, as you may remember.
|
||||
|
||||
#!bash
|
||||
(gdb) actions
|
||||
Enter actions for tracepoint 1, one per line.
|
||||
End with a line saying just "end".
|
||||
>collect $_probe_arg0
|
||||
>end
|
||||
(gdb)
|
||||
```console
|
||||
(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
|
||||
|
|
@ -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
|
||||
continue our program normally.
|
||||
|
||||
#!bash
|
||||
(gdb) tstart
|
||||
(gdb) continue
|
||||
Continuing.
|
||||
```console
|
||||
(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.
|
||||
|
|
@ -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
|
||||
hit, and then we can inspect what we ordered it to collect:
|
||||
|
||||
#!bash
|
||||
(gdb) tfind start
|
||||
Found trace frame 0, tracepoint 1
|
||||
8 STAP_PROBE1 (test_program, my_probe, a);
|
||||
(gdb) p $_probe_arg0
|
||||
$1 = 10
|
||||
```console
|
||||
(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,8 +47,9 @@ to always encrypt the message to myself too.
|
|||
You basically have to edit your `$HOME/.gnupg/gpg.conf` file and put
|
||||
this setting there:
|
||||
|
||||
#!bash
|
||||
hidden-encrypt-to ID
|
||||
```console
|
||||
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,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
|
||||
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
|
||||
```
|
||||
|
||||
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,
|
||||
|
|
@ -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
|
||||
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
|
||||
|
|
@ -240,9 +246,8 @@ 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).
|
||||
|
||||
|
|
@ -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,
|
||||
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,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
|
||||
`etc/gerrit.config`:
|
||||
|
||||
[container]
|
||||
```ini
|
||||
[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
|
||||
|
|
@ -198,13 +200,14 @@ 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:
|
||||
|
||||
<VirtualHost *:80>
|
||||
```apacheconf
|
||||
<VirtualHost *:80>
|
||||
ServerName gnutoolchain-gerrit.osci.io
|
||||
|
||||
RedirectPermanent / https://gnutoolchain-gerrit.osci.io/r/
|
||||
</VirtualHost>
|
||||
</VirtualHost>
|
||||
|
||||
<VirtualHost *:443>
|
||||
<VirtualHost *:443>
|
||||
ServerName gnutoolchain-gerrit.osci.io
|
||||
|
||||
RedirectPermanent / /r/
|
||||
|
|
@ -243,7 +246,8 @@ sense. In the end, my Apache config file looks like this:
|
|||
AllowEncodedSlashes On
|
||||
ProxyPass /r/ http://127.0.0.1:8081/ nocanon
|
||||
#ProxyPassReverse /r/ http://127.0.0.1:8081/r/
|
||||
</VirtualHost>
|
||||
</VirtualHost>
|
||||
```
|
||||
|
||||
I confess I was almost giving up Keycloak when I finally found
|
||||
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
|
||||
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/
|
||||
...
|
||||
```
|
||||
|
||||
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,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
|
||||
source code in order to provide the database name/file):
|
||||
|
||||
#!bash
|
||||
$> perl j2to1.pl jabberd14-dir/
|
||||
Converting user@host...
|
||||
$>
|
||||
```console
|
||||
$> 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/`.
|
||||
|
|
@ -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
|
||||
XEP-0227 XML file that will be imported into Prosody.
|
||||
|
||||
#!bash
|
||||
$> ./sleekmigrate.py -j /path/to/jabberd14-dir/
|
||||
```console
|
||||
$> ./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
|
||||
|
|
@ -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
|
||||
Prosody source code directory, and do:
|
||||
|
||||
#!bash
|
||||
$> apt-get build-dep prosody && ./configure --ostype=debian && make
|
||||
```console
|
||||
$> 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:
|
||||
|
||||
#!bash
|
||||
$> cd tools && lua ./xep227toprosody.lua /path/to/227.xml
|
||||
```console
|
||||
$> 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:
|
||||
|
||||
```nil
|
||||
```ini
|
||||
[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:
|
||||
|
||||
```nil
|
||||
```ini
|
||||
[Interface]
|
||||
PrivateKey = PRIVATE_KEY_HERE
|
||||
Address = 10.0.0.2/32
|
||||
|
|
|
|||
Loading…
Reference in a new issue