Why do I get the wrong address when referencing a global variable?

Question

I am trying to write a basic OS to better understand OS fundamentals and I am running into a strange problem. After switching to protected mode I jump into my kernel. In my kernel.cpp file I declare the following global variables (where IdtPointer_t and IdtEntry_t are both structs.)

IdtPointer_t idtPtr;
IdtEntry_t idtEntries[256];

This creates the idtPtr and idtEntries variables in the bss section. Then later in my code when I do the following

IdtEntry_t* entry = &idtEntries[0];

the value returned by &idtEntries[0] isn't the correct address. Using GDB I have done the following

p &idtEntries[0]
(IdtEntry_t *) 0x87a0 <idtEntries>
p entry
(IdtEntry_t *) 0x87e0 <idtEntries+64>

There is a 64 byte difference between the locations of the two variables. Why does referencing the variable return a different address than where the variable is stored in memory?

Also, I am running this using the qemu i386 emulator.

What happens if you change the order of declarations of `idtPtr` and `idtEntries`? — marko, Mar 25 '20 at 22:51
Are you changing `entry` between when you initialize it and when you look at it in gdb? A [mcve] would help. — dbush, Mar 25 '20 at 22:57
Could gdb be reporting this incorrectly - perhaps because you are compile optimised? — marko, Mar 25 '20 at 22:58

score 0 · Answer 1 · answered Mar 27 '20 at 15:07

Why does referencing the variable return a different address than where the variable is stored in memory? It does not. I strongly suspect that what GDB is displaying is not what you think it is displaying (although I'm no GDB expert).

Assuming you are developing this on a linux system, I suggest supplementing your observations with the output of 'nm' (or it's cross-compiler relative).

nm -n <elf file>

This will reliably give you a list of all the symbols in your kernel/OS and their addresses (sorted by numerical order). Then compare the addresses of 'idtEntries' and 'entry' against what you got in GDB.

Why do I get the wrong address when referencing a global variable?

1 Answers1