Page 1 of 1

kernel debugging problem; qemu & bochs - SIGSEGV on cli(

Posted: Tue Oct 31, 2006 11:27 am
by raistlinthewiz
Hi,

i'm hacking my own OS these days.
It's somewhat working on real hardware & qemu & bochs.

The problems is that, theres a strange problem with my IRQ1 - keyboard handler code.
So i want to debug the problem using GDB.

The problem arrises now;
I have compiled a bochs with gdb-stub support and got apt-get install qemu.
For both, when i enable the debugging (gdb-stub enable in bochs, -s -S switches with qemu)
i'm getting SIGSEGV when trying to debug my OS code;
Starting program: /root/kernel/trunk/kernel/kernel.bin
Program received signal SIGSEGV, Segmentation fault.
main (magic_no=0, addr=0) at src/kernel.c:29
29 cli(); /* disable interrupts while init */
This is somewhat strange, as i already statedi in real hardware or non-debugging qemu or bochs mode, the code just works.

Here is my cli() definition;

Code: Select all

#define sti() __asm__ __volatile__ ("sti":::"memory")
#define cli() __asm__ __volatile__ ("cli":::"memory")
the code that i got SIGSEGV;

Code: Select all

void main(unsigned long magic_no,unsigned long addr) /* entrance point to kernel */
{
	int i;

	cli(); /* disable interrupts while init */
this is the just init code, which is called from the boot.S with the GRUB multiboot specification stub;

Code: Select all

             /* Now enter the C main function... */
             call    EXT_C(main)
Any ideas & suggestions welcome

Posted: Tue Oct 31, 2006 11:46 am
by Candy
what's after the cli?

Posted: Tue Oct 31, 2006 12:00 pm
by raistlinthewiz

Code: Select all

void main(unsigned long magic_no,unsigned long addr) /* entrance point to kernel */
{
	int i;

	cli(); /* disable interrupts while init */
	init_console(); /* prepare any console related data structures */	
	parse_boot_info(magic_no,addr); /* GRUB provided boot info */
	get_cpuid(); /* read CPU brand & technical data */

	printk("Installing GDT (Global Descriptor Table)\n");
	install_gdt();

	printk("Installing IDT (Interrupt Descriptor Table)\n");
	install_idt();
	
	printk("Enabling interrupts...\n");
	sti(); /* system init ok, so re-enable the interrupts */

	/* print pre-processor information */	
	printk("Compiled %s %s\n",__DATE__,__TIME__);
	
	init_keyboard(); 
	printk("System Ready...\n");
	printk(">");
	
	while(1)
	{
		/* idle loop */
	}
	
}
function calls to misc. system startup...

but the right after the cli, init_console() takes place which inits the console buffer

Code: Select all

void init_console(void) /* initialize the console driver */
{
	/* must be called before any printk or screen related function */
	/* TODO: put a check if the init_console is called before any other console related function */
	int i,j;
	
	cls();
	vga_buffer_x_offset=0; // vga buffer's x cordinate
	vga_buffer_y_offset=0; // vga buffer's y cordinate
	
	/* loop through the entire vga buffer array */
	for(i=0;i<80;i++)	
	{
		for(j=0;j<24;j++)
		{
			vga_buffer[i][j]='\0'; /* init the vga_buffer_array */
		}
	}
}
then which calls the

Code: Select all

void cls (void)
     {
       int i;
     
       video = (unsigned char *) VIDEO;
     
       for (i = 0; i < COLUMNS * LINES * 2; i++)
         *(video + i) = 0;
     
       xpos = 0;
       ypos = 0;
     }
but with answering this question, i remember

Code: Select all

*(video + i) = 0;
line giving SIGSERV, then i'll try to resolv this lines problem now.

Btw;

Code: Select all

     /* The video memory address. */
     #define VIDEO                   0xB8000
     /* Point to the video memory. */
     volatile unsigned char *video;

Posted: Wed Nov 01, 2006 5:37 am
by Candy
If nothing helps directly, you can try to use the basic elimination principle, comment out half your code and see whether it crashes. If it does, repeat on the part you didn't remove, if it doesn't, mark the code as valid and repeat on the part you removed. This helps, assuming a not too lengthy compile process, with removing very stubborn crashes and bugs. It also helps diagnose limit bugs, since either half could be removed "fixing" the bug.

Posted: Wed Nov 01, 2006 8:44 am
by raistlinthewiz
okay, thanks with the direction.
my initial view was a set interrupt & clear interrupt problem handing with gdb, but i understand better the problem.

Posted: Wed Nov 01, 2006 11:39 am
by raistlinthewiz
i've tried to first comment all the lines except the cli() call in my main function. Seems still i got the same problem.

In util.h file here's my definition for cli() and sti()

Code: Select all

#define sti() __asm__ __volatile__ ("sti":::"memory")
#define cli() __asm__ __volatile__ ("cli":::"memory")
instead of calling the cli() function, i tried to execute
asm volatile ("CLI")

but same problem.

Anyone seems a problem with my clear interrup code?

Posted: Wed Nov 01, 2006 2:17 pm
by Candy
raistlinthewiz wrote:i've tried to first comment all the lines except the cli() call in my main function. Seems still i got the same problem.

In util.h file here's my definition for cli() and sti()

Code: Select all

#define sti() __asm__ __volatile__ ("sti":::"memory")
#define cli() __asm__ __volatile__ ("cli":::"memory")
instead of calling the cli() function, i tried to execute
asm volatile ("CLI")

but same problem.

Anyone seems a problem with my clear interrup code?
As far as I can tell, no. Are you running in a mode that disallows cli, such as V86 mode or some lower-cpl mode? could you check that somehow?

Posted: Wed Nov 01, 2006 4:45 pm
by niteice
It looks like you're trying to run the program as a local binary, whereas you should be connecting to qemu or bochs.

Posted: Wed Nov 01, 2006 5:29 pm
by raistlinthewiz
i have enabled bochs gdb-stub via config.

After running bochs, i'm opening gdb with
gdb kernel.bin

and then connectin remote via
target remote localhost:1234

Posted: Wed Nov 01, 2006 5:38 pm
by raistlinthewiz
niteice wrote:It looks like you're trying to run the program as a local binary, whereas you should be connecting to qemu or bochs.
thanks for the help guys.
as u just pointed i was making gdb to confuse and try to debug it with a local binary.

im now just using;

gdb
target remote localhost:1234
symbol-file kernel.bin