From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=VVrC=5P=klomp.org=mark@sourceware.org>
Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184])
	by sourceware.org (Postfix) with ESMTPS id CB9E13858D28;
	Wed, 18 Jan 2023 09:48:16 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CB9E13858D28
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org
Received: from r6.localdomain (82-217-174-174.cable.dynamic.v4.ziggo.nl [82.217.174.174])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by gnu.wildebeest.org (Postfix) with ESMTPSA id 5F3DC302BBEC;
	Wed, 18 Jan 2023 10:48:15 +0100 (CET)
Received: by r6.localdomain (Postfix, from userid 1000)
	id 15D8B340248; Wed, 18 Jan 2023 10:48:14 +0100 (CET)
Message-ID: <0676f6c1b4fe81ff3ff24ad8de030dda2a27b3eb.camel@klomp.org>
Subject: Re: [PATCH v2]     remote.c: Allow inferior to reply with an error
From: Mark Wielaard <mark@klomp.org>
To: Andrew Burgess <aburgess@redhat.com>, ahajkova@sourceware.org, 
	gdb-patches@sourceware.org
Date: Wed, 18 Jan 2023 10:48:13 +0100
In-Reply-To: <87zgahdsyi.fsf@redhat.com>
References: <20230113115910.3215524-1-ahajkova@redhat.com>
	 <87zgahdsyi.fsf@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.2 (3.46.2-1.fc37) 
MIME-Version: 1.0
X-Spam-Status: No, score=-3030.4 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gdb-patches.sourceware.org>

Hi Andrew,

On Tue, 2023-01-17 at 16:30 +0000, Andrew Burgess wrote:
>=20
> So, then I went to the docs again, and re-read what we say about
> QSetWorkingDir:
>=20
> =C2=A0 This packet is used to inform the remote server of the intended
> =C2=A0 current working directory for programs that are going to be
> executed.
>=20
> Note the use of the word 'intended'.=C2=A0 This packet does not try to
> change
> the directory NOW, it will try to change the directory LATER, when
> the
> inferior is actually executed.
>=20
> My current reading of the docs is that the QSetWorkingDir packet, is
> either not supported, or should never fail.
>=20
> 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?

Thanks,

Mark