remote.c: Make packet_check_result return a structure

  packet_check_result currently returns an packet_result enum.
If GDB will recieve an error in a format E.errtext, which
is possible for some q packets, such errtext is lost if
treated by packet_check_result.
Introduce a new structure which bundles enum packet_result
with possible error message or error code returned by
the GDBserver.
I plan to make more GDBserver response checking functions to use
packet_check_result to make remote.c code more consistent.
This will also allow to use E.errtext more in the future.

There's no infrastructure to test this with a test case so
I tested this by modifying store_registers_using_G function
to get an error message:

[remote] Sending packet: $GG00000000 ...

gdbserver: Wrong sized register packet (expected 1792 bytes, got 1793)
gdbserver: Invalid hex digit 71
Killing process(es): 1104002
[remote] Packet received: E01
Could not write registers; remote failure reply '01'
---
 gdb/remote.c | 110 ++++++++++++++++++++++++++++++++++++---------------
 1 file changed, 79 insertions(+), 31 deletions(-)
  

>>>>> "Alexandra" == Alexandra Hájková <ahajkova@redhat.com> writes:

Alexandra> packet_check_result currently returns an packet_result enum.
Alexandra> If GDB will recieve an error in a format E.errtext, which
Alexandra> is possible for some q packets, such errtext is lost if
Alexandra> treated by packet_check_result.

Thank you for the patch.  I think the general idea makes sense.

Alexandra> There's no infrastructure to test this with a test case so
Alexandra> I tested this by modifying store_registers_using_G function
Alexandra> to get an error message:

packet_check_result is isolated enough that, if you wanted, you could
write unit tests for it.

