Thank you, that was what I suspected as well. I think I may have figured out the key though, but I don't quite understand why. When I turned on the -fPIC option, it did access a global variable correctly, but others it ended up writing to no man's land. Then I noticed that the one that it bombed on was a static. When I looked a little further, I realized those static variables are not identified in the linker map output. A ha! Unsigned char byRunning __attribute__((section(".bldata"))); //this one was part of the module compiled with -fPIC, and it was accessed correctly. Static CAN_MESSAGE dCANBuffer __attribute__((section(".bldata"))); //this is a typdefed structure, but it was static and was not accessed correctly. Is that the trick? Once I took out the static keyword, the second one did access correctly. So am I correct in learning that static variables within a module that is to be position-independent cannot be statics? On 2019-01-31 15:03 +0000, David Sherman wrote: > Is the global offset table section supposed to be relocated along with > the position-independent code so it stays at the same relative > location to the code? Yes. That's how GOT works. Or how can the code find it? -- Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx<mailto:xry111@xxxxxxxxxxxxxxxx>> School of Aerospace Science and Technology, Xidian University