ARM position-independent code problem

[David Sherman]

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@mengyan1223.wang<mailto:xry111@mengyan1223.wang>>

School of Aerospace Science and Technology, Xidian University