OSDev.org

Posted: **Sat Jan 16, 2010 6:36 am**

Hi. During my OS design I encountered a problem with GDB remote debugging. When I try to continue execution of stopped kernel after remote connection to it (either by next, step, continue or any other command) the GDB tries to set breakpoint on the image entry point. The problem is that my OS image is loaded at low physical addresses (probably the most OS'es do that) and after that is remapped on highest virtual addresses. After the paging is enabled the temporal identity mapping in the lowest virtual addresses is invalidated and the original entry point becomes inaccessible. So the GDB cannot debug the kernel when I use Qemu built-in debugger:

Code: Select all

(gdb) n
Warning:
Cannot insert breakpoint -1.
Error accessing memory address 0x200000: Unknown error 4294967295.

0x200000 - is my OS loading address and entry point address.
For the OS-builtin debugger I use temporal workaround: when someone tries to read or write from boot-code range I translate these addresses to higher memory where the boot-code also is accessible. This works but in some cases I'm not able to use my built-in debugger (e.g. when the debugger itself needs to be debugged) and I need to use Qemu debugger. Probably GDB could have some option to not insert this breakpoint which still is not used. I searched for a such option but nothing found. May be somebody had similar problem and knows the solution? Thanks in advance.

Posted: **Mon Jan 25, 2010 1:19 pm**

Hi,
I have successfully solved the problem. I will describe the solution for the case someone will have such problem. Firstly, I have not found any way to tell GDB to not create breakpoint on program entry point. So I just made him think that my entry point is located at relocated high addresses. All I needed was just slightly modify linker script and entry point code. Here is a fragment of my linker script:

Code: Select all

...................................................................................
ENTRY(start)

SECTIONS {
	. = KERNEL_ADDRESS;
	.boot_trampoline : AT(LOAD_ADDRESS) {
		*/start.o(.text)
	}
	_eboot_tramp = ALIGN(0x1000);
	
	. = LOAD_ADDRESS + _eboot_tramp - KERNEL_ADDRESS;
	.boot : AT (LOAD_ADDRESS + _eboot_tramp - KERNEL_ADDRESS) {
		*/start.o(.data .rodata*)
		*/init.o(.text .data .rodata*)
		_bootbss = ABSOLUTE(.);
		*/start.o(.bss)
		*/init.o(.bss)
	}
	_eboot = ALIGN(0x1000);
	
	. = KERNEL_ADDRESS + _eboot - LOAD_ADDRESS;
	.text : AT(_eboot) {
		_btext = ABSOLUTE(.);
		*(.text)
		*(.gnu.linkonce.t.*)
	}

	. = ALIGN(0x1000);
	_etext = ABSOLUTE(.);
	
	/* exclude constructors/destructors of init.cpp from global list */
	/DISCARD/ : {
		*/init.o(.ctors .dtors)
	}
...................................................................................

LOAD_ADDRESS - is low physical loading address and KERNEL_ADDRESS is high virtual relocation address which are defined in makefile. start.o file is produced from start.S file which contains in its text section just several instructions to jump in C++ initialization code:

Code: Select all

..................................................
	.text
	.globl start, _start
start:
_start:
	cli
	movl	$boot_stack, %esp
	pushl	%ebx 		/* boot info */
	pushl	%eax		/* boot loader signature */
	pushl	$start_ret	/* return address, for debugger */
	pushl	$Bootstrap
	ret
start_ret:

/* Multiboot header */
.align	4
/* magic */
.long   MULTIBOOT_HEADER_MAGIC
/* flags */
#define MBH_FLAGS (MULTIBOOT_HF_PAGEALIGN | MULTIBOOT_HF_MEMINFO)
.long   MBH_FLAGS
/* checksum */
.long   -(MULTIBOOT_HEADER_MAGIC + MBH_FLAGS)
..................................................

Hope this may help for someone.

OSDev.org

GDB question

GDB question

Re: GDB question