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


             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: link
Be 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).