problem debugging kernel with gdb

[vjain20]

Hi,

I am having problems debugging my kernel through remote gdb in both qemu and bochs.
I followed the instructions given in the wiki - http://wiki.osdev.org/How_Do_I_Use_A_De ... With_My_OS
As instructed I created a symbol file named kernel.sym for my kernel binary.
I have an assembly file loader.asm which calls the main function (kmain()) of the kernel in C.

When I start bochs and set the break point on the the function - kmain()
the break point gets set but on continuing it receives a SIGTRAP and terminates
Whereas without debugging the kernel is running fine on bochs.

Code: Select all

(gdb) symbol-file kernel.sym 
Reading symbols from /home/vaibhav/thesis/vscopy/kernel.sym...done.
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x00000000 in ?? ()
(gdb) break kmain
Breakpoint 1 at 0x10000c: file main.c, line 32.
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0002be96 in ?? ()
(gdb) 

When I try the same thing with qemu it hits the breakpoint at kmain()
but on stepping or next line it just runs through the code to get to the last line.

Code: Select all

(gdb) symbol-file kernel.sym 
Reading symbols from /home/vaibhav/thesis/vscopy/kernel.sym...done.
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
[New Thread 1]
0x000f1996 in ?? ()
(gdb) break kmain
Breakpoint 1 at 0x10000c: file main.c, line 32.
(gdb) c
Continuing.

Breakpoint 1, kmain (bootinfo=0x2bd20) at main.c:32
32	{
(gdb) s
loader.bad () at loader.asm:65
65	loader.asm: No such file or directory.
	in loader.asm
(gdb) 

Here .bad is a label in loader.asm just after the call to kmain()

Please tell me if I am something wrong in both the cases or something extra needs to be done.

Thanks
Vaibhav Jain

[Solar]

The latter error message (from QEMU) is telling you that it cannot find the source code file "loader.asm". Check the "--directory" option of GDB for telling it where to look for sources.

Did you use -O0 when compiling? Optimization can do curious things indeed inside GDB.

[vjain20]

Hi,

The latter error message (from QEMU) is telling you that it cannot find the source code file "loader.asm". Check the "--directory" option of GDB for telling it where to look for sources.

Did you use -O0 when compiling? Optimization can do curious things indeed inside GDB.

I tried both the options above. This time gdb found the source file but still it just rushed through all the code. So by the time it hits
the break point the terminal already has all the display. When I try to step to the next line of the C file main.c , it just takes me to the last line in the assembly file loader.asm (which is jmp $)

Code: Select all

(gdb) break kmain
Breakpoint 1 at 0x100265: file main.c, line 32.
(gdb) c
Continuing.

Breakpoint 1, kmain (bootinfo=0x2bd20) at main.c:32
32	{
(gdb) s
loader.bad () at loader.asm:65
65	        jmp $ 
(gdb)

- Thanks

[Solar]

Did you use -O0 when compiling? Optimization can do curious things indeed inside GDB.

[vjain20]

Did you use -O0 when compiling? Optimization can do curious things indeed inside GDB.

Yes as I mentioned above I tried both the options - using --directory in gdb and -O0 in gcc.

-Thanks
Vaibhav Jain

[vjain20]

Why not use bochs internal debugger (which actually works, in contrast to gdb support which is at best flaky).

Thanks! It actually works. I was given this suggestion before but I ignored it. I should have done this before.

Here is a link which provides script to generate symbol file for bochs - http://wiki.cs.unm.edu/ssl/doku.php/kurt:bochs
and shows how to debug using bochs internal debugger.

-Thanks
Vaibhav Jain

[vjain20]

Why not use bochs internal debugger (which actually works, in contrast to gdb support which is at best flaky).

Is there a way that bochs debugger can display C code and step one line at a time instead of one assembly instruction ?
I am finding it hard to single-step through the code.


-Thanks
Vaibhav Jain