Debug

Available options

The course is teaching you how to debug with Eclipse only... The only nice thing about Eclipse is its advanced debug features. VSCode on the contrary is more limited but could be enough for most cases.

We don't know the exact difference between Eclipse and VSCode, it seems impossible to manually change the value of a CPU register in VSCode. Variable can be changed though. If some limitations are too annoying, come back to Eclipse.

You can also try to use gdb commands directly, but this is a bit hardcore mode...

By default, starting a debug session is a pain and require at least 4 manuals steps!

In the following sections, we'll describe the 3 options, starting with the one we recommend the most. For most students, we recommend using VSCode but trying Eclipse at least once to serve as a backup solution for VSCode limitations.

VSCode in just one shortcut

Note: this only concerns debugging .bin files in Qemu... This doesn't support C debugging when running binaries natively (such as exo1.c in first lab).

vscode-debug-demo.png

  1. At the start of the lab, run asm vscode to detect the .bin files and generate debug configurations

  2. Build your code if you made changes: asm make

  3. Put a breakpoint somewhere in your code.

  4. Go in the Debug panel of VSCode and choose the appropriate debug configuration

  5. Run this configuration (or just press F5), wait 7s, when the activity bar at the bottom turns colored, the go 0x... should happen just after that the code should stop at your breakpoint.

  6. If you see this message, you can check the box and click Debug anyway, it will not show again. This is a known issue we couldn't fix.

  7. The program output is shown in VSCode's Terminal tab

  8. If needed, you can inspect the assembly (and move instruction by instruction) via the Command palette > Open Disassembly View

  9. You can change the value of a variable

  10. When you see the Uboot shell => after the program exit, you can hit Enter to restart the debug directly if desired.

  11. If you want to stop or interrupt the debug, hit Shift+F5. It should completely kill the debug session and close the terminal. If for some reason the terminal session is stuck, try Enter, ctrl+c or the trash icon. Then you can restart the process at step 2.

You can hide these annoying popup

vscode-open-ports-popup.png

Eclipse with the CLI in parrallel

global view
The final view of debugging with Eclipse. The terminal at left and Eclipse at right stopped on breakpoint at line 31.

  1. Make sure the current workspace is the lab directory.

    eclipse-opening-lab-folder.png

  2. If you see this error, you can ignore it.

    eclipse-ignore-workspace-versions-issue.png

  3. Build your code: asm make

  4. Start the binary in Qemu for debugging: asm debug arm/hello_world.bin

  5. It will wait 7 seconds to let you start the debug in Eclipse.

    eclipse-debug-picker.png

    If this pause is too short for you, it can be configured (see asm help).
    Note: If you don't see these debug entries, this is because you don't have the CDT plugin, as described in the setup page.

  6. Fix the issue with debuggers not starting

    See the fix

    The arm-none-linux-gnueabihf-gdb binary will not be found or will crash... i686-linux-gdb might also not be found.

    arm-linux-gdb-failure.png

    The solution is easy: you have to manually replace the gdb binary in the Debug configurations. At left, for all entries for ARM and x86 you change this. On Fedora gdb is a perfectly fine replacement. On Ubuntu gdb-multiarch works fine.

    eclipse-debug-configs.png
    eclipse-debug-config-details.png

  7. Then it will run the go 0x... command. Eclipse will show you the program stopped on the first breakpoint.

  8. Eclipse is showing disassembly, variables and registers panels. The registers can be edited directly in the associated panel.

    eclipse-advanced-views.png

GDB only for the raw experience

If you go down this route, you might find useful to use a GDB frontend to have a better UI.

Here is an example to debug x86/crackme.bin in ./st86, in 2 terminal windows: window 1 is for GDB and window 2 is for qemu

  1. Window 2:
    1. Run ./st86 (for arm it would be ./st)
    2. Run setenv cmd "tftp x86/crackme.bin"
    3. Run run cmd
  2. Window 1:
    1. run gdb or gdb-multiarch (Fedora or Ubuntu respectively)
    2. run inside gdb file x86/crackme
    3. run inside gdb target remote localhost:1234
  3. Window 2:
    1. Run go 0x40000
  4. The debug should now be ready
  5. Window 1:
    1. You should be able to run standard gdb commands like
      • list to see source code
      • b 20 to set a breakpoint at line 20
      • c to call continue used to go until next breakpoint
      • n to go to next instruction
      • ni to go to nexti assembly instruction