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