public inbox for
 help / color / mirror / Atom feed
From: Andrew Burgess <>
To: Mark Wielaard <>,,
Subject: Re: [PATCH v2]     remote.c: Allow inferior to reply with an error
Date: Wed, 18 Jan 2023 18:10:24 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Mark Wielaard <> writes:

> Hi Andrew,
> On Tue, 2023-01-17 at 16:30 +0000, Andrew Burgess wrote:
>> So, then I went to the docs again, and re-read what we say about
>> QSetWorkingDir:
>>   This packet is used to inform the remote server of the intended
>>   current working directory for programs that are going to be
>> executed.
>> Note the use of the word 'intended'.  This packet does not try to
>> change
>> the directory NOW, it will try to change the directory LATER, when
>> the
>> inferior is actually executed.
>> My current reading of the docs is that the QSetWorkingDir packet, is
>> either not supported, or should never fail.
>> If you specify an invalid directory then future attempts to start an
>> inferior will fail, but the QSetWorkingDir packet itself shouldn't
>> fail.
> This is part of nicer integration of the valgrind gdbserver and gdb.
> One of the issues we have been struggling with is making this more user
> friendly. Although the reply to some packets, like vRun, can include an
> error value ('Enn', An error occurred. The error number nn is given as
> hex digits), gdb seems to not use the error number at all (and the
> remote protocol doesn't seem to define meaning to the error numbers).
> But a lot of different things can go wrong with vRun. But all gdb will
> say is "Running on the remote target failed". So that is why we like
> the different vRun "setup" packets that currently don't take an Error
> return to explain to the user what exactly goes wrong.
> So if you think things like QSetWorkingDir shouldn't return an error,
> then how do we get what is going wrong when handling the vRun packet
> back to the gdb user?

Off the top of my head, we could start defining some meanings for the
various 'Enn' values.

If it doesn't already, we could update vRun to accept the 'E.msg' style
error packets.

Or for this particular case, we could, as I left open in my reply,
extend QSetWorkingDir to allow errors.  My only concern with that is
it's not just an extension of QSetWorkingDir, but a change to how
QSetWorkingDir is to be handled.  We'd certainly need a more extensive
doc update than Alexandra initially suggested.

Having spent most of the last few years doing remote debug, I share your
frustration at the poor error reporting in the remote protocol, so
anything we can do to improve that is a good thing, I'm 100% on board
with improving error reporting.

My concern here was just that the initial proposal, as laid out, seemed
to be based on a misunderstanding of what the QSetWorkingDir does.


  reply	other threads:[~2023-01-18 18:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-13 11:59 
2023-01-13 13:16 ` Eli Zaretskii
2023-01-17 16:30 ` Andrew Burgess
2023-01-18  9:48   ` Mark Wielaard
2023-01-18 18:10     ` Andrew Burgess [this message]
2023-01-18 13:37   ` Alexandra Petlanova Hajkova
2023-01-18 18:19     ` Andrew Burgess

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).