readme: underscore to - on all title ids

README.adoc

@@ -108,7 +108,7 @@ If you don't want to wait, you could also try the following faster but much more
 
 but you will soon find that they are simply not enough if you anywhere near serious about systems programming.
 
-After `./run`, QEMU opens up leaving you in the <<lkmc_home,`/lkmc/` directory>>, and you can start playing with the kernel modules inside the simulated system:
+After `./run`, QEMU opens up leaving you in the <<lkmc-home,`/lkmc/` directory>>, and you can start playing with the kernel modules inside the simulated system:
 
 ....
 insmod hello.ko
@@ -5965,7 +5965,7 @@ and so it is Read Only as shown by `ro`.
 
 ==== norandmaps
 
-Disable userland address space randomization. Test it out by running <<rand_check-out>> twice:
+Disable userland address space randomization. Test it out by running <<rand-check-out>> twice:
 
 ....
 ./run --eval-after './linux/rand_check.out;./linux/poweroff.out'
@@ -10828,7 +10828,7 @@ A convenient shortcut to do both at once to test the feature is:
 By comparing the terminal output of both runs, we can see that they are the exact same, including things which normally differ across runs:
 
 * timestamps of dmesg output
-* <<rand_check-out>> output
+* <<rand-check-out>> output
 
 The record and replay feature was revived around QEMU v3.0.0. It existed earlier but it rot completely. As of v3.0.0 it is still flaky: sometimes we get deadlocks, and only a limited number of command line arguments are supported.
 
@@ -13687,6 +13687,7 @@ Certain features may not work in Ruby. For example, <<gem5-checkpoint>> creation
 
 Tested in gem5 d7d9bc240615625141cd6feddbadd392457e49eb.
 
+[[gem5-ruby-mi-example-protocol]]
 ===== gem5 Ruby MI_example protocol
 
 This is the simplest of all protocols, and therefore the first one you should study to learn how Ruby works.
@@ -22299,6 +22300,7 @@ A summary of results is shown at: xref:table-linux-calling-conventions[xrefstyle
 
 |===
 
+[[x86-64-calling-convention]]
 ==== x86_64 calling convention
 
 Examples:
@@ -26423,6 +26425,7 @@ The cycle count is higher for `arm`, 350M vs 250M for `aarch64`, not nowhere nea
 
 A quick look at the boot logs show that they are basically identical in structure: the same operations appear more ore less on both, and there isn't one specific huge time pit in arm: it is just that every individual operation seems to be taking a lot longer.
 
+[[gem5-x86-64-derivo3cpu-boot-panics]]
 ===== gem5 x86_64 DerivO3CPU boot panics
 
 https://github.com/cirosantilli2/gem5-issues/issues/2
@@ -28588,6 +28591,7 @@ ls /mnt/9p/rootfs_overlay
 
 This way you can just hack away the scripts and try them out immediately without any further operations.
 
+[[out-rootfs-overlay-dir]]
 ===== out_rootfs_overlay_dir
 
 This path can be found with:
@@ -28624,6 +28628,7 @@ Those files also contain arch specific helpers under ifdefs like:
 
 We try to keep as much as possible in those files. It bloats builds a little, but just makes everything simpler to understand.
 
+[[lkmc-home]]
 ==== lkmc_home
 
 `lkmc_home` refers to the target base directory in which we put all our custom built stuff, such as <<userland-setup,userland executables>> and <<your-first-kernel-module-hack,kernel modules>>.
@@ -28693,6 +28698,7 @@ arm_sve=False
 baremetal=True
 ....
 
+[[rand-check-out]]
 ==== rand_check.out
 
 Print out several parameters that normally change randomly from boot to boot: