Re: ARM position-independent code problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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





[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux