From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Sat, 23 Sep 2017 02:48:52 +0200 Subject: [U-Boot] [PATCH v3 3/6] arm: provide a PCS-compliant setjmp implementation In-Reply-To: <1505981969-49480-4-git-send-email-philipp.tomsich@theobroma-systems.com> References: <1505981969-49480-1-git-send-email-philipp.tomsich@theobroma-systems.com> <1505981969-49480-4-git-send-email-philipp.tomsich@theobroma-systems.com> Message-ID: <10f7c0bb-1e28-8f15-8bea-db207f3efbbd@suse.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 21.09.17 10:19, Philipp Tomsich wrote: > The previous setjmp-implementation (as a static inline function that > contained an 'asm volatile' sequence) was extremely fragile: (some > versions of) GCC optimised the set of registers. One critical example > was the removal of 'r9' from the clobber list, if -ffixed-reg9 was > supplied. I wouldn't call that fragile, but "works as intended". Gcc only saves the registers it really needs to save - and if r9 is fixed it can safely assume that between setjmp/longjmp it did not change. Did you encounter other cases where it did something wrong? > To increase robustness and ensure PCS-compliant behaviour, the setjmp > and longjmp implementation are now in assembly and closely match what > one would expect to find in a libc implementation. I'm personally quite indifferent on which version we take, but I personally found the inline asm version more readable. At least it was half-way self-documenting and struct offset independent ;). But again, I really don't have strong feelings. I only wrote the inline asm version because we didn't have any implementation at all. If you opt to maintain yours, be my guest :). Alex