From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24601 invoked by alias); 31 Mar 2010 21:44:00 -0000 Received: (qmail 24576 invoked by uid 48); 31 Mar 2010 21:43:59 -0000 Date: Wed, 31 Mar 2010 21:44:00 -0000 Message-ID: <20100331214359.24575.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "mikpe at it dot uu dot se" Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org X-SW-Source: 2010-q1/txt/msg00189.txt.bz2 ------- 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