Simplify debugging initialization, and allow vscode (Native Debug extension) to use .gdbinit.

.vscode/launch.json

@@ -0,0 +1,13 @@
+{
+    "configurations": [
+        {
+            "type": "gdb",
+            "request": "attach",
+            "name": "(gdb) Attach",
+            "target": "localhost:1234",
+            "remote": true,
+            "cwd": "${workspaceRoot}/build",
+            "valuesFormatting": "parseText"
+        }
+    ]
+}

CMakeLists.txt

@@ -147,14 +147,16 @@ add_custom_target(
 # executables.
 add_custom_target(
     gdbinit
-    BYPRODUCTS ${CMAKE_BINARY_DIR}/.gdbinit
+    BYPRODUCTS ${CMAKE_BINARY_DIR}/.gdbinit ${CMAKE_BINARY_DIR}/gdb.run
+    # Create the generic gdb configuration.
     COMMAND echo "add-symbol-file ${CMAKE_BINARY_DIR}/mentos/kernel.bin" > ${CMAKE_BINARY_DIR}/.gdbinit
     COMMAND echo "add-symbol-file ${CMAKE_BINARY_DIR}/mentos/kernel-bootloader.bin" >> ${CMAKE_BINARY_DIR}/.gdbinit
     COMMAND ls -1 ${CMAKE_BINARY_DIR}/programs/tests/test_* | sed 's/^/add-symbol-file /' >> ${CMAKE_BINARY_DIR}/.gdbinit
     COMMAND ls -1 ${CMAKE_BINARY_DIR}/programs/prog_* | sed 's/^/add-symbol-file /' >> ${CMAKE_BINARY_DIR}/.gdbinit
-    # COMMAND echo "break boot.c: boot_main" >> ${CMAKE_BINARY_DIR}/.gdbinit
+    COMMAND echo "break boot.c: boot_main" >> ${CMAKE_BINARY_DIR}/.gdbinit
-    # COMMAND echo "break kernel.c: kmain" >> ${CMAKE_BINARY_DIR}/.gdbinit
+    COMMAND echo "break kernel.c: kmain" >> ${CMAKE_BINARY_DIR}/.gdbinit
-    COMMAND echo "target remote localhost:1234" >> ${CMAKE_BINARY_DIR}/.gdbinit
+    # Create the GDB connection file.
+    COMMAND echo "target remote localhost:1234" >> ${CMAKE_BINARY_DIR}/gdb.run
     DEPENDS kernel-bootloader.bin
     DEPENDS all_programs
     DEPENDS all_tests
@@ -170,8 +172,10 @@ add_custom_target(
     COMMAND echo ""
     COMMAND echo "Now, QEMU has loaded the kernel, and it is waiting that you"
     COMMAND echo "remotely connect to it. To start debugging, open a new shell"
-    COMMAND echo "in THIS same folder, and just type :"
+    COMMAND echo "in THIS same folder, and just type:"
-    COMMAND printf "    cgdb -q -iex %q" "add-auto-load-safe-path ."
+    COMMAND echo "    gdb --quiet --command=gdb.run"
+    COMMAND echo "or if you want to use cgdb, type:"
+    COMMAND echo "    cgdb --quiet --command=gdb.run"
     COMMAND echo ""
     COMMAND ${EMULATOR} ${EMULATOR_FLAGS} -s -S -kernel ${CMAKE_BINARY_DIR}/mentos/kernel-bootloader.bin
     DEPENDS kernel-bootloader.bin

README.md

@@ -352,7 +352,11 @@ make qemu-gdb
 
 If you did everything correctly, you should see an empty QEMU window. Basically, QEMU is waiting for you to connect *remotely* with gdb. Anyway, running `make qemu-gdb` will make your current shell busy, you cannot call `gdb` in it. You need to open a new shell inside the `build` folder and do a:
 ```bash
-cgdb -q -iex 'add-auto-load-safe-path .'
+gdb --quiet --command=gdb.run
+```
+or
+```bash
+cgdb --quiet --command=gdb.run
 ```
 
 Now you should have in front of you:
@@ -381,6 +385,9 @@ Breakpoint 2, kmain (...) at .../mentos/src/kernel.c:95
 95      {
 ```
 
+There is also a launch configuration for vscode in `.vscode/launch.json`, called `(gdb) Attach`, which should allow you
+to connect to the running process.
+
 *[Back to the Table of Contents](#table-of-contents)*
 
 ## 11. Contributors