Another workaround for GDB

[matthewdu]

Regarding the Set Up GDB page. There's another solution from osdev wiki I'm using that also works: http://wiki.osdev.org/QEMU_and_GDB_in_long_mode#Workaround_1:_Reconnecting

With this we don't need to compile a custom version of GDB. Also rust-gdb seems to be included by default with recent installations of rust (running rust-gdb just works!). So we also don't need to use the custom script from the fork of gdb.

My make gdb target:

gdb:
	@rust-gdb "build/kernel-x86_64.bin" \
	-ex 'set arch i386:x86-64:intel' \
	-ex 'target remote localhost:1234' \
	-ex 'break rust_main' \
	-ex 'continue' \
	-ex 'disconnect' \
	-ex 'set arch i386:x86-64' \
	-ex 'target remote localhost:1234' \
	-ex 'tui enable'

I'm not too familiar with GDB or writing OS in general, so I don't know if there's any downsides to this. Maybe you can't debug the assembly, and only rust source?

[robert-w-gries]

From https://michaelwoerister.github.io/2015/03/27/rust-xxdb.html

Unbeknownst to most Rustaceans, two little helpers have found their way into almost any Rust installation over the last few months: rust-gdb and rust-lldb. These are two small wrapper scripts that will start the underlying debugger with Rust pretty printers enabled

Note that the rust-gdb/rust-lldb scripts will always use the debugger in your PATH, e.g. rust-gdb internally just calls gdb without any qualifications.

Looks like rust-gdb is a wrapper around the system default gdb. It seems like a good idea in general to use rust-gdb since it makes gdb's output of Rust objects more readable. I'll probably start using this wrapper in my Makefile :-)

Regarding the workaround using disconnect, I prefer the patched rust-os-gdb solution. It takes more time to setup, but after compilation and editing my Makefile I forget that I'm even using a separate binary.

With the disconnect workaround, you have to manually disconnect and reconnect after reaching the breakpoint. You're correct that your make rule can't debug the assembly init code, and we should not assume that a developer immediately wants to break at rust_main.

If you still prefer the disconnect workaround because compiling rust-os-gdb is too slow, I've had some thoughts on how to better provide rust-os-gdb:

1. Host the rust-os-gdb binary somewhere
2. Include the building of rust-os-gdb in the docker build when we get docker support (okay so this doesn't actually speed up setup, but it does reduce the number of steps needed)
3. Use a PPA? I don't have much experience with these but it seems popular for distributing community packages on Ubuntu

[phil-opp]

Cool, didn't know about this reconnect trick, thanks! I think we should mention it in the “Set Up Gdb” post.

Regarding rust-gdb: Yeah, it is included for a long time. The script in the fork is just a copy of the builtin script, that uses the modified gdb instead of the system one.

I've had some thoughts on how to better provide rust-os-gdb

Hosting the binary is a good idea. We could use github releases and set up CI (travis and e.g. appveyor) to build the binaries for all common platforms. Integrating it into the docker build makes sense, too. I don't know much about PPAs either, unfortunately…