On 01/02/2019 15:05, David Sherman wrote:
>
>
> 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!
>
Maybe that's because your linker script doesn't consider those sections ?
In general statics should also be accessed in a position independent
manner with -fPIC and I believe the backend does this usually.
>
>
> 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?
>>
>>
static variables within a module should also be accessed in a position
independent manner.
In general we would be doing the right thing here the options to use the
PIC stuff is generally reasonably stable and should be so for most
simple cases. As Andrew says maybe there's a bug here but no one can
comment because we are looking at it with partial information and
guessing based on what's visible on your computer screen :)
However since you aren't showing us a self-contained testcase with steps
for someone to reproduce this. Please consider filing a self-contained
testcase as described here
https://gcc.gnu.org/bugs
regards
Ramana