Alexandra> +/* Keeps packet's return value. If packet's return value is PACKET_ERROR,
Alexandra> +   err_msg contains an error message string from E.string or the number
Alexandra> +   stored as a string from E.num.  */
Alexandra> +struct packet_result
Alexandra> +{
Alexandra> +  packet_result (enum packet_status status, std::string err_msg)
Alexandra> +    : m_status (status),
Alexandra> +    m_err_msg (std::move (err_msg))

This is formatted strangely.

Alexandra> +  packet_result (enum packet_status status)
Alexandra> +    : m_status (status)
Alexandra> +    {
Alexandra> +      gdb_assert (status != PACKET_ERROR);

Here and elsewhere the "{" is indented too far.
Also, single-argument constructors should ordinarily be "explicit".

Alexandra> +    }
Alexandra> +
Alexandra> +private:
Alexandra> +  enum packet_status m_status;
Alexandra> +  std::string m_err_msg;
Alexandra> +
Alexandra> +public:

Better IMO to put all the private stuff at the end.

Alexandra> +  enum packet_status
Alexandra> +  status () const

For methods this all goes on one line.

Alexandra> -static enum packet_result
Alexandra> +static struct packet_result

Since you're touching this anyway you might as well leave out the
'struct' keyword.

Tom
  

Hello,

Nice change! Just a couple of small nits below, if you agree with them.

Regardless of whether you make the changes I suggest:

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>


Alexandra Hájková <ahajkova@redhat.com> writes:

> @@ -9705,8 +9751,9 @@ remote_target::remote_send_printf (const char *format, ...)
>  
>    rs->buf[0] = '\0';
>    getpkt (&rs->buf);
> +  packet_result pkt_status = packet_check_result (rs->buf);

IMHO it's a bit confusing to have a variable of type packet_result named
pkt_status. I'd suggest changing to pkt_result.

>  
> -  return packet_check_result (rs->buf);
> +  return pkt_status.status ();
>  }
>  
>  /* Flash writing can take quite some time.  We'll set
> @@ -9718,7 +9765,7 @@ void
>  remote_target::flash_erase (ULONGEST address, LONGEST length)
>  {
>    int addr_size = gdbarch_addr_bit (current_inferior ()->arch ()) / 8;
> -  enum packet_result ret;
> +  enum packet_status ret;
>    scoped_restore restore_timeout
>      = make_scoped_restore (&remote_timeout, remote_flash_timeout);
>  
> @@ -11308,7 +11355,7 @@ remote_target::verify_memory (const gdb_byte *data, CORE_ADDR lma, ULONGEST size
>    if (target_has_execution ()
>        && m_features.packet_support (PACKET_qCRC) != PACKET_DISABLE)
>      {
> -      enum packet_result result;
> +      enum packet_status result;

Similar comment here. A variable of type packet_status is named
result. The upside of preserving the current name is that the diff is
smaller, but I think the clearer code is worth having a bigger diff.

Same comment for the following hunks of the patch:

>  
>        /* Make sure the remote is pointing at the right process.  */
>        set_general_process ();
> @@ -12210,7 +12257,7 @@ remote_target::get_thread_local_address (ptid_t ptid, CORE_ADDR lm,
>        struct remote_state *rs = get_remote_state ();
>        char *p = rs->buf.data ();
>        char *endp = p + get_remote_packet_size ();
> -      enum packet_result result;
> +      enum packet_status result;
>  
>        strcpy (p, "qGetTLSAddr:");
>        p += strlen (p);
> @@ -12256,7 +12303,7 @@ remote_target::get_tib_address (ptid_t ptid, CORE_ADDR *addr)
>        struct remote_state *rs = get_remote_state ();
>        char *p = rs->buf.data ();
>        char *endp = p + get_remote_packet_size ();
> -      enum packet_result result;
> +      enum packet_status result;
>  
>        strcpy (p, "qGetTIBAddr:");
>        p += strlen (p);
> @@ -13821,7 +13868,7 @@ remote_target::get_trace_status (struct trace_status *ts)
>  {
>    /* Initialize it just to avoid a GCC false warning.  */
>    char *p = NULL;
> -  enum packet_result result;
> +  enum packet_status result;
>    struct remote_state *rs = get_remote_state ();
>  
>    if (m_features.packet_support (PACKET_qTStatus) == PACKET_DISABLE)
> @@ -14201,7 +14248,7 @@ remote_target::set_trace_buffer_size (LONGEST val)
>        struct remote_state *rs = get_remote_state ();
>        char *buf = rs->buf.data ();
>        char *endbuf = buf + get_remote_packet_size ();
> -      enum packet_result result;
> +      enum packet_status result;
>  
>        gdb_assert (val >= 0 || val == -1);
>        buf += xsnprintf (buf, endbuf - buf, "QTBuffer:size:");
> @@ -15527,9 +15574,10 @@ remote_target::store_memtags (CORE_ADDR address, size_t len,
>  
>    putpkt (rs->buf);
>    getpkt (&rs->buf);
> +  packet_result pkt_status = packet_check_result (rs->buf);
>  
>    /* Verify if the request was successful.  */
> -  return packet_check_result (rs->buf.data ()) == PACKET_OK;
> +  return pkt_status.status () == PACKET_OK;
>  }
>  
>  /* Return true if remote target T is non-stop.  */
  

Tom Tromey <tom@tromey.com> writes:

>>>>>> "Alexandra" == Alexandra Hájková <ahajkova@redhat.com> writes:
>
> Alexandra> packet_check_result currently returns an packet_result enum.
> Alexandra> If GDB will recieve an error in a format E.errtext, which
> Alexandra> is possible for some q packets, such errtext is lost if
> Alexandra> treated by packet_check_result.
>
> Thank you for the patch.  I think the general idea makes sense.
>
> Alexandra> There's no infrastructure to test this with a test case so
> Alexandra> I tested this by modifying store_registers_using_G function
> Alexandra> to get an error message:
>
> packet_check_result is isolated enough that, if you wanted, you could
> write unit tests for it.
>
> Alexandra> +/* Keeps packet's return value. If packet's return value is PACKET_ERROR,
> Alexandra> +   err_msg contains an error message string from E.string or the number
> Alexandra> +   stored as a string from E.num.  */
> Alexandra> +struct packet_result
> Alexandra> +{
> Alexandra> +  packet_result (enum packet_status status, std::string err_msg)
> Alexandra> +    : m_status (status),
> Alexandra> +    m_err_msg (std::move (err_msg))
>
> This is formatted strangely.
>
> Alexandra> +  packet_result (enum packet_status status)
> Alexandra> +    : m_status (status)
> Alexandra> +    {
> Alexandra> +      gdb_assert (status != PACKET_ERROR);
>
> Here and elsewhere the "{" is indented too far.
> Also, single-argument constructors should ordinarily be "explicit".

OOI, wondering why you specifically call out single-argument
constructors here?  I was re-reading this page to refresh my knowledge
of 'explicit':

  https://en.cppreference.com/w/cpp/language/explicit

And it seems that marking multi-argument constructors would place the
same restrictions on the constructor as for single-argument
constructors...

Though I guess there's more chance of accidentally assigning a scalar
into a non-scalar object (e.g. packet_result in this case).  Maybe
that's why the single-argument case is being called out?

Anyway, not disagreeing with you, just trying to educate myself.

Thanks,
Andrew

>
> Alexandra> +    }
> Alexandra> +
> Alexandra> +private:
> Alexandra> +  enum packet_status m_status;
> Alexandra> +  std::string m_err_msg;
> Alexandra> +
> Alexandra> +public:
>
> Better IMO to put all the private stuff at the end.
>
> Alexandra> +  enum packet_status
> Alexandra> +  status () const
>
> For methods this all goes on one line.
>
> Alexandra> -static enum packet_result
> Alexandra> +static struct packet_result
>
> Since you're touching this anyway you might as well leave out the
> 'struct' keyword.
>
> Tom
  

>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:

Andrew>   https://en.cppreference.com/w/cpp/language/explicit

Andrew> And it seems that marking multi-argument constructors would place the
Andrew> same restrictions on the constructor as for single-argument
Andrew> constructors...

Andrew> Though I guess there's more chance of accidentally assigning a scalar
Andrew> into a non-scalar object (e.g. packet_result in this case).  Maybe
Andrew> that's why the single-argument case is being called out?

Yeah.  I think it just doesn't matter for multi-argument constructors
(that do not have default arguments), since there's no chance of
introducing an accidental implicit conversion -- multiple arguments are
needed.

Tom