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

["rearnsha at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #31 from rearnsha at gcc dot gnu dot org  2010-03-31 08:47 -------
(In reply to comment #30)
> (In reply to comment #29)
> > Wouldn't it be better to just remove _Unwind_GetRegionStart?
> > This function is not part of the ARM EABI, and removing it would expose any
> > (already broken) users at compile time.
> 
> No.
> 
> First it'd break most of gcc since the c, c++, and objc unwinders use it. And
> they generally use it to provide a base address when interpreting LSDA and
> computing landing pad addresses.
> 
> Second, all _Unwind_GetRegionStart does is give r/o access to the fnstart value
> in ARM's UCB.  But ARM's own unwinder uses fnstart in __gnu_unwind_pr_common,
> so if fnstart is broken then so it ARM's unwinder.
> 
> ARM's unwinder is in the same boat as the c/c++/objc ones.  It works because
> .ARM.exidx merging is limited to immediate table data, but the code using
> fnstart (by luck or design) only runs when the table contains non-immediate
> data, and in those cases fnstart is accurate.
> 

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 because such behaviour may work on other machines does not make the
presumption correct or the ARM unwinding code wrong.

1) Compilers may inline functions.  If they do so, then unwind blocks will get
merged.

2) Compilers may create extra frames (though currently rarely).  If they do,
then a function may have more than one frame.

3) They may do some combination of the above.

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.

Source language code is run on an abstract machine.  When it's mapped onto real
hardware the reality can be very different.  You can't rely on the two
corresponding directly beyond the semantics of the language.


-- 


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