Re: [RFA 1/2] mips: Switch inferior function calls to ON_STACK method.

["Maciej W. Rozycki" <macro@codesourcery.com>]

On Wed, 9 May 2012, Mark Kettenis wrote:

> >  I have no strong opinion either way -- as we discussed both choices work 
> > equally well for the common cases and both have their corner-case 
> > advantages and disadvantages, none of which seem to directly hit any one 
> > of us.  What are the reasons for other targets we support to have chosen 
> > their particular way?
> 
> Not too long ago, Jan Kratochvil pointed out a problem with
> AT_ENTRY_POINT.  The entry point address might be covered by DWARF CFI
> embedded in the binary.  Now if the called function throws an
> exception, it will use this CFI to unwind the stack with potential
> disastrous consequences.  Now I'm not sure how serious that problem
> actually is; calling functions that throw exceptions from within GDB
> seems like a really bad idea in the first place (did I ever mention
> that C++ code is basically undebuggable? ;)).  But ON_STACK doesn't
> have this limitation.

 OK, that looks like an advantage that actually matters in practice.  So 
unless someone comes with a counterargument I think that we should go for 
this change.

 FWIW I don't find it unreasonable to manually call functions that can 
throw exceptions -- that's just a centralised error recovery mechanism 
that's alternative to the standard procedural language's series of IFs 
checking the error status after each relevant subprocedure call (or other 
action that could score as a failure) and bailing out if unsuccessful 
before proceeding with any further actions.

 It would make sense IMHO though if GDB was capable to catch that 
exception and report that the function returned with such rather than 
normally (if it already does not, that is -- I don't deal with C++ or 
other code using exceptions much, so I don't know).

  Maciej