From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id B66C13858D28 for ; Wed, 18 Jan 2023 18:10:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B66C13858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674065436; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6ElsGBPTRawEmLJkvqGPkdOaDLWD7cF7Z2CiSa+6+Lw=; b=HoKycYs4DaC4/f7D/qgMIIjNfXLodd3aAH8Dfv8Q3GJu90VGC5UwlNHLojZ/6+SwaECWK8 AMLMKFFb6+Yjd6LWD1iHuPNnZSfUM37a3DfFmg/UKLLvgXScyVssQn0WPhH/lctpjdzu5y 6QuFmKuUIrhwbIggj1tTMi7gyMvsTZA= Received: from mail-vk1-f200.google.com (mail-vk1-f200.google.com [209.85.221.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-479-DuURo207MkOm5kU1EeZ2fw-1; Wed, 18 Jan 2023 13:10:28 -0500 X-MC-Unique: DuURo207MkOm5kU1EeZ2fw-1 Received: by mail-vk1-f200.google.com with SMTP id f123-20020a1f9c81000000b003e1a7591524so1720470vke.1 for ; Wed, 18 Jan 2023 10:10:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:to:from:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=6ElsGBPTRawEmLJkvqGPkdOaDLWD7cF7Z2CiSa+6+Lw=; b=zCraVS6fSffDhO3Cg5v0fsRJphikKM/2gWcSfrWsbDcLGPy2VGFUh+c2ZjTBtsCxjD jONMpyYyo5XdiaISYH+nKMH3dv6lmij+NCJsgR+OCAxUa69rHug8RRws+NycI6RA0C3U JgyR2sXUu7LiPoZibF/IMMxXjCAPhUtqp5trXN+6MIxRy2n8IKYwuAGJlhRhH5e4Chpw LV/kvV0ZgXm5ltJaynvOCwVmPSmuf1gvLNdiou3I53aeOulQirx9lG2yHT3h6P1NzfaJ lr8mvtWLHKDjrdFDqNuMlBTCQEDbNiyJJOsnvmWx6LGB7C70s+sAmwPSo0ipPp/dZxcd S2tQ== X-Gm-Message-State: AFqh2kqMy5i/UeivdnoTL66QbSIQgWcOdQmpsF8iQPETAoowl5UYAE66 BG34uUVsGy0NjuZcTBtEYD3CG+08EM8M/jCl0j+At3rYVe3u4IiSs1CvSehwsat7IS5GjnE371f cgf48qoS5VviuI5hcbyRoJg== X-Received: by 2002:a67:cd81:0:b0:3d3:c72a:1bc0 with SMTP id r1-20020a67cd81000000b003d3c72a1bc0mr7958886vsl.31.1674065427106; Wed, 18 Jan 2023 10:10:27 -0800 (PST) X-Google-Smtp-Source: AMrXdXtBpVhtDflVQWbVtCb/5VNRZJCc1Y+zQIHmJvhKXNsZoe9/8855+C8LgGNsNZDrYM9RpftzyA== X-Received: by 2002:a67:cd81:0:b0:3d3:c72a:1bc0 with SMTP id r1-20020a67cd81000000b003d3c72a1bc0mr7958870vsl.31.1674065426842; Wed, 18 Jan 2023 10:10:26 -0800 (PST) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id br20-20020a05620a461400b00706c1fc62desm1037851qkb.112.2023.01.18.10.10.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Jan 2023 10:10:26 -0800 (PST) From: Andrew Burgess To: Mark Wielaard , ahajkova@sourceware.org, gdb-patches@sourceware.org Subject: Re: [PATCH v2] remote.c: Allow inferior to reply with an error In-Reply-To: <0676f6c1b4fe81ff3ff24ad8de030dda2a27b3eb.camel@klomp.org> References: <20230113115910.3215524-1-ahajkova@redhat.com> <87zgahdsyi.fsf@redhat.com> <0676f6c1b4fe81ff3ff24ad8de030dda2a27b3eb.camel@klomp.org> Date: Wed, 18 Jan 2023 18:10:24 +0000 Message-ID: <87tu0nemsv.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Mark Wielaard writes: > 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? 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. Thanks, Andrew