Incorrect memory addresses while debugging

[KaloyanYosifov]

Hey Dan,

It seems that the current symbol file is giving incorrect memory addresses in GDB.

My assumption and correct me if I am wrong is that i686-elf-ld -g -relocatable $(FILES) -o ./build/kernelfull.o is using a default link file and does not add the correct memory offset that we assign in the linker file . = 1M;. Therefore kernelfull.o assumes that addresses start from 0. Doing nm ./build/kernelfull.o confirms this.

My solution was to create an exact copy of linker.ld, except that this time we change the OUTPUT_FORMAT to be elf32-i386 instead of binary.

This allows me to add another command during the ./bin/kernel.bin file which creates the correct symbol file.

Full version:

./bin/kernel.bin: $(FILES)
    i686-elf-ld -g -relocatable $(FILES) -o ./build/kernelfull.o
    i686-elf-gcc $(FLAGS) -T ./src/linker.ld -o ./bin/kernel.bin -ffreestanding -O0 -nostdlib ./build/kernelfull.o
    i686-elf-gcc $(FLAGS) -T ./src/linker-elf.ld -o ./build/kernelfull-elf.o -ffreestanding -O0 -nostdlib ./build/kernelfull.o

After the build instead of ./build/kernelfull.o I am using ./build/kernelfull-elf.o for the add-symbol-file command in gdb.

---

Here are a couple of videos explaining the situation in visual format.

Incorrect address: https://drive.google.com/file/d/1zoxyxB-XDsgWz5_OqoqxOIVgC8lmpLgA/view?usp=share_linkCorrect Correct address: https://drive.google.com/file/d/1dd-qMhGv-rzCfYXR-U6lOTISHDJsLg1h/view?usp=share_linkNM Output: https://drive.google.com/file/d/1vakDElifvr5mGEVeEjtpXzXKkTOrahi9/view?usp=share_link

---

Let me know if further information is needed

[nibblebits]

Thanks for bringing this over to Github, thanks for sharing

[chemistr33]

Thanks, this fix worked great with the same gdb issue I ran into. When I would try to print kernel_heap or kernel_heap_table , all the members would be 0x0. Yet when you'd step through a function, the arguments would be populated with the apparently correct values. I knew the data must've been passed in correctly but gdb wouldn't print it.