Fix code highlighting on all posts

This commit is contained in:
Sergio Durigan Junior 2024-02-25 16:07:05 -05:00
parent 0171106eee
commit cb2a0bcfff
10 changed files with 299 additions and 261 deletions

View file

@ -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"
``` ```

View file

@ -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
---------- ----------

View file

@ -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

View file

@ -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!"*

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -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