zephyrproject-rtos / meta-zephyr-sdk

Zephyr SDK (obsolete)
MIT License
44 stars 29 forks source link

tests/kernel/test_multilib/ failed on EMSK/ARC #53

Closed zephyrbot closed 7 years ago

zephyrbot commented 7 years ago

Reported by Inaky Perez-Gonzalez:

Random issue, found in master

$ git checkout be1dd33053f7fa731b4950d0113d9eb8a72926ac

***********************************

**===================================Exception vector: 0x00000008, cause code: 0x00000000, parameter 0x0000002f
Address 0x80000030
Fatal fault in essential thread! Spinning...

(Imported from Jira SDK-34)

zephyrbot commented 7 years ago

by Sharron LIU:

Juro Bystricky could you check if the multilib is properly selected? The error message shown in this issue is similar to the one mentioned in the "README.rst", which suggesting mis-uage of multilib.

zephyrbot commented 7 years ago

by Juro Bystricky:

The libraries that are actually used depend on the compiler flags (lbc, libgcc, ...). The association between compiler options and various libraries is as follows:

{{$ ./arc-poky-elf-gcc -print-multi-lib .; em;@mcpu=em arcem;@mcpu=arcem em4;@mcpu=em4 em4_dmips;@mcpu=em4_dmips em4_fpus;@mcpu=em4_fpus em4_fpuda;@mcpu=em4_fpuda quarkse_em;@mcpu=quarkse_em hs;@mcpu=hs archs;@mcpu=archs hs34;@mcpu=hs34 hs38;@mcpu=hs38 hs38_linux;@mcpu=hs38_linux arc600;@mcpu=arc600 arc600_norm;@mcpu=arc600_norm arc600_mul64;@mcpu=arc600_mul64 arc600_mul32x16;@mcpu=arc600_mul32x16 arc601;@mcpu=arc601 arc601_norm;@mcpu=arc601_norm arc601_mul64;@mcpu=arc601_mul64 arc601_mul32x16;@mcpu=arc601_mul32x16 arc700;@mcpu=arc700 }}

These are the options used by Zephyr:

soc-cflags = $(call cc-option,-mARCv2EM) $(call cc-option,-mav2em,) $(call cc-option,-mno-sdata)

(I don't know where they originate from). So only if wrong compiler options are used can a wrong library be used.

There is a rather older page that elaborates on various ARC/GCC options: [https://gcc.gnu.org/onlinedocs/gcc/ARC-Options.html]

I would probably advocate to use -mcpu option instead of -mARCv2EM (-mARCv2EM is deprecated in later compilers):

Known ARC CPUs (for use with the -mcpu= option): arc600 arc600_mul32x16 arc600_mul64 arc600_norm arc601 arc601_mul32x16 arc601_mul64 arc601_norm arc700 arcem archs em em4 em4_dmips em4_fpuda em4_fpus hs hs34 hs38 hs38_linux quarkse_em

(I think EMSK should set -mcpu=em based on the fact thatt ARC EM4, ARC EM5D and ARC EM6 processors are subsets of ARC EM7D processor. So software may be built for ARC EM4, ARC EM5 or ARC EM6 processors but then run on the ARC EM7D processor configuration on the starter kit)

While on the subject, the -mcpu options should be modified for for quark_se_c1000_ss as well.

For completeness, these are all ARC/GCC options for SDK 0.8.2:

{{The following options are target specific: -EB [disabled] -EL [disabled] -mA6 [disabled] -mA7 [disabled] -mARC600 [disabled] -mARC601 [disabled] -mARC700 [disabled] -mARCv2EM [disabled] -mARCv2HS [disabled] -mEA [disabled] -mEM [disabled] -mHS [disabled] -mRcq [disabled] -mRcw [disabled] -mabi= std -mannotate-align [disabled] -marc600 [disabled] -marc601 [disabled] -marc700 [disabled] -marcem [disabled] -marchs [disabled] -margonaut [disabled] -matomic [disabled] -mauto-modify-reg [disabled] -mav2em [disabled] -mav2hs [disabled] -mbarrel-shifter [disabled] -mbbit-peephole [enabled] -mbig-endian [disabled] -mbypass-cache [disabled] -mcase-vector-pcrel [disabled] -mcode-density [disabled] -mcompact-casesi [disabled] -mcpu= [default] -mcrc [disabled] -mdiv-rem [disabled] -mdpfp [disabled] -mdpfp-compact [disabled]
-mdpfp-fast [disabled]
-mdsp-packa [disabled]
-mdvbf [disabled]
-mearly-cbranchsi [enabled]
-mexpand-adddi [disabled]
-mfpu= [default]
-mindexed-loads [disabled] -mirq-ctrl-saved=
-misize [disabled] -mlittle-endian [enabled] -mll64 [disabled] -mlock [disabled] -mlong-calls [disabled] -mlra-priority-compact [disabled] -mlra-priority-noncompact [disabled] -mlra-priority-none [enabled] -mmac-24 [disabled] -mmac-d16 [disabled] -mmedium-calls [disabled] -mmixed-code [disabled] -mmpy [disabled] -mmpy-option=
-mmpy16 [disabled] -mmul32x16 [disabled] -mmul64 [disabled] -mno-brcc [disabled] -mno-cond-exec [disabled] -mno-dpfp-lrsr [disabled] -mno-millicode [disabled] -mnorm [disabled] -mq-class [disabled] -mrgf-banked-regs=
-mrtsc [disabled] -msdata [enabled] -msimd [disabled] -msize-level= 0x1 -msoft-float [disabled] -mspfp [disabled] -mspfp-compact [disabled] -mspfp-fast [disabled] -mswap [disabled] -mswape [disabled] -mtelephony [disabled] -mtls [disabled] -mtls9 [disabled] -mtp-regno= 0x19 -mtp-regno=none [disabled] -mtune= [default] -mucb-mcount [disabled] -multcost= 0xffffffff -mvolatile-cache [enabled] -mxy [disabled]

}}

zephyrbot commented 7 years ago

by Juro Bystricky:

In addition (and this could be the real culprit) the GCC for ARC can generate incorrect code: [https://jira.zephyrproject.org/browse/ZEP-1243]

There is a workaround in Gerrit [https://gerrit.zephyrproject.org/r/#/c/8717/1]

Basically, an interrupt can come at a time when a frame pointer and stack are misaligned, resulting in stack being corrupted after the interrupt is done -> leading to exception.

zephyrbot commented 7 years ago

by Mark Linkmeyer:

Per review with Juro Bystricky , this is fixed.

zephyrbot commented 7 years ago

Related to ZEP-1342