Ping [ARM back-end and middle-end patch] stack check for threads

[Thomas Klein]

ping


At the ARM platform the old generic options is working as before.

is switched on.)

also working, too.
This was not the case due to missing trap function.

doing a compare against a given limit value.
I'm treating this as keeping old stuff alive.

Back to my new options I like to have here.
Maybe you are happy with the above, but I'm not.
Sometimes you do not have a one single limit value that is valid for all.

its own stack at an different location.

which is holding the limit value.


There are two ways to inform the compiler about this limit variable.

 use the option combination
 -fstack-check=indirect and -fstack-limit-symbol=global_stack_limit

 If it is a register global variable you should use the option combination
 -fstack-check=direct} and -fstack-limit-register=r6

 For example you can add the option -ffixed-r6 to all files that are
 not going to do stack checking.
The OS is responsible to insert the correct limit value.
For example at the end of a context switch.

I've added a little bit of documentation, too.
This may not be as god as you expect, but it the best I can do.
Sorry for that.


and running tests with:
gmake check-gcc RUNTESTFLAGS="--target_board=arm-sim arm_stack_check.exp"

gmake check-gcc RUNTESTFLAGS="arm_stack_check.exp"

Each test case is done with:
- stack checking variants
  generic using a limit-symbol, generic using a limit register,
  direct using a limit-symbol, direct using a limit register and
  indirect using a limit-symbol
- various modes ARM, Thumb, (and if possible with Thumb-2)
- With and without optimization.
- Without -fpic, with -fpic and with -fpic -msingle-pic-base

I have also detected a minor bug if using combination:
-fpic -mpic-register=r9 -march=armv4t -mthumb.
(A move of the hi register to a lo register is missing here.)
So I've added the few lines of code in here, too.
Maybe you think that this is a nasty hack, so insert a better one instead.

All tests succeeds.

I'm still thinking that my idea isn't that bad.
How ever any feedback from the ARM maintainers would be god.
Even if is something like: "We hate this bull shit at all."
Any feedback is better than no feedback.

Regards
  Thomas Klein

references
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01261.html
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00310.html
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00216.html
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00281.html
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00149.html
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01872.html
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01226.html

I would like to introduce two new -fstack-check options named direct and indirect. Targets that did not supporting the new stack checking options will work as before. (Including that is now possible to have a checking code sequence even if optimization The check against a given limit value while doing dynamic stack allocation is now For this case I've added a code sequence to let "generic" act like the dynamic part For example if you are having an environment with threads and each threads is using In case all functions should have a common knowledge about a global limit variable This limit value can be used to check if a stack overflow has occurred or not. If it is an ordinary variable (located somewhere in data space) you should In this case you have to make sure that this register isn't be used by others. I have added some tests running on arm simulator and linux arm target machine. I'm using ../src/configure --target=arm-elf and --target=arm-elf-eabi cross compilers Also using a native linux compiler (on armv7-a machine) and running tests with:

ChangeLog.check.bz2
Description: Binary data

gcc.diff_chk.bz2
Description: Binary data

gcc.diff_dep.bz2
Description: Binary data

ChangeLog.test.bz2
Description: Binary data

gcc.diff_test.bz2
Description: Binary data