./run --debug-vm: pass GDB arguments to the option on the CLI.

readme: remote g packet reply is too long

Benchmark gem5 single file rebuild

README.adoc

@@ -1835,6 +1835,18 @@ For when it breaks again, or you want to add a new feature!
 
 See also: https://stackoverflow.com/questions/13496389/gdb-remote-protocol-how-to-analyse-packets
 
+==== Remote 'g' packet reply is too long
+
+This error means that the GDB server, e.g. in QEMU, sent more registers than the GDB client expected.
+
+This can happen for the following reasons:
+
+* you set the architecture of the client wrong, often 32 vs 64 bit as mentioned at: https://stackoverflow.com/questions/4896316/gdb-remote-cross-debugging-fails-with-remote-g-packet-reply-is-too-long
+* there is a bug in the GDB server and the XML description does not match the number of registers actually sent
+* the GDB server does not send XML target descriptions and your GDB expects a different number of registers by default. E.g., gem5 d4b3e064adeeace3c3e7d106801f95c14637c12f does not send the XML files
+
+The XML target description format is described a bit further at: https://stackoverflow.com/questions/46415059/how-to-observe-aarch64-system-registers-in-qemu/53043044#53043044
+
 == KGDB
 
 KGDB is kernel dark magic that allows you to GDB the kernel on real hardware without any extra hardware support.
@@ -8046,7 +8058,7 @@ Then you could:
 
 ....
 break edu_mmio_read
-continue
+run
 ....
 
 And in QEMU:
@@ -8055,6 +8067,12 @@ And in QEMU:
 /qemu_edu.sh
 ....
 
+Or for a faster development loop:
+
+....
+./run --debug-vm='-ex "break edu_mmio_read" -ex "run"'
+....
+
 When in <<qemu-text-mode>>, using `--debug-vm` makes Ctrl-C not get passed to the QEMU guest anymore: it is instead captured by GDB itself, so allow breaking. So e.g. you won't be able to easily quit from a guest program like:
 
 ....
@@ -10606,6 +10624,33 @@ Get results with:
 tail -n+1 ../linux-kernel-module-cheat-regression/*/gem5-bench-build-*.txt
 ....
 
+====== Benchmark gem5 single file change rebuild time
+
+This is the critical development parameter, and is dominated by the link time of huge binaries.
+
+In order to benchmark it better, do a run with:
+
+....
+./build-gem5 -v
+....
+
+and then copy the link command to a separate Bash file. Then you can time and modify it easily.
+
+Some approximate refrence values on P51:
+
+* `opt`
+** unmodified: 15 seconds
+** hack with `-fwith-ld=gold`: 7.5 seconds. Huge improvement!
+* `debug`
+** unmodified: 30 seconds. Why two times slower than unmodified?
+** hack with `-fwith-ld=gold`: `internal error in read_cie, at ../../gold/ehframe.cc:919` on Ubuntu 18.04 all GCC. TODO report.
+* `fast`
+** `--force-lto`: 1 minute. Slower as expected, since more optimizations are done at link time. `--force-lto` is only used for `fast`, and it adds `-flto` to the build.
+
+ramfs made no difference, the kernel must be caching files in memory very efficiently already.
+
+Tested at: d4b3e064adeeace3c3e7d106801f95c14637c12f + 1.
+
 === Benchmark machines
 
 ==== P51

run

@@ -13,7 +13,7 @@ import common
 defaults = {
     'cpus': 1,
     'debug_guest': False,
-    'debug_vm': False,
+    'debug_vm': None,
     'eval': None,
     'extra_emulator_args': [],
     'gem5_exe_args': '',
@@ -54,8 +54,9 @@ def main(args, extra_args=None):
     kernel_cli_after_dash = ''
     extra_emulator_args = []
     extra_qemu_args = []
-    if args.debug_vm:
-        debug_vm = ['gdb', '-q', '-ex', 'start', '--args']
+    if args.debug_vm is not None:
+        print(args.debug_vm)
+        debug_vm = ['gdb', '-q'] + shlex.split(args.debug_vm) + ['--args']
     else:
         debug_vm = []
     if args.debug_guest:
@@ -398,7 +399,7 @@ def get_argparse():
         help='Number of guest CPUs to emulate. Default: %(default)s'
     )
     parser.add_argument(
-        '-D', '--debug-vm', default=defaults['debug_vm'], action='store_true',
+        '-D', '--debug-vm', default=defaults['debug_vm'], nargs='?', action='store', const='',
         help='Run GDB on the emulator itself.'
     )
     kvm_group.add_argument(