This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]