This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch v4 20/24] btrace, gdbserver: read branch trace incrementally
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Pedro Alves <palves at redhat dot com>
- Date: Sun, 22 Sep 2013 16:42:24 +0200
- Subject: Re: [patch v4 20/24] btrace, gdbserver: read branch trace incrementally
- Authentication-results: sourceware.org; auth=none
- References: <1372842874-28951-1-git-send-email-markus dot t dot metzger at intel dot com> <1372842874-28951-21-git-send-email-markus dot t dot metzger at intel dot com> <20130818190905 dot GP24153 at host2 dot jankratochvil dot net> <A78C989F6D9628469189715575E55B230A9CEBAD at IRSMSX104 dot ger dot corp dot intel dot com>
On Mon, 16 Sep 2013 14:48:42 +0200, Metzger, Markus T wrote:
> The -EOVERFLOW return signals a buffer overflow which indicates that
> delta trace is not available. GDB then switches to a full read after discarding
> the existing trace.
Then linux_read_btrace function comment should document this as -EOVERFLOW is
specific to its API. But I would find some enum more clear, see below.
> The -ENOSYS return signals that the feature is not available. This error is
> passed on to the user.
+
> > TBH returning all these errno codes are not common in GDB, returning -1
> > would make it easier but I do not insist on it.
>
> I need to distinguish different types of errors, e.g. overflow and not supported.
Then use enum. There is for example:
enum return_reason
{
/* User interrupt. */
RETURN_QUIT = -2,
/* Any other error. */
RETURN_ERROR
};
One could even throw and catch specific exceptions (enum errors) but I find
that needlessly overcomplicated when we just return to the immediate caller.
Thanks,
Jan