Hello. Engaged in the development of simple wasps. Faced a problem: I can't upload debug information files to gdb. There are a dozen files that are compiled into separate .o files and then linked into one binary.

G ++ command line

g++ -c -g -m32 -nostdlib -nostartfiles -nodefaultlibs

Command line ld

 ld -T src/kernel/link.ld -o bin/kernel.bin $(KERNEL_OBJ_LINK_LIST)

link.ld

 ENTRY(kernel_start) SECTIONS { . = 0x00100000; ___kern_mem_start = .; .text : { *(.text) } .rodata : { *(.rodata) } .data : { *(.data) } .bss : { *(.bss) } ___kern_mem_end = .; _mem_null = .; }

Now, launching gdb and joining qemu, I want to set a breakpoint on any function, but I can’t because gdb writes that debug information is not loaded. How do I download this information? I tried to specify gdb

 file bin/kernel.bin

but gdb writes that it cannot find debugging information there despite the -g flag in g ++.

Update .

I load symbols from the file prepared via objdump. When loading, it still writes that the characters were not loaded, but at the same time I can put a breakpoint on the function. The problem now is that this breakpoint doesn't work. Any idea what the problem is?

  • And this is already tried? - avp
  • Yes of course. I do just that. - user183725
  • Well, then it remains to hope that someone has already passed this path in practice and will tell you what and how (but, look also in other places, it seems there are no such gurus here). - avp
  • I hoped so. But apparently no one has encountered such a problem. - user183725

1 answer 1

After a long study of gdb dumps, I understood what the error was. The loader loaded the preparatory sector of the kernel and the kernel itself at 0x100: 0x0 (absolute address 0x1000). At the same time, the linker script contains a countdown of addresses from 0x100000. Accordingly, the addresses of functions and variables from 0x100000 fell into the debug information. Fixed the script and it worked. Gdb complained about a bad debug file. Fixed changing the format of debug information (-gstabs). I find it difficult to explain why this format works. select from this page https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

A piece of my makefal. Maybe someone will come in handy. After linking, we remove debug information from the binary using objcopy utility into a separate file.

 KERNEL_COMPILER=gcc KERNEL_DEFAULT_GCC_FLAGS=-m32 -nostdlib -nostartfiles -nodefaultlibs -gstabs KERNEL_OBJ_LINK_LIST=$(CRTI_OBJ) \ $(CRTBEGIN_OBJ) \ obj/kernel_start.o \ obj/kernel_main.o \ obj/gdt_flush.o \ obj/gdt.o obj/kdbg.o \ obj/idt.o \ obj/idt_impl.o \ obj/kmem.o \ $(CRTEND_OBJ) \ $(CRTN_OBJ) \ obj/kernel_debug_end.o bin/kernel.bin: nasm -f elf32 src/kernel/kernel_start.asm -o obj/kernel_start.o -l lst/kernel/kernel_start.lst $(KERNEL_COMPILER) -c -o obj/kernel_main.o src/kernel/kernel_main.cpp $(KERNEL_DEFAULT_GCC_FLAGS) $(KERNEL_COMPILER) -c -o obj/gdt.o src/kernel/hal/gdt.cpp $(KERNEL_DEFAULT_GCC_FLAGS) nasm -f elf32 src/kernel/hal/gdt_flush.asm -o obj/gdt_flush.o -l lst/kernel/hal/gdt_flush.lst $(KERNEL_COMPILER) -c -o obj/idt.o src/kernel/hal/idt.cpp $(KERNEL_DEFAULT_GCC_FLAGS) nasm -f elf32 src/kernel/hal/idt_impl.asm -o obj/idt_impl.o -l lst/kernel/hal/idt_impl.lst $(KERNEL_COMPILER) -c -o obj/kmem.o src/kernel/kmem.cpp $(KERNEL_DEFAULT_GCC_FLAGS) $(KERNEL_COMPILER) -c -o obj/kdbg.o src/kernel/kdbg.cpp $(KERNEL_DEFAULT_GCC_FLAGS) nasm -f elf32 src/kernel/kernel_debug_end.asm -o obj/kernel_debug_end.o -l lst/kernel/kernel_debug_end.lst ld -g -T src/kernel/link.ld -o bin/kernel.bin -Map lst/kernel/kernel_map.map $(KERNEL_OBJ_LINK_LIST) objcopy --only-keep-debug bin/kernel.bin debug_info/kernel.debug objcopy --strip-debug bin/kernel.bin bin/kernel.bin