public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "drow at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/14202] New: [arm] Thumb __builtin_setjmp not interworking safe Date: Wed, 18 Feb 2004 23:05:00 -0000 [thread overview] Message-ID: <20040218230529.14202.drow@gcc.gnu.org> (raw) There are two problems. The first is simple, indirect jumps don't use bx. arm_indirect_jump and thumb_indirect_jump are the only affected patterns, the "fix" is obvious. The second is triggered by that fix. __builtin_setjmp works by saving the address of a label, and later jumping to it in __builtin_longjmp. The label has its low bit clear; if I fix the arm_indirect_jump to use bx, then the bx will set us back into ARM mode. So if the exception is thrown from ARM code and caught in Thumb code, we'll get illegal instructions all over the place when we return to the Thumb code. With the use of bx this is probably true for exceptions within Thumb code also. The obvious thing to do would be to mark the low bit of the label. I couldn't make gas do it; it explicitly rejects .thumb_func for local labels. If I use .thumb_set then it looks like the result will work, but the label becomes a symbol and clutters up disassembly. An alternative would be to explicitly or the lower bit of the label. It could be done at runtime in builtin_setjmp_setup or at compiletime by emitting .word L12 + 1 instead of .word L12 which would require a change to expand_builtin_setjmp. Here's the trivial testcase I've been using. int main () { try { throw 1; } catch (int) { return 0; } catch (...) { return 0; } return 1; } -- Summary: [arm] Thumb __builtin_setjmp not interworking safe Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drow at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14202
next reply other threads:[~2004-02-18 23:05 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-02-18 23:05 drow at gcc dot gnu dot org [this message] 2004-02-19 0:15 ` [Bug target/14202] " drow at gcc dot gnu dot org 2004-02-19 1:23 ` pinskia at gcc dot gnu dot org 2004-02-19 12:01 ` rearnsha at gcc dot gnu dot org 2004-02-19 12:02 ` rearnsha at gcc dot gnu dot org 2004-02-19 14:56 ` drow at gcc dot gnu dot org 2004-02-19 15:30 ` Richard Earnshaw 2004-02-19 15:30 ` rearnsha at arm dot com 2004-02-19 17:51 ` drow at gcc dot gnu dot org 2004-10-11 10:57 ` giovannibajo at libero dot it 2005-07-02 1:31 ` pinskia at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20040218230529.14202.drow@gcc.gnu.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).