[01/15,v3] Introduce common/errors.h

  Doug Evans wrote:
> fatal is a confusing name IMO.  In gdb it just throws RETURN_QUIT.
> That's not your fault of course, but I wonder if I can trouble you
> to expand on the function comment a bit.  E.g., something like the
> following?
> 
> /* Cause a fatal error.
>    What this does in gdb is throw a RETURN_QUIT exception.  */
> 
> One could expand on the comment, but I didn't want to turn it into
> a FIXME.  [which is really what it should be, but that's a topic
> for another patch :-)]

I have rewritten the documentation on all these functions.  I don't
want to mention details of GDB's and/or gdbserver's implementation
in this file, so what I have done is described what callers should
expect the functions to do.  I hope this is clear enough.

> It's odd to separate out fatal and not vfatal.
> [ditto for the others]
> Can you add vfatal, et.al. to this patch?

I've done that now.  I made the non-v-prefixed functions part of
the common codebase; users of the common codebase are required to
implement the v-prefixed functions only.

Thanks,
Gary

--
gdb/
2014-07-16  Tom Tromey  <tromey@redhat.com>
	    Gary Benson  <gbenson@redhat.com>

	* common/errors.h: New file.
	* common/errors.c: Likewise.
	* Makefile.in (HFILES_NO_SRCDIR) [common/errors.h]: New header.
	(COMMON_OBS) [errors.o]: New object file.
	(errors.o): New rule.
	* utils.h: Include errors.h.
	(perror_with_name, error, verror, fatal, vfatal, warning
	vwarning): Don't declare.
	* common/common-utils.h: Include errors.h.
	(malloc_failure, internal_error): Don't declare.

gdb/gdbserver/
2014-07-16  Tom Tromey  <tromey@redhat.com>
	    Gary Benson  <gbenson@redhat.com>

	* Makefile.in (SFILES) [common/errors.c]: New sourcefile.
	(OBS) [errors.o]: New object file.
	(IPA_OBS) [errors-ipa.o]: Likewise.
	(errors.o): New rule.
	(errors-ipa.o): Likewise.
	* utils.h: Include errors.h.
	(perror_with_name, error, fatal, warning): Don't declare.
	* utils.c (warning): Renamed and rewritten as...
	(vwarning): New function.
	(error): Renamed and rewritten as...
	(verror): New function.
	(fatal): Renamed and rewritten as...
	(vfatal): New function.
	(internal_error): Renamed and rewritten as...
	(internal_verror): New function.
---
 gdb/ChangeLog             |   14 ++++++++
 gdb/Makefile.in           |    8 +++-
 gdb/common/common-utils.h |    5 +--
 gdb/common/errors.c       |   71 +++++++++++++++++++++++++++++++++++++++
 gdb/common/errors.h       |   81 +++++++++++++++++++++++++++++++++++++++++++++
 gdb/gdbserver/ChangeLog   |   19 ++++++++++
 gdb/gdbserver/Makefile.in |   16 +++++++--
 gdb/gdbserver/utils.c     |   35 +++++--------------
 gdb/gdbserver/utils.h     |    5 +--
 gdb/utils.c               |   46 -------------------------
 gdb/utils.h               |   22 +------------
 11 files changed, 217 insertions(+), 105 deletions(-)
 create mode 100644 gdb/common/errors.c
 create mode 100644 gdb/common/errors.h
  

On 07/17/2014 02:47 PM, Gary Benson wrote:
> +/* Throw an error.  The current operation will be aborted.  The
> +   message will be issued to the user.  The application will
> +   return to a state where it is accepting commands from the user.  */

These comments aren't really true, though.  We have plenty of places
catching errors with TRY_CATCH and proceeding without returning to a
state where we're accepting commands from the user.

> +
> +extern void error (const char *fmt, ...)
> +     ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 2);
> +

(We should really bite the bullet and move exceptions.{h|c} and
cleanups.{h|c} to common/ and make gdbserver use them too.)
  

Pedro Alves wrote:
> On 07/17/2014 02:47 PM, Gary Benson wrote:
> > +/* Throw an error.  The current operation will be aborted.  The
> > +   message will be issued to the user.  The application will
> > +   return to a state where it is accepting commands from the user.  */
> 
> These comments aren't really true, though.  We have plenty of places
> catching errors with TRY_CATCH and proceeding without returning to a
> state where we're accepting commands from the user.

How about "Throw an error.  The current operation will be aborted.
The application may catch and process the error, or, if not, the
message will be issued to the user and the application will return
to a state where it is accepting commands from the user."

> (We should really bite the bullet and move exceptions.{h|c} and
> cleanups.{h|c} to common/ and make gdbserver use them too.)

Can I leave this for another series please?  This one's big enough
already.

Thanks,
Gary
  

On 07/17/2014 04:39 PM, Gary Benson wrote:
> Pedro Alves wrote:
>> On 07/17/2014 02:47 PM, Gary Benson wrote:
>>> +/* Throw an error.  The current operation will be aborted.  The
>>> +   message will be issued to the user.  The application will
>>> +   return to a state where it is accepting commands from the user.  */
>>
>> These comments aren't really true, though.  We have plenty of places
>> catching errors with TRY_CATCH and proceeding without returning to a
>> state where we're accepting commands from the user.
> 
> How about "Throw an error.  The current operation will be aborted.
> The application may catch and process the error, or, if not, the
> message will be issued to the user and the application will return
> to a state where it is accepting commands from the user."

Still infers what the application does with the error.  IMO, it's
best to describe the interface.  Like:

 Throw a generic error.  This function not return, instead
 it executes a long jump, aborting the current operation.
 The function takes printf-style arguments, which are used to
 construct the error message.

>> (We should really bite the bullet and move exceptions.{h|c} and
>> cleanups.{h|c} to common/ and make gdbserver use them too.)
> 
> Can I leave this for another series please?  This one's big enough
> already.

Yes, of course.  That's why it was a parenthesis.
  

Pedro Alves wrote:
> On 07/17/2014 04:39 PM, Gary Benson wrote:
> > Pedro Alves wrote:
> > > On 07/17/2014 02:47 PM, Gary Benson wrote:
> > > > +/* Throw an error.  The current operation will be aborted.  The
> > > > +   message will be issued to the user.  The application will
> > > > +   return to a state where it is accepting commands from the user.  */
> > >
> > > These comments aren't really true, though.  We have plenty of
> > > places catching errors with TRY_CATCH and proceeding without
> > > returning to a state where we're accepting commands from the
> > > user.
> > 
> > How about "Throw an error.  The current operation will be aborted.
> > The application may catch and process the error, or, if not, the
> > message will be issued to the user and the application will return
> > to a state where it is accepting commands from the user."
> 
> Still infers what the application does with the error.  IMO, it's
> best to describe the interface.  Like:
> 
>  Throw a generic error.  This function not return, instead
>  it executes a long jump, aborting the current operation.
>  The function takes printf-style arguments, which are used to
>  construct the error message.

Surely "it executes a long jump" is describing what the application
does with the error?  Besides, it's not true for IPA, where error
just calls exit (1).

In the context of this whole file, you have:

 - warning (one type)
 - errors (three types)
 - special cases (perror_with_name, malloc_failure)

The only difference between the three types of error is what the
application does with them:

 - error (may be handled, may return to command level, may exit)
 - fatal (will exit)
 - internal_error (may return to command level, may exit)

I don't think you can properly document these functions without
spelling this out.

Also, the documentation in this file is not just for callers of the
functions, it has to document them for implementors too.

How about the following?

Cheers,
Gary

--
/* Display a warning message to the user.  The message is constructed
   using a printf-style format string and a printf- or vprintf-style
   argument list.  */

extern void warning (const char *fmt, ...) ATTRIBUTE_PRINTF (1, 2);

extern void vwarning (const char *fmt, va_list args)
     ATTRIBUTE_PRINTF (1, 0);

/* Throw a non-fatal error, constructing the message using a printf-
   style format string and a printf- or vprintf-style argument list.
   This function does not return.  The application may attempt to
   handle the error.  */

extern void error (const char *fmt, ...)
     ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 2);

extern void verror (const char *fmt, va_list args)
     ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 0);

/* Throw a non-fatal error, constructing the message by combining
   STRING with the system error message for errno.  This function does
   not return.  The application may attempt to handle the error.  */

extern void perror_with_name (const char *string) ATTRIBUTE_NORETURN;

/* Throw a fatal error, constructing the message using a printf-style
   format string and a printf- or vprintf-style argument list.  This
   function does not return.  The application will exit.  */

extern void fatal (const char *fmt, ...)
     ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 2);

extern void vfatal (const char *fmt, va_list args)
     ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 0);

/* Throw an internal error, constructing the message using a printf-
   style format string and a printf- or vprintf-style argument list.
   This function does not return.  Internal errors indicate
   programming errors such as assertion failures, as opposed to more
   general errors the user may encounter.  Internal errors are treated
   as fatal errors, except that the application may offer the user the
   choice to return to the command level rather than exiting.  */

extern void internal_error (const char *file, int line,
			    const char *fmt, ...)
     ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (3, 4);

extern void internal_verror (const char *file, int line,
			     const char *fmt, va_list args)
     ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (3, 0);

/* A special case of internal error used to handle memory allocation
   failures.  */

extern void malloc_failure (long size) ATTRIBUTE_NORETURN;
  

On Fri, Jul 18, 2014 at 10:06 AM, Gary Benson <gbenson@redhat.com> wrote:
> [...]
> /* Throw a fatal error, constructing the message using a printf-style
>    format string and a printf- or vprintf-style argument list.  This
>    function does not return.  The application will exit.  */
>
> extern void fatal (const char *fmt, ...)
>      ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 2);
>
> extern void vfatal (const char *fmt, va_list args)
>      ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 0);
> [...]

Remember gdb doesn't exit on fatal().
fatal() in gdb is essentially ^c (quit() calls fatal()!).

Can I repeat my request to please document this in the function comment.
  

On 07/18/2014 10:06 AM, Gary Benson wrote:
> Pedro Alves wrote:
>> On 07/17/2014 04:39 PM, Gary Benson wrote:
>>> Pedro Alves wrote:
>>>> On 07/17/2014 02:47 PM, Gary Benson wrote:
>>>>> +/* Throw an error.  The current operation will be aborted.  The
>>>>> +   message will be issued to the user.  The application will
>>>>> +   return to a state where it is accepting commands from the user.  */
>>>>
>>>> These comments aren't really true, though.  We have plenty of
>>>> places catching errors with TRY_CATCH and proceeding without
>>>> returning to a state where we're accepting commands from the
>>>> user.
>>>
>>> How about "Throw an error.  The current operation will be aborted.
>>> The application may catch and process the error, or, if not, the
>>> message will be issued to the user and the application will return
>>> to a state where it is accepting commands from the user."
>>
>> Still infers what the application does with the error.  IMO, it's
>> best to describe the interface.  Like:
>>
>>  Throw a generic error.  This function not return, instead
>>  it executes a long jump, aborting the current operation.
>>  The function takes printf-style arguments, which are used to
>>  construct the error message.
> 
> Surely "it executes a long jump" is describing what the application
> does with the error?

By "does with the error" I was talking about what the application
does after the error is thrown, like talking about accepting
commands from the user, not really the internal implementation.

> Besides, it's not true for IPA, where error
> just calls exit (1).

Yeah, forgot that, though that's conceptually the same as the IPA having
an outer TRY_CATCH and calling exit(1) there.

OK, thinking this through.

Conceptually, what matters to the user of the API is when to call which error
function variant, and this one is to be called on generic errors.  That
the IPA chooses the treat generic errors as fatal errors, it's IPA's
business.  That's the detail of what the application decides to do
with the error.

> 
> In the context of this whole file, you have:
> 
>  - warning (one type)
>  - errors (three types)
>  - special cases (perror_with_name, malloc_failure)
> 
> The only difference between the three types of error is what the
> application does with them:
> 
>  - error (may be handled, may return to command level, may exit)
>  - fatal (will exit)
>  - internal_error (may return to command level, may exit)

I think that's not the best way to look at this.  We're documenting
an API, the contract the shared/core code will rely on to decide which
function to call.  If the contract is different in GDB vs GDBserver
then we shall fix up the differences first.

So, what is the contract we want ?  Where do we want to get to?

I think it should be:

- warning (something odd detected, but we'll carry on anyway.)
- error (generic, non-predicatable, non-fatal condition detected.
         The requested operation can't proceed.  E.g.: trying to
         compute expressions with optimized values; invalid input;invalid
         conversion attempted; etc.)
- internal_error (faulty logic detected)

and then, I think we should just not use 'fatal' as is in common code,
and so not move that to common code.  It's just confusing and behaves
different in GDB and GDBserver.  We have a bunch of callers on the
GDBserver side, but can't those all be internal_error / gdb_assert?
Why not?  If not, then I propose really describing 'fatal' as
being a non-recoverable fatal error.

On the GDB side it's only used in two situations -- throw
a QUIT when the user wants to try recovering from an internal error,
and, throw a QUIT when the user presses ctrl-c.  It's not called
when a fatal / internal error is detected, like on the
GDBserver side.

I think we should rename the existing 'fatal' on the GDB side for
clarity to something like throw_quit or some such.  How GDB
recovers from internal_error is GDB's business.  It just happens
today, that results in a QUIT being thrown.

For situations in GDB where we might have a fatal error that is
truly not recoverable, and that should not even consult the user
on whether to quit/dump core, etc., then we wouldn't call the
existing 'fatal' function as it is.
E.g., if GDB's 'fatal' where truly a 'fatal'-like function like
GDBserver's, this in main.c:

    /* Install it.  */
    if (!interp_set (interp, 1))
      {
        fprintf_unfiltered (gdb_stderr,
			    "Interpreter `%s' failed to initialize.\n",
                            interpreter_p);
        exit (1);
      }

would be written as:

    /* Install it.  */
    if (!interp_set (interp, 1))
      {
        fatal ("Interpreter `%s' failed to initialize.\n",
               interpreter_p);
      }

with 'fatal' printing the error and exiting, just like gdbserver.

I'd support doing that.

> I don't think you can properly document these functions without
> spelling this out.
> 
> Also, the documentation in this file is not just for callers of the
> functions, it has to document them for implementors too.

The way to do that is to document the contract callers use to
determine the class of error at hand, not what the application
does with such class of error.  If we're thinking in terms of library,
then listing what current applications do just results in comments
getting stale as implementations change or more applications are added.

> /* Throw an internal error, constructing the message using a printf-
>    style format string and a printf- or vprintf-style argument list.
>    This function does not return.  Internal errors indicate
>    programming errors such as assertion failures, as opposed to more
>    general errors the user may encounter.  Internal errors are treated
>    as fatal errors, except that the application may offer the user the
>    choice to return to the command level rather than exiting.  */

Here we're talking about "the command level", which doesn't
even exist on GDBserver or the IPA.  And I'm now thinking that
saying "Throw" here isn't exactly the best to say.  Instead,
I think it'd be better to say something like "Call when an internal
error was detected.", and don't even talk about the command level.
Like:

 /* An internal error was detected.  Internal errors indicate
    programming errors such as assertion failures, as opposed to more
    general errors beyond the application's control.
    This function does not return, and constructs an error message
    using a printf-style argument list.  FILE and LINE indicate the
    file and line number where the programming error was detected.

Thanks,
  

Doug Evans wrote:
> On Fri, Jul 18, 2014 at 10:06 AM, Gary Benson <gbenson@redhat.com> wrote:
> > [...]
> > /* Throw a fatal error, constructing the message using a printf-style
> >    format string and a printf- or vprintf-style argument list.  This
> >    function does not return.  The application will exit.  */
> >
> > extern void fatal (const char *fmt, ...)
> >      ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 2);
> >
> > extern void vfatal (const char *fmt, va_list args)
> >      ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 0);
> > [...]
> 
> Remember gdb doesn't exit on fatal().
> fatal() in gdb is essentially ^c (quit() calls fatal()!).
> 
> Can I repeat my request to please document this in the function
> comment.

I wanted to avoid putting implementation details here, but I see this
isn't going to happen.  Is the attached ok?

Cheers,
Gary
  

On Fri, Jul 18, 2014 at 11:44 AM, Gary Benson <gbenson@redhat.com> wrote:
> Doug Evans wrote:
>> On Fri, Jul 18, 2014 at 10:06 AM, Gary Benson <gbenson@redhat.com> wrote:
>> > [...]
>> > /* Throw a fatal error, constructing the message using a printf-style
>> >    format string and a printf- or vprintf-style argument list.  This
>> >    function does not return.  The application will exit.  */
>> >
>> > extern void fatal (const char *fmt, ...)
>> >      ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 2);
>> >
>> > extern void vfatal (const char *fmt, va_list args)
>> >      ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 0);
>> > [...]
>>
>> Remember gdb doesn't exit on fatal().
>> fatal() in gdb is essentially ^c (quit() calls fatal()!).
>>
>> Can I repeat my request to please document this in the function
>> comment.
>
> I wanted to avoid putting implementation details here,

I realize that.

> but I see this
> isn't going to happen.  Is the attached ok?

I'm trying to not impose on you too much churn and back-and-forth in
what is clearly a stepping stone.
Eventually I think fatal needs to disappear from the gdb side (renamed
or whatever).
Until that happens (i.e., *if* you just want to keep the patch
basically as is), then at the least I don't want to lie to the reader,
and I want to make the reader aware of the issue.  That's the high
order bit for me as far as "fatal" goes (within the context of trying
to keep the patch basically as is).

If you want to take on the task of getting this 100% correct in this
pass (or at least within some fraction thereof :-)), then we can take
a different route.  Your choice IMO.  [And I mean that sincerely - I
*am* trying to help you make progress here without being too
pedantic.]

> /* Throw a fatal error, constructing the message using a printf-style
>    format string and a printf- or vprintf-style argument list.  This
>    function does not return.  Fatal errors cause GDB to return to the
>    command level.  Fatal errors cause gdbserver to exit.  */
>
> extern void fatal (const char *fmt, ...)
>      ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 2);
>
> extern void vfatal (const char *fmt, va_list args)
>      ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 0);

I would tweak that a little, and instead just point out that gdb's
usage of the name "fatal" is broken.  I don't care too much about
the wording, I just want to make sure we don't lie to the reader
and make the reader aware of the issue.

/* Throw a fatal error, constructing the message using a printf-style
   format string and a printf- or vprintf-style argument list.  This
   function does not return.  Fatal errors cause the app to exit,
   except in the case of gdb where it just throws a RETURN_QUIT
   exception.  */