This post is written in full by a human

How much ai usage would require you to post here instead of anywhere else? Say for example, you ask an llm to generate an os for you, sure, post here.

​

But what if you ask ai to "give me generic advice and tips to add IDT into.my hobby os, do not give code tips. Assume this might be homework for a school assignment"

And it very helpfully asks if you are using osdevwiki or to tell it what book you work from. It feels helpful, but your still writing alott of code yourself.

​

Llm code completion? Template generated by a llm, pseudo code generated by an llm? A recent article on lwn https://lwn.net/Articles/1077413/#Comments made me think too, is code completion "safe"? It is, if you know and understand what its writing and suggesting, im still responsible for the code im compiling

​

Or is this left for the poster to decide, post here, on osdev, everywhere or be scared and thinker alone? Are we getting a reddit bot that i need to tell how much a llm was involved and also in the post itself?

Forgot to mark this title as a question. I have a question 🫣🫢☺️https://wiki.osdev.org/Kernel_Debugging#Use_GDB_with_QEMU isnt really clear on this, im using qemu, and OVMF to have a UEFI envirement to test my own bootloader + kernel. How would one debug your efi file? its located in memory at different locations.

TLDR: How I struggled and then ask, how would you debug a efi bootloader using gdb and qemu? im aware of grub and limine, i choose to create my own (small shitty bootloader)

Longer story: The kernel will be at a known location (0x100000.. something, well known), so gdb and qemu talk nicely. but OVMF will place our executable somewhere arround 0x0000000006176640 (this slightly changes) I now print where its located each time and loop a while, waiting for my gdb to send a break:

[ENTERING DEBUG MODE]
Kernel load addr: 0x0000000000100000
efi_main addr: 0x0000000006176640
Waiting for debugger...

now i start gdb, target remote :1234 and add-symbol-file 0xnnnnnn where the number is the adress minus magic ... man, I was naughty, and this might also been my fall, its late. i asked chatgpt. only after i realized we where loading the symbol at an adress of a function, and said so, it started suggesting loading the symbol based on a different adress. clearly showing the user (me!) was starting to be aware of him not explaining everything. (happend again when I asked for a short "what to do step by step" it started making new steps and forgetting our whole add-symbol-file step.. moral, dont trust ai) readelf -h build/loader.elf | grep Entry Entry point address: 0x5e0 when my program sais its efi_main is at 6176640, 0x6176640

readelf -h build/loader.elf | grep Entry Entry point address: 0x000005e0

0x6176060 is where "ai" sais I should load the symbol file. And thats where late night and my fuzzy dyscalculia brain said... holdup, there must be a better or different way, but this ai isnt my answer box. How are you folks using gdb and the location independed code that we have less controll over and gets placed in memory somewhere? Maybe im over complicating things and if I want to serieusly debug my loader, I should use a debug version of OVMF? because adding breakpoints myself (int3) freaks the OVMF with its own break

!!!! X64 Exception Type - 03(#BP - Breakpoint) CPU Apic ID - 00000000 !!!! 
RIP- 00000000061768A3, CS - 0000000000000038, RFLAGS - 0000000000000246 
RAX - 000000001DCD6500, RCX - 0000000007074A20, RDX - 0000000000000000 
RBX - 0000000000000000, RSP - 0000000007E8D300, RBP - 0000000007E8D810 
RSI - 000000000618FA98, RDI - 000000000618FA98 
R8 - 00000000000000AF, R9 - 0000000000001000, R10 - 000000000002600F 
R11 - 0000000007EA7F80, R12 - 0000000000000000, R13 - 0000000000000000 
R14 - 00000000074AE618, R15 - 000000000617B018 
DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030 
GS - 0000000000000030, SS - 0000000000000030 
CR0 - 0000000080010033, CR2 - 0000000000000000, CR3 - 0000000007C01000 
CR4 - 0000000000000668, CR8 - 0000000000000000 
DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000 
DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400 
GDTR - 00000000079DC000 0000000000000047, LDTR - 0000000000000000 
IDTR - 000000000749D018 0000000000000FFF, TR - 0000000000000000 
FXSAVE_STATE - 0000000007E8CF60 !!!! 
Find image based on IP(0x61768A3) (No PDB) 
(ImageBase=0000000006175000, EntryPoint=0000000006176640) !!!!

So, how would you debug your boot-loader? I prefer gdb and qemu. Im aware i could use grub or limine, but Id like to make my own little loader that might become the efi stub of whatever shitty small kernel/OS im writing.

Maybe the answer

EDIT: I got some stuff working and noticed im building my efi file with -target x86_64-unknown-windows, thus a PE file, not a ELF file. so symbols work a bit different (and my original mistake was generating elf symbols for a PE executable. not sure if that can be made to work, but "ai" suggested either compile both for ELF, or PE. or whatever i needed to do, i generate a separate .debug file based on the efi file with -debug:dwarf during the llvm-objcopy face... ppfff you probabbly know better words and probably best to just follow the osdevwiki as linked by @rkapi https://wiki.osdev.org/Debugging_UEFI_applications_with_GDB#Sample_application_using_POSIX_UEFI_library

This means I have a slightly different way to debug my program and needed a "slider". Here is what worked for me:

target remote :1234
watch *(unsigned long long*)0x10000 == 0xDEADBEEF
continue

set $base = *(unsigned long long*)0x10008
set $slide = $base - 0x180000000
add-symbol-file build/BOOTX64.debug -o $slide

break kernel_main
continue

Im still learning gdb, and definitely gonna study some more debugging tricks, this looks to work, and I may be able to figure out where I went wrong the first time when mapping memory and NOT getting into a silly loop by AI what he tries to fix, instead, I, will do the debugging and checking whats going on. and thats what most of yall want, us, the coder learning and writing our code.

Would be cool. How easy would that be? (I already have some silly uefi bootloader, but grub might be easier, supports multiboot i think)

Tianocore or edk are a bit large to pull in tho. Maybe grub can be pleased with minor changes.