The debugger does not work after jump to the higher half

[mrjbom]

Hi.
I use Visual Studio Code for debugging and using the "Native Debug" extension I connect to qemu and I debug the kernel.
Now I've finished following "Higher Half x86 Bare Bones" and everything is working as it should.
However, I came across the fact that after jumping to the top half, I can't debug the code in this file. Debugging when in other source files works fine.

Code: Select all

section .multiboot.text
. . .
    ; Jump to higher half with an absolute jump.
    ; <breakpoint is successfully triggered here>
    lea ecx, .higher_half
    jmp ecx

section .text
.higher_half:
    ; Unmap the identity mapping as it is now unnecessary.
    ; <breakpoint doesn't work here>
    mov [boot_page_directory + 0], DWORD 0

    ; Reload crc3 to force a TLB flush so the changes to take effect.
    mov ecx, cr3
    mov cr3, ecx
. . .

Step-by-step debugging seems to work, but I can't see which line I'm on.

Has anyone encountered this? What could be the problem?

[Octocontrabass]

Did you tell your assembler to include debug information in its output? If you did, what kind of debug information did you tell it to use?

[iansjack]

How does your higher-half kernel get loaded? Do you load it to low memory then move it to higher memory, or does your boot loader load it directly to its final address?

If the former, I suspect your debugger is still working on the premise that your kernel is located at its load address, so can't reconcile the debugger information with the running code.

[mrjbom]

Did you tell your assembler to include debug information in its output? If you did, what kind of debug information did you tell it to use?

Of course, I use the -g flag for nasm, which generates debugging information.

[mrjbom]

If the former, I suspect your debugger is still working on the premise that your kernel is located at its load address, so can't reconcile the debugger information with the running code.

I think everything is as you say.
Is it possible to "explain" to the debugger how to behave correctly after the moment with the jump to the upper half?

[iansjack]

In gdb one can specify an offset that is added to symbol addresses: https://sourceware.org/gdb/onlinedocs/gdb/Files.html

I'm not sure whether you can do the same with the Windows debugger.

[mrjbom]

In gdb one can specify an offset that is added to symbol addresses: https://sourceware.org/gdb/onlinedocs/gdb/Files.html

The offset that I can specify for gdb will be added to all sections.
However, in my case it should only seem like a section .text and within this file. Is it possible to change this offset right during debugging?

[iansjack]

I presume that you can reload the symbol file with a different offset whilst debugging.

[mrjbom]

I presume that you can reload the symbol file with a different offset whilst debugging.

gdb as a whole complains about the lack of information about the line, although it must be contained, because this whole file is compiled with debugging information and debugging works up to the moment with a jump. I have no idea what this is related to.

[iansjack]

But does it still complain after you reload the symbols with the appropriate offset?

Until you do that the debugging information is wrong once you jump to the relocated code. Gdb can't reconcile the instruction pointer with the lines of code.

[mrjbom]

Gdb can't reconcile the instruction pointer with the lines of code.

I tried to change the location of the section trying to coordinate them

gdb console:

Code: Select all

> info files
Symbols from "/home/emilia/osdev/kernel-0.bin".
Remote serial target in gdb-specific protocol:
Debugging a target over a serial line.
	While running this, GDB does not access memory from...
Local exec file:
	`/home/emilia/osdev/kernel-0.bin', file type elf32-i386.
	Entry point: 0x100030
	0x00100000 - 0x00100030 is .multiboot.data
	0x00100030 - 0x0010009b is .multiboot.text
	0xc0101000 - 0xc0101411 is .text
	0xc0101411 - 0xc0101420 is .init
	0xc0101420 - 0xc010142a is .fini
	0xc0102000 - 0xc0102016 is .rodata
	0xc0102018 - 0xc010201c is .eh_frame
	0xc0103000 - 0xc0103008 is .data
	0xc0103008 - 0xc0103010 is .ctors
	0xc0103010 - 0xc0103018 is .dtors
	0xc0104000 - 0xc010b010 is .bss

> section .text 0x00101000
	`/home/emilia/osdev/kernel-0.bin', file type elf32-i386.
	Entry point: 0x100030
	0x00100000 - 0x00100030 is .multiboot.data
	0x00100030 - 0x0010009b is .multiboot.text
	0x00101000 - 0x00101411 is .text
	0xc0101411 - 0xc0101420 is .init
	0xc0101420 - 0xc010142a is .fini
	0xc0102000 - 0xc0102016 is .rodata
	0xc0102018 - 0xc010201c is .eh_frame
	0xc0103000 - 0xc0103008 is .data
	0xc0103008 - 0xc0103010 is .ctors
	0xc0103010 - 0xc0103018 is .dtors
	0xc0104000 - 0xc010b010 is .bss

But it doesn't affect anything at all.

I also created a separate file with symbols
objcopy --only-keep-debug kernel-0.bin kernel.sym
and tried to reload it immediately after the jump
symbol-file kernel.sym -readnow