This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] m68k: fix clobbering a5 in setjmp() [BZ #24202]
- From: Nick Alcock <nix at esperi dot org dot uk>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Sergei Trofimovich <slyfox at gentoo dot org>, libc-alpha at sourceware dot org, Andreas Schwab <schwab at suse dot de>, James Le Cuirot <chewi at gentoo dot org>, Andreas Schwab <schwab at linux-m68k dot org>
- Date: Mon, 25 Feb 2019 17:47:43 +0000
- Subject: Re: [PATCH] m68k: fix clobbering a5 in setjmp() [BZ #24202]
- References: <email@example.com> <firstname.lastname@example.org>
On 24 Feb 2019, Florian Weimer uttered the following:
>> setjmp() uses C code to store current registers into jmp_buf
>> environment. -fstack-protector-all places canary into setjmp()
>> prologue and clobbers 'a5' before it gets saved.
>> The change inhibits stack canary injection to avoid clobber.
>> [BZ #24202]
>> * sysdeps/m68k/setjmp.c (*setjmp): Use
> The code is still invalid. The C compiler can still clobber any
> register it wants. So this does not actually fix the bug. But I think
> it's an incremental improvement.
I'd say it's in the same state as pthread_cond_wait() et al were in on
i386 before 7a25d6a84df9fea56963569ceccaaf7c2a88f161: works with the
compiler as it is now, by sheer good fortune.
To me this feels like code that can't really be written in C safely, but
it's so arch-dependent that having it depend on the compiler not
emitting anything else in the prologue is probably not *too* likely to
break. But we should probably add the reproducer for this to glibc's
'make check' to stop it regressing again.