This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
RE: Customizable `__stack_chk_fail` implementation
- From: Łukasz Żak <lzak at kplabs dot pl>
- To: Freddie Chopin <freddie_chopin at op dot pl>, "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Wed, 16 Oct 2019 16:52:29 +0000
- Subject: RE: Customizable `__stack_chk_fail` implementation
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=kplabs.pl; dmarc=pass action=none header.from=kplabs.pl; dkim=pass header.d=kplabs.pl; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bg0cldsm1XBWZamRT1t1xL5DaV0V/0d7q3dbvP4f/HU=; b=S0lZ8qnrRLe3S2yA953d5asTujyEdO3O6huTKVfjaEE8UJYoUdlHI57qBjlRYILpGGGrSwAXVgXMiewwyQX5qoJIAwyAikJV5wvQRoW1sDHbLpVdNGyVf9+FK750gmXIW3Uioeiv1BDYSvaTHh9TVIa/sO8Pg6eWYsrrk+1VngxhAVu+n/6wEmo80RZ4CGOfRjVjuqD+gBhikdbsyt9lmpFjiB4IY6CSDDnro/y/lEiNLBhg10jtAy2Xtx9gDRk7tZ2R0ic7x3LsmQrEhVEPZVvP9lJSs51SYwnFSzchAhTSbJNhht8SNN/u/vfSnm15nVV+pmR+7Mow0VO9VAG/8Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KGcLslsc381QVY3tJKOnB7wHjiZdeMHAeL9AXjavyhWmYPfBZU5w51IFN5/XFy1IXNWCaaMERMIoJFVqBeFzWGx4TXHU9ecQJH8F9up10mRystBjdl1sAxnLMdQyqHBcvs47kBk23nA2xY8sc0DxJYFZvrttEDly4hf0XuUGPF4sGtgdEI+mNrdYKAWNza5Gil+QNHftp+dk29Pw2q4GTW9yUG3h5S19UFK/scNXXLoJ/qv73aLjrLIo0rWHDQOEunTpZnei65EvQh7MYk2zixXUju/NWTJubICDb9nu5fCMJ5Jv3sh6i+VRqbUsx+9hj94DdGrPRAqRJYpHUxqCLA==
- References: <VI1PR10MB1965AB01696D3C536E8DCD46D3930@VI1PR10MB1965.EURPRD10.PROD.OUTLOOK.COM> <b7721b05263a68ebd536d8b50c67fbecc05eb10d.camel@op.pl>
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