Page 1 of 1
The debugger does not work after jump to the higher half
Posted: Wed Mar 02, 2022 6:52 am
by 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?
Re: The debugger does not work after jump to the higher half
Posted: Wed Mar 02, 2022 6:39 pm
by 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?
Re: The debugger does not work after jump to the higher half
Posted: Thu Mar 03, 2022 3:10 am
by 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.
Re: The debugger does not work after jump to the higher half
Posted: Thu Mar 03, 2022 5:27 am
by mrjbom
Octocontrabass wrote: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.
Re: The debugger does not work after jump to the higher half
Posted: Thu Mar 03, 2022 5:36 am
by mrjbom
iansjack wrote: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?
Re: The debugger does not work after jump to the higher half
Posted: Thu Mar 03, 2022 6:05 am
by 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.
Re: The debugger does not work after jump to the higher half
Posted: Thu Mar 03, 2022 6:40 am
by mrjbom
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?
Re: The debugger does not work after jump to the higher half
Posted: Thu Mar 03, 2022 7:12 am
by iansjack
I presume that you can reload the symbol file with a different offset whilst debugging.
Re: The debugger does not work after jump to the higher half
Posted: Thu Mar 03, 2022 10:41 am
by mrjbom
iansjack wrote: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.
Re: The debugger does not work after jump to the higher half
Posted: Thu Mar 03, 2022 10:46 am
by 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.
Re: The debugger does not work after jump to the higher half
Posted: Thu Mar 03, 2022 2:13 pm
by mrjbom
iansjack wrote: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