The title sounds strange, but it's a real quantum physics style random bug I can't comprehend and get past.
I'm loading a non-empty tar archive as grub module, and grub gives me address of 0x14F000.
struct multiboot_tag_module* initrd = get_module_by_cmdline("initrd");
// this returns the module tag I need with start address of 0x14F000
as I check with debugger, there are only zeros, and the rest of my code does not work (it expects here to be something. But whenever I insert something which directly references this address in code, for example:
char c = *(char*)initrd->mod_start;
it somehow figures out that there is something, debugger shows valid info and, and the code itself works fine.
I'm using GCC to compile, GDB to debug, my file output format is elf-i386 and QEMU is qemu-system-x86_64. Bootloader is GRUB 2, and I'm using Multiboot 2.0 with my own custom kernel.
So, why is this happening, is it local to QEMU and how to get around that without having to resort to this seemingly redundant stub?
P.S. Btw, I have recently stumbled upon a similar bug, but in strlen(). The classical assignment
const char* tmp = str;
did not work (tmp != str as debugger had shown even right after the statement), and the function was returning a wrong value, and I "fixed" it by... an if statement.
if (str != tmp)
// this actually never runs
kprintf("%p %p\n", str, tmp);