[rfc/rfa(top.c)] catch_exceptions()

[Andrew Cagney <ac131313@cygnus.com>]

Hello,

The attatched patch impements a successor to catch_errors() - 
catch_exceptions().  If you read all the FIXMEs  (appended), two 
alternatives are suggested:

>  When returning normally, i.e. without catching an error or a
> quit, catch_event() could return RETURN_NORMAL, which would be
> added to enum return_reason. FUNC would return information
> exclusively via ARGS.
> 
> Alternatively, normal catch_event() could return FUNC's return
> value. The caller would need to be aware of potential overlap
> with enum return_reason, which could be publicly restricted to
> negative values to simplify return value processing in FUNC and
> in the caller. */ [nsd]


I implemented the second.  For strictly arbitrary reasons.  I really 
don't remember which of the above was my preference when Nick added the 
above comment.

The new function:

	o	handles UIOUT
		(catch errors didn't)

	o	returns a catch indication
		(catch errors didn't)

	o	checks that the wrapped FUNC()
		compiles to certain basic
		requirements.
		(catch errors didn't)

I should note that the final version of this function depends on what 
happens to my previous patch.

The successor to this patch is to gdb.h where I'll add that missing 
uiout parameter to all the gdb client calls, after that is one to allow 
the MI to query the stop reason .....

Comments.  Any preference for the other.  Ok for top.c?

	Andrew

Ref: top.c

/* Call FUNC with arg ARGS, catching any errors.  If there is no
    error, return the value returned by FUNC.  If there is an error,
    print ERRSTRING, print the specific error message, then return
    zero.

    Must not be called with immediate_quit in effect (bad things might
    happen, say we got a signal in the middle of a memcpy to quit_return).
    This is an OK restriction; with very few exceptions immediate_quit can
    be replaced by judicious use of QUIT.

    MASK specifies what to catch; it is normally set to
    RETURN_MASK_ALL, if for no other reason than that the code which
    calls catch_errors might not be set up to deal with a quit which
    isn't caught.  But if the code can deal with it, it generally
    should be RETURN_MASK_ERROR, unless for some reason it is more
    useful to abort only the portion of the operation inside the
    catch_errors.  Note that quit should return to the command line
    fairly quickly, even if some further processing is being done.  */

/* MAYBE: cagney/1999-11-05: catch_errors() in conjunction with
    error() et.al. could maintain a set of flags that indicate the the
    current state of each of the longjmp buffers.  This would give the
    longjmp code the chance to detect a longjmp botch (before it gets
    to longjmperror()).  Prior to 1999-11-05 this wasn't possible as
    code also randomly used a SET_TOP_LEVEL macro that directly
    initialize the longjmp buffers. */

/* MAYBE: cagney/1999-11-05: Should the catch_errors and cleanups code
    be consolidated into a single file instead of being distributed
    between utils.c and top.c? */


   /* FIXME: cagney/1999-11-05: A correct FUNC implementation will
      clean things up (restoring the cleanup chain) to the state they
      were just prior to the call.  Unfortunately, many FUNC's are not
      that well behaved.  This could be fixed by adding either a
      do_cleanups call (to cover the problem) or an assertion check to
      detect bad FUNCs code. */

   /* Tell the caller that an event was caught.

      FIXME: nsd/2000-02-22: When MASK is RETURN_MASK_ALL, the caller
      can't tell what type of event occurred.

      A possible fix is to add a new interface, catch_event(), that
      returns enum return_reason after catching an error or a quit.

      When returning normally, i.e. without catching an error or a
      quit, catch_event() could return RETURN_NORMAL, which would be
      added to enum return_reason.  FUNC would return information
      exclusively via ARGS.

      Alternatively, normal catch_event() could return FUNC's return
      value.  The caller would need to be aware of potential overlap
      with enum return_reason, which could be publicly restricted to
      negative values to simplify return value processing in FUNC and
      in the caller. */

   /* FIXME: cagney/1999-11-07: Technically this do_cleanups() call
      isn't needed.  Instead an assertion check could be made that
      simply confirmed that the called function correctly cleaned up
      after itself.  Unfortunately, old code (prior to 1999-11-04) in
      main.c was calling SET_TOP_LEVEL(), calling the command function,
      and then *always* calling do_cleanups().  For the moment we
      remain ``bug compatible'' with that old code..  */
   do_cleanups (ALL_CLEANUPS);
From jimb@zwingli.cygnus.com Mon Aug 13 14:29:00 2001
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: correctly detect overlapping overlays
Date: Mon, 13 Aug 2001 14:29:00 -0000
Message-id: <npitfrtzos.fsf@zwingli.cygnus.com>
References: <20010812184312.C90245E9DA@zwingli.cygnus.com> <3B7737C3.8070805@cygnus.com> <npofpkt44n.fsf@zwingli.cygnus.com> <3B77FB42.6050005@cygnus.com>
X-SW-Source: 2001-08/msg00145.html
Content-length: 800

Andrew Cagney <ac131313@cygnus.com> writes:
> > But I do think it's a shame.  When layout can expose symmetry in what
> > you're doing, it makes it easier to read the code.
> 
> 
> Order it as:
> 
> 	start_a
> 	start_b
> 	end_a
> 	end_b

(Surely this horse isn't dead yet...)

Then you don't have the a->vma terms lining up, which show off the
fact that all the values are based on the section's VMA address.

Basically, there are two axes of symmetry: the fact that the *_a
computations are the same as those for *_b, and the fact that both the
end addresses are just the start addresses plus the size.  There's no
ordering that will show off both symmetries without custom
indentation.

But really, your change is fine with me.  I think the ability to
mechanically re-indent the code is valuable.