''relocation truncated to fit: R_PPC_VLE_REL24'' when placing function in .data section

[davedave95]

Posted on March 06, 2017 at 21:26

Hello,

Trying to make a workaround for the flash-not-ready-after-leaving-power-saving problem, I am placing the below function in a section which goes into the .data section:

__attribute__ (( __section__ ('halt'))) void halt0(void)

{ ME.HALT0.B.CFLAON = ME.RUN[0].B.CFLAON = 1; ME.HALT0.B.DFLAON = ME.RUN[0].B.DFLAON = 1; ME.MCTL.R = SPC5_ME_MCTL_MODE(SPC5_RUNMODE_HALT0) | SPC5_ME_MCTL_KEY; ME.MCTL.R = SPC5_ME_MCTL_MODE(SPC5_RUNMODE_HALT0) | SPC5_ME_MCTL_KEY_INV; while(ME.GS.B.S_MTRANS); ME.RUN[0].B.CFLAON = 3; ME.RUN[0].B.DFLAON = 3; ME.MCTL.R = SPC5_ME_MCTL_MODE(SPC5_RUNMODE_RUN0) | SPC5_ME_MCTL_KEY; ME.MCTL.R = SPC5_ME_MCTL_MODE(SPC5_RUNMODE_RUN0) | SPC5_ME_MCTL_KEY_INV; while(ME.GS.B.S_MTRANS);}

Calling this function from code in the .text segment cause the linker to fail with the message

relocation truncated to fit: R_PPC_VLE_REL24 against symbol `halt0' defined in flop section in arch/spc560/halt0.o

The exact reason for this error is not clear to me, as it is quite cryptic.

However - and this is the strange part - if I adjust the function and take out some code, the object compiles and links just fine. For example, remove the last 3 lines, and the problem is gone.

Can anyone explain what exactly causes the error message, and if there is a workaround for this?

[davedave95]

Posted on March 06, 2017 at 21:43

As a side note, I can trick the compiler in calling this function just fine like this:

        volatile ptrdiff_t n = 0;

        void (*fn)(void) = halt0 + n;        fn();

[Erwan YVIN]

Posted on March 08, 2017 at 16:57

Hello Gert ,

it seems to be a too long jump

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61972

Did you use Freegcc Vle ?

Could you send me your compilation directive ?

Do you use optimization level ?

There is a post along that.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61972

 

   Best regards

                     Erwan

[davedave95]

Posted on March 09, 2017 at 10:38

The jump itself should be no problem for the cpu, but it seems that the linker is confused trying to fix up the relocation.

Relevant compiler flags:

powerpc-eabivle-gcc

-O2-falign-functions=16-msoft-float-Wno-pointer-to-int-cast-mcpu=e200z0-meabi-msdata=none-mregnames-mvle-mno-spe

Compiler is powerpc-eabivle-gcc (GCC) 4.9.2 20141030, linker is GNU ld (GNU Binutils) 2.24.90.20141014

My workaround to calculate the function address at runtime using a volatile trick does not work when optimization is disabled (-O0), in this case the same error is reported.

[davedave95 · Accepted solution]

Posted on May 03, 2017 at 18:58

Found solution gcc documentation:

__attribute__((longcall))

does the trick