From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: gdb-patches@sources.redhat.com Subject: [rfc/rfa(top.c)] catch_exceptions() Date: Mon, 13 Aug 2001 13:43:00 -0000 Message-id: <3B783BC9.8030603@cygnus.com> X-SW-Source: 2001-08/msg00144.html 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 To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: correctly detect overlapping overlays Date: Mon, 13 Aug 2001 14:29:00 -0000 Message-id: References: <20010812184312.C90245E9DA@zwingli.cygnus.com> <3B7737C3.8070805@cygnus.com> <3B77FB42.6050005@cygnus.com> X-SW-Source: 2001-08/msg00145.html Content-length: 800 Andrew Cagney 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.