Can't debug with gdb and qemu

[fctorial]

I'm following this guide but can't get qemu and gdb to work:

https://fuchsia.dev/fuchsia-src/development/debugging/qemu#debugging_the_kernel_with_gdb

I'm starting qemu like this:

    $ fx qemu -- -s -S

This is what a gdb session looks like:

```

$ gdb /home/fctorial/src/fuchsia/fuchsia/out/core.qemu-x64.zircon/kernel-x64-clang/obj/kernel/zircon.elf

GNU gdb (GDB) 9.2

Copyright (C) 2020 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GDB was configured as "x86_64-unknown-linux-gnu".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".

Type "apropos word" to search for commands related to "word"...

Reading symbols from /home/fctorial/src/fuchsia/fuchsia/out/core.qemu-x64.zircon/kernel-x64-clang/obj/kernel/zircon.elf...

warning: File "/home/fctorial/src/fuchsia/fuchsia/zircon/kernel/scripts/zircon.elf-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/nix/store/hxs99j1kx878pxxw5lbdarml69r5f1qb-gcc-9.3.0-lib".

To enable execution of this file add

        add-auto-load-safe-path /home/fctorial/src/fuchsia/fuchsia/zircon/kernel/scripts/zircon.elf-gdb.py

line to your configuration file "/home/fctorial/.gdbinit".

To completely disable this security protection add

        set auto-load safe-path /

line to your configuration file "/home/fctorial/.gdbinit".

For more information about this security protection see the

"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:

        info "(gdb)Auto-loading safe path"

(gdb) target extended-remote :1234

Remote debugging using :1234

0x000000000000fff0 in ?? ()

(gdb) break _start

Breakpoint 1 at 0xffffffff80100050: file ../../zircon/kernel/arch/x86/start.S, line 55.

(gdb) break lk_main

Breakpoint 2 at 0xffffffff80101640: file ../../zircon/kernel/top/main.cc, line 51.

(gdb) continue

Continuing.

[Inferior 1 (process 1) exited normally]

Remote communication error.  Target disconnected.: Connection reset by peer.

(gdb)

```

On typing continue, the os boots as normal without hitting any breakpoints. The command line shows up, and on killing qemu 'process exited normally' message appears in gdb.

[Sagar Tiwari]

It works now. Thanks.

On 17/01/2021, Marco Vanotti <marcova...@gmail.com> wrote:
> Hi fctorial,
>
> If you use gdb directly with zircon.elf it would not work because of kaslr
> relocation (we just change 1 bit in where we load the kernel).
>
> The gdb python script is supposed to solve that problem (we probably should
> document that). From what I can see in your output, it is not loading
> automatically for you (there's a warning in the gdb output).
>
> Can you try running: *gdb «path-to-zircon.elf»
> -x zircon/kernel/scripts/zircon.elf-gdb.py <http://zircon.elf-gdb.py> *?
>
> (maybe fix the path so it points to the right gdb script).

>> --
>> All posts must follow the Fuchsia Code of Conduct
>> https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
>> ---
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to zircon-dev+...@fuchsia.dev.
>>
>

[Marco Vanotti]

Hi fctorial,

If you use gdb directly with zircon.elf it would not work because of kaslr relocation (we just change 1 bit in where we load the kernel).

The gdb python script is supposed to solve that problem (we probably should document that). From what I can see in your output, it is not loading automatically for you (there's a warning in the gdb output).

Can you try running: gdb «path-to-zircon.elf» -x zircon/kernel/scripts/zircon.elf-gdb.py ?

(maybe fix the path so it points to the right gdb script). 

On Sat, Jan 16, 2021 at 12:47 PM fctorial <fcto...@gmail.com> wrote:

--

[Marco Vanotti]

Cool!

Somehow I can't get it to work with qemu-kvm. It seems like while using kvm, you can't set software breakpoints, you have to use hardware ones (hbreak).

Sadly, gdb's python interface doesn't let you create hardware breakpoints yet. So that complicates things.

As a workaround, you can force gdb to use hardware breakpoints by creating a read-only memory region:

gdb.execute("mem 0 0xffffffffffffffff ro") from the script, or just

`mem 0 0xffffffffffffffff ro` before connecting to the target.

I created fxbug.dev/67893 to track this issue.

Best Regards,
Marco

[Roland McGrath]

The problem with using -S is that you're talking to the debugger before the kernel has actually been loaded.  In fact, in startup it's in 16-bit mode I think and the debugger really doesn't understand that state very well.  My experience with gdb-qemu for x86 when the hardware is not in 64-bit mode has not been very good.  If you don't need to debug the early boot process, then the easiest thing to do is just "cont" at the start (before attempting to insert any breakpoints) to let the system get booted.  Then you can hit ^C in gdb to wake it up and interrupt whatever it's doing at a point when the kernel is fully loaded and running normally.  Then it works to set breakpoints and examine kernel addresses.

If you do need to debug the earlier parts of the boot process, then things are a bit more difficult but there are some tricks you can try.  It's actually a fair bit easier on ARM than on x86.

[Marco Vanotti]

Hi Roland,

I see, I wasn't aware that we don't actually need the -S, as the script would try to look up the kernel_relocated_base from memory (if we attach while the vm is running kernel code).

I didn't have any errors with qemu, and so far the python script worked well for me. But it seems like it's a common issue.

Best Regards,
Marco