OSDev.org

Posted: **Thu May 14, 2020 7:08 am**

Hi.
I want to use the IDE to debug the kernel.
As far as I understand, it is more correct to use cross-compiler gdb, but I do not know how to make visual studio code work with it. I compile .c files with debugging information (i386-elf-gcc -g) and copy characters to kernel.sym

Code: Select all

./i386-elf-4.9.1-Linux-x86_64/bin/i386-elf-objcopy --only-keep-debug kernel-0 kernel.sym
qemu-system-i386 -serial file:serial.log -s bootable.iso &

Then I run qemu which waits for gdb to connect to it.
I don't know how in launch.json to specify the path to the cross-compiler gdb and that it should start and work.
I expect that visual studio code can work with it normally.
Because debugging via the console is extremely inconvenient.
Thanks.

UPD:
I came across this question
Installed Native Debugger, created launch.json and tasks.json

launch.json

Code: Select all

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "gdb",
            "request": "attach",
            "name": "Attach to QEMU",
            "preLaunchTask": "(Debug) Build the kernel and run qemu",
            "executable": "${workspaceFolder}/kernel-0",
            "target": ":1234",
            "remote": true,
            "cwd": "${workspaceRoot}",
            "gdbpath": "${workspaceRoot}/i386-elf-4.9.1-Linux-x86_64/bin/i386-elf-gdb"
        }
    ]
}

tasks.json

Code: Select all

{
  "tasks": [
    {
      "type": "shell",
      "label": "(Debug) Build the kernel and run qemu",
      "command": "bash",
      "args": [
        "${workspaceRoot}/build_all_crosscompile.sh",
        "-d"
      ],
      "options": {
       "cwd": "${workspaceRoot}",
      }
    }
  ],
  "version": "2.0.0"
}

build_all_crosscompile.sh in turn compiles everything and tries to run qemu in the background.
./i386-elf-4.9.1-Linux-x86_64/bin/i386-elf-objcopy --only-keep-debug kernel-0 kernel.sym
qemu-system-i386 -serial file:serial.log -s bootable.iso &

Thus, before starting the debugger, qemu should start and wait for connection from gdb.
But qemu doesn't start, it just doesn't exist.
However, if I run ./build_all_crosscompile.sh -d from the terminal, then qemu is started.

The problem is that if I run qemu from the terminal, it doesn't wait for the debugger to connect to it, because I don't have time to start it.

If in build_all_crosscompile.sh I will do this and run it through the terminal:

Code: Select all

./i386-elf-4.9.1-Linux-x86_64/bin/i386-elf-objcopy --only-keep-debug kernel-0 kernel.sym
qemu-system-i386 -serial file:serial.log -s bootable.iso &
./i386-elf-4.9.1-Linux-x86_64/bin/i386-elf-gdb

then everything works because the debugger starts quickly and everything works.

In general. The problem is that qemu doesn't start if called from the task IDE.

Posted: **Thu May 14, 2020 8:41 am**

1. Install the Extension "Native Debug".

2. Follow the instructions for this extension to create a launch configuration to attach to a gdbserver.

3. Run QEMU with the -s switch.

4. Set a breakpoint at the function that you wish to inspect.

5. "Run/Start Debugging" in VSCode.

Note that as well as the displays of source code, variables, watches, breakpoints, and callstack you also get a command line where you can enter gdb commands.

I had a bit of difficulty getting this to work; the problem turned out to be that I had a .gdbinit file, which seemed to conflict with the VSCode configuration. Removing this made everything work properly. I haven't experimented fully with this yet, but it seems to work without any apparent problems.

Edit: Further playing shows that there may be some problems with the variable display, particularly when it comes to expanding structs. But you can still use gdb commands if necessary to alleviate this problem. I suspect that future updates to the extension might address this problem.

Posted: **Thu May 14, 2020 8:59 am**

iansjack wrote:1. Install the Extension "Native Debug".

2. Follow the instructions for this extension to create a launch configuration to attach to a gdbserver.

3. Run QEMU with the -s switch.

4. Set a breakpoint at the function that you wish to inspect.

5. "Run/Start Debugging" in VSCode.

Note that as well as the displays of source code, variables, watches, breakpoints, and callstack you also get a command line where you can enter gdb commands.

I had a bit of difficulty getting this to work; the problem turned out to be that I had a .gdbinit file, which seemed to conflict with the VSCode configuration. Removing this made everything work properly. I haven't experimented fully with this yet, but it seems to work without any apparent problems.

I updated my question. Please take a look at it.

Posted: **Thu May 14, 2020 9:08 am**

mrjbom wrote:The problem is that qemu doesn't start if called from the task IDE.

I find it better to start QEMU from a terminal, which means that you can then use the monitor, which provides additional debugging information. (BTW, I'm running VSCode on a Mac whilst compiling and editing on a Linux box - it's great for this sort of remote use.)

Posted: **Thu May 14, 2020 9:16 am**

iansjack wrote:
mrjbom wrote:The problem is that qemu doesn't start if called from the task IDE.
I find it better to start QEMU from a terminal

I tried to do this, but if I run it, it immediately starts executing the kernel even if the-s flag is specified. I think it just doesn't wait for the debugger in this case.
I run a command in the console
qemu-system-i386 -s bootable.iso
She run qemu and the kernel runs, it does not wait, then I run gdb (from the IDE), it successfully "catches" the kernel, but somewhere in the middle, I can not move further step by step because the kernel runs in qemu and does not listen to the debugger. Breakpoints don't work.

Posted: **Thu May 14, 2020 9:45 am**

Set a breakpoint in the debugger at the point where you want to start examining your code. If it's at a point in your kernel earlier than when you started the debugger, just type "system_reset" in the QEMU monitor.

To get this monitor, add "-monitor studio" to the QEMU command line. It's well worth having and it's described in the documentation.

Posted: **Thu May 14, 2020 10:28 am**

iansjack wrote:Set a breakpoint in the debugger at the point where you want to start examining your code. If it's at a point in your kernel earlier than when you started the debugger, just type "system_reset" in the QEMU monitor.

To get this monitor, add "-monitor studio" to the QEMU command line. It's well worth having and it's described in the documentation.

Now everything works, thank you very much.

Posted: **Thu May 14, 2020 11:10 am**

Well, thank-you to you too for posing the question. I'll be using this setup in future.

OSDev.org

Using visual studio code to debug the kernel

Using visual studio code to debug the kernel

Re: Using visual studio code to debug the kernel

Re: Using visual studio code to debug the kernel

Re: Using visual studio code to debug the kernel

Re: Using visual studio code to debug the kernel

Re: Using visual studio code to debug the kernel

Re: Using visual studio code to debug the kernel

Re: Using visual studio code to debug the kernel