From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24448 invoked by alias); 9 Apr 2009 11:31:36 -0000 Received: (qmail 24354 invoked by uid 48); 9 Apr 2009 11:31:26 -0000 Date: Thu, 09 Apr 2009 11:31:00 -0000 Message-ID: <20090409113126.24353.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/14202] [arm] Thumb __builtin_setjmp not interworking safe In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "ramana at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-04/txt/msg00820.txt.bz2 ------- Comment #12 from ramana at gcc dot gnu dot org 2009-04-09 11:31 ------- For the record here's some more info on the problem. One part of the problem is as described in comment #1 about labels having the right bit and the correct instruction being generated which I've achieved by a method inspired by Richard to mark setjmp receiver labels as STT_FUNC. The other part of the problem however is that the frame pointer registers for ARM state and Thumb state are different. Hence if you did a setjmp from an ARM state function and you did a longjmp from a Thumb state function, the problem would also be restoring the "correct" frame pointer. I've tried to solve this problem by storing r7 and r11 at fixed locations in the jmpbuf and restoring them unconditionally from the "correct location" in the corresponding builtin_longjmp pattern. I am currently testing a patch for this. The other idea I had was to check for the lower bit of the label being restored for Thumb"ness" and then load the appropriate frame pointer. Kludgy but that might be the path of least risk to get this truly fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14202