gcc builds use linker scripts with both _f_sdata and __SDATA_BEGIN__.
Normally they are the same in our scripts.
Native GNU toolchain startup uses __SDATA_BEGIN__ to configure %GP register.
But embARC startup sticks to MWDT agreement and uses _f_sdata.
This works ok until user decides to put __SDATA_BEGIN__ in the middle of the section to extend it's range.
(GP-based offset is signed). And linker uses __SDATA_BEGIN__ to calculate relocations and actual offsets.
So when user changes related line in the script to something like this - __SDATA_BEGIN__ = . + 0x100;
small data access becomes wrong. Runtime offsets will be 0x100 less (easily driving into negative zone),
while startup still sets %GP to the beginning of small data section.
Question
Is it possible to change arc_startup.s in a way that for GCC builds it will choose __SDATA_BEGIN__ for GP?
Issue Summary
Bug
Development Environment
HOST OS All OS
TOOLCHAIN ARC GNU 2020.03=9.
BOARD Customer's board, irrelevant.
ARC CORE EM9D.
Bug Description
gcc builds use linker scripts with both
_f_sdataand__SDATA_BEGIN__. Normally they are the same in our scripts. Native GNU toolchain startup uses__SDATA_BEGIN__to configure %GP register. But embARC startup sticks to MWDT agreement and uses_f_sdata.This works ok until user decides to put
__SDATA_BEGIN__in the middle of the section to extend it's range. (GP-based offset is signed). And linker uses__SDATA_BEGIN__to calculate relocations and actual offsets.So when user changes related line in the script to something like this -
__SDATA_BEGIN__ = . + 0x100;small data access becomes wrong. Runtime offsets will be 0x100 less (easily driving into negative zone), while startup still sets %GP to the beginning of small data section.Question
Is it possible to change arc_startup.s in a way that for GCC builds it will choose
__SDATA_BEGIN__for GP?