enable stack canaries on ARC so we can run test_stackprot

[nashif]

Reported by Hirally Santiago:

Attempts to build nanokernel test_stackprot fail as stack canaries are not implemented on ARC architecture, nano_init.c does not build:

/projects/fc3/kernel/nanokernel/nano_init.c:207:2: error: #error "Unknown Architecture type"
 #error "Unknown Architecture type"
  ^
/projects/fc3/kernel/nanokernel/nano_init.c: In function '_Cstart':
/projects/fc3/kernel/nanokernel/nano_init.c:214:20: error: expected string literal before '_MOVE_INSTR'
   __asm__ volatile(_MOVE_INSTR "%1, %0;\n\t" \
                    ^
/projects/fc3/kernel/nanokernel/nano_init.c:263:2: note: in expansion of macro 'STACK_CANARY_INIT'
  STACK_CANARY_INIT();
  ^
make[4]: *** [kernel/nanokernel/nano_init.o] Error 1

(Imported from Jira ZEP-54)

[nashif]

by Inaky Perez-Gonzalez:

This is actually building in all the ARC platforms I have access to.

It succeeds runtime in the EM9d Synopsis Starter Kit (running to completion):

tc_start() - Test Stack Protection Canary
Starts main
Starts fiber1
fiber1: Input string is too long and stack overflowed!
***** Stack Check Fail! *****
Current thread ID = 0x800001d4
Faulting instruction address = 0x0000052c
Fatal fault in fiber ! Aborting fiber.
main: Stack ok
main: Stack ok
main: Stack ok
main: Stack ok
main: Stack ok
main: Stack ok
===================================================================
PASS - main.
===================================================================
RunID: :uwmh
PROJECT EXECUTION SUCCESSFUL

it however fails on Quark SE based platforms:

ipm_console0: 'tc_start() - Test Stack Protection Canary'
ipm_console0: ''
ipm_console0: 'Starts main'
ipm_console0: 'Starts fiber1'
ipm_console0: 'fiber1: Input string is too long and stack overflowed!'
ipm_console0: ''
ipm_console0: '***** Stack Check Fail! *****'
ipm_console0: 'Current thread ID = 0xa80004e0'
ipm_console0: 'Faulting instruction address = 0x00000000'
ipm_console0: 'Fatal fault in fiber ! Aborting fiber.'

[nashif]

by Mark Linkmeyer:

Anas Nashif , Inaky Perez-Gonzalez , what needs to happen next on this one? Per the ww24.2 backlog grooming meeting Anas got the AR to talk to Chuck Jordan to see if he can work on it. Is that still needed given Inaky's last comment? Thx. Gajinder Vij

[nashif]

by Anas Nashif:

Chuck, any feedback on this?

[nashif]

by Chuck Jordan:

I looked at this today, but I'm not sure what is going wrong. The file nano_init.c has this:

elif defined(CONFIG_ARC)

define _MOVE_INSTR "mov "

which should come in to play when building for the ARC CPU. arch/arc/defconfig sets CONFIG_ARC=y.

[nashif]

by Chuck Jordan:

I tried to reproduce this, but it is building for me. Can you try again. If you want to assign it back to me, tell me the exact arguments you gave to make. Thanks.

[nashif]

by Inaky Perez-Gonzalez:

You said it builds, no runtime testing, right?

We might need to close this and file a bug for the testcase failing in other ARC archiectures.

[nashif]

by Chuck Jordan:

There shouldn't be a build error for other ARC architectures, due to the use of the symbol CONFIG_ARC. So I'm thinking this reported build error was because a make clean wasn't done. Any ARC target would have CONFIG_ARC=y.

[nashif]

by Inaky Perez-Gonzalez:

Peter Mitsis Peter, can you guys work on this one?

[nashif]

by Peter Mitsis:

Unassigning myself as I just realized that we do not have any ARC boards, and thus can not test any potential work.

[nashif]

by Andrew Boie:

Peter Mitsis you guys don't have any Arduino 101 boards? Ben did the original ARC port, you must have some..

[nashif]

by Peter Mitsis:

Although Ben did the original ARC port, it was done "in the dark" without a board to test on.

Our current Arduino 101 boards are currently bricked and have been converted to paper weights.

More are on order for other non-ARC testing, but we don't know the current ETA.

[nashif]

by Chuck Jordan:

Btw, the problem described is a build error -- so technically you don't need a board. You can verify that things build now.