Customizable `__stack_chk_fail` implementation

[Łukasz Żak]

Thank you for pointing out such an obvious mistake in my assumptions.  Regarding the hooking 
`__stack_chk_fail` the only way to intercept stack check failures is at `_exit` handler level 
where the fact of unexpected (and ultimately invalid anyway) call has been made? 
If there is no other way it, of course, can be done but I was hoping, that such failures could be 
intercepted sooner and handled differently.  

Regards,
Łukasz Żak 

-----Original Message-----
From: Freddie Chopin <freddie_chopin@op.pl> 
Sent: Tuesday, October 15, 2019 1:44 PM
To: Łukasz Żak <lzak@kplabs.pl>; newlib@sourceware.org
Subject: Re: Customizable `__stack_chk_fail` implementation

On Tue, 2019-10-15 at 10:25 +0000, Łukasz Żak wrote:
> When however I build and run the same sources for real hardware the 
> problems are detected - I can observe the calls to `__stack_chk_fail` 
> with the gdb but as there is no semihosting available the write/_exit 
> procedures used by the `__stack_chk_fail` handler are basically noops 
> as they should be as on real hardware there is no standard output (at 
> least in my case) and there is nothing to exit to.

While this is true for _write(), it's wrong for _exit(), which should _NOT_ return.

This is how a stub for _exit() should look like (code from my C++ RTOS for ARM microcontrollers):
https://github.com/DISTORTEC/distortos/blob/6c1e232f777284f6ecb935b7f2e94faba6174860/source/newlib/syscallsStubs.cpp#L57

It may reset your chip, it may print/log whatever you want, send you an e-mail or print something on LCD, but it should never ever return.

Regards,
FCh