public inbox for java-prs@sourceware.org
help / color / mirror / Atom feed
From: "mikpe at it dot uu dot se" <gcc-bugzilla@gcc.gnu.org>
To: java-prs@gcc.gnu.org
Subject: [Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux
Date: Wed, 31 Mar 2010 21:44:00 -0000	[thread overview]
Message-ID: <20100331214359.24575.qmail@sourceware.org> (raw)
In-Reply-To: <bug-40860-5724@http.gcc.gnu.org/bugzilla/>



------- Comment #32 from mikpe at it dot uu dot se  2010-03-31 21:43 -------
(In reply to comment #31)
> There appears to be a mistaken presumption running through this thread that
> there is a 1<->1 mapping between unwind blocks and source language functions. 
> This is not the case, and any code written with such a presumption is just
> wrong code.

Just to clarify: I'm not defending the parts of gcc that depend on the fact
that gcc's ARM EABI backend has implemented _Unwind_GetRegionStart.  I'm just
trying to explain that those dependencies currently do exist.

> 4) The ARM frame-unwinding annotations are designed to unwind C++ exceptions. 
> If they don't work outside that specification that does not make them wrong;
> they simply weren't designed for the other (mis-)uses to which some people are
> trying to put them.

The extreme logical conclusion is that gcc's ARM backend shouldn't even pretend
to implement _Unwind_GetRegionStart, as Paul suggested.  Doing that in an
arm-linux-gnueabi cross-compiler causes compile-time breakage for most
languages including C++.

A less extreme conclusion is to make _Unwind_GetRegionStart always return 0. 
That solves the compile-time dependencies but not the functional ones (however
technically invalid they are).  Ignoring libjava's stacktrace module the
functional dependencies are all the same: LSDA blobs attached to exception
table entries are in DWARF format and contain deltas for landing pads relative
to the enclosing function entry.  GCC assumes that _Unwind_GetRegionStart
works, so always outputs a dummy @LPStart in the LSDA
(output_function_exception_table in gcc/except.c); at runtime the PRs' LSDA
parsers check if @LPStart is encoded as a dummy or a proper value, if it's a
dummy they set it to the return value of _Unwind_GetRegionStart.  Even the
libstdc++ unwinder does this and thus depends on _Unwind_GetRegionStart on ARM
EABI.

So to eliminate the functional dependency on _Unwind_GetRegionStart we have to
instruct output_function_exception_table to output a proper @LPStart with each
LSDA blob not a dummy one.  I'll look into that next.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860


  parent reply	other threads:[~2010-03-31 21:44 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-26 10:51 [Bug libgcj/40860] New: " debian-gcc at lists dot debian dot org
2009-07-29 23:07 ` [Bug libgcj/40860] " jsm28 at gcc dot gnu dot org
2009-10-15 12:54 ` jakub at gcc dot gnu dot org
2010-01-21 13:16 ` jakub at gcc dot gnu dot org
2010-01-24 16:04 ` mikpe at it dot uu dot se
2010-01-25  9:33 ` mikpe at it dot uu dot se
2010-02-03 14:51 ` mikpe at it dot uu dot se
2010-02-05 15:40 ` mikpe at it dot uu dot se
2010-02-06 15:36 ` mikpe at it dot uu dot se
2010-02-13 20:49 ` mikpe at it dot uu dot se
2010-02-15 15:32 ` doko at ubuntu dot com
2010-02-15 22:26 ` mikpe at it dot uu dot se
2010-02-16 16:34 ` doko at ubuntu dot com
2010-02-19 23:32 ` mikpe at it dot uu dot se
2010-02-22 21:49 ` mikpe at it dot uu dot se
2010-02-28 10:07 ` aph at gcc dot gnu dot org
2010-03-04 10:17 ` mikpe at it dot uu dot se
2010-03-15  9:09 ` mikpe at it dot uu dot se
2010-03-15  9:16 ` rearnsha at gcc dot gnu dot org
2010-03-16 13:42 ` doko at ubuntu dot com
2010-03-16 17:29 ` mikpe at it dot uu dot se
2010-03-16 23:30 ` doko at ubuntu dot com
2010-03-16 23:39 ` mikpe at it dot uu dot se
2010-03-17 10:51 ` doko at ubuntu dot com
2010-03-17 21:13 ` mikpe at it dot uu dot se
2010-03-17 21:23 ` mikpe at it dot uu dot se
2010-03-19 23:20 ` mikpe at it dot uu dot se
2010-03-20 18:54 ` ramana at gcc dot gnu dot org
2010-03-20 22:10 ` mikpe at it dot uu dot se
2010-03-20 22:36 ` mikpe at it dot uu dot se
2010-03-22 23:48 ` rearnsha at gcc dot gnu dot org
2010-03-30 13:21 ` mikpe at it dot uu dot se
2010-03-30 14:04 ` pbrook at gcc dot gnu dot org
2010-03-30 15:09 ` mikpe at it dot uu dot se
2010-03-31  8:47 ` rearnsha at gcc dot gnu dot org
2010-03-31 21:44 ` mikpe at it dot uu dot se [this message]
2010-04-08 12:14 ` [Bug libgcj/40860] [4.4/4.5/4.6 " mikpe at it dot uu dot se
2010-04-12 19:03 ` mikpe at it dot uu dot se
2010-04-13 16:36 ` aph at gcc dot gnu dot org
2010-04-13 16:52 ` mikpe at it dot uu dot se
2010-04-13 17:02 ` aph at redhat dot com
2010-04-13 17:25 ` aph at gcc dot gnu dot org
2010-04-21 16:34 ` aph at gcc dot gnu dot org
2010-04-21 17:05 ` aph at gcc dot gnu dot org
2010-04-22 16:07 ` aph at gcc dot gnu dot org
2010-04-22 16:08 ` aph 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=20100331214359.24575.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=java-prs@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).