From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 1Cq5KjkmyWi9bQYAWB0awg (envelope-from ) for ; Tue, 16 Sep 2025 04:56:25 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=L9JsF2c2; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 9E4041E047; Tue, 16 Sep 2025 04:56:25 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 205B01E047 for ; Tue, 16 Sep 2025 04:56:24 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5D462385735A for ; Tue, 16 Sep 2025 08:56:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5D462385735A Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=L9JsF2c2 Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [IPv6:2001:4860:4864:20::2e]) by sourceware.org (Postfix) with ESMTPS id 26FB03858D39 for ; Tue, 16 Sep 2025 08:55:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 26FB03858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 26FB03858D39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:4860:4864:20::2e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1758012944; cv=none; b=WJRkWvVIbOmmNg0+mVOCucGsMh0Pv/bcY+hqS+SFJdfUv6HqtaH6sMfzrKls9+lwlyCEsDvEKadTuXJ3bf7AX2qe11VNdPA+BYC4Y2TUtgvsxm2TrID0VhowSsKSRm/RInuXvAQzHCFZR0O9jdjYHVVr3Rh9mpjenil/SVeeg5w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1758012944; c=relaxed/simple; bh=SUM1tOE8T6PjRuFUTOT6KMnOgiZdJHozudwUfUvPvMQ=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=CS9wmbviU4Yuxz30Kciwlvqqyzpapk/ODQeQkl3Z283qC9W/eGQWU/NWyt5UcuFjqKYmDiAjUA23ONPMdxx04SROeRDCgljzrcrV7o1You8jcXI9J7iXoh4rQkIiPkBq0hBKiu8jcSecF6jn5na7C7psHYbGyOq0bLVOC+8nH3o= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 26FB03858D39 Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-30cceb749d7so2385985fac.2 for ; Tue, 16 Sep 2025 01:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758012943; x=1758617743; darn=sourceware.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YC1eyLkW8kkfRxrxHKWgJCFhgGa6NF0n+0escfroeEE=; b=L9JsF2c2mdG/sQt39MFUefo9LJLlNvjdAbnYIlrwbDE7zuDYURn3eiEyvpWAcp9tlY T1Mwv9RfoqbSDd15+7yeeKbQYGRPv6DCNgAMpxGuquSGutY3LJG8o1fZhFY+fbP4F97b 0QywGB028+FyVFj7q3TwPaEhGxZpIXPkhI6cgRueNCfHvkMXlpq9g6CWvpQwp0DordbC T8VgtCDEyEOGeZUneqHW95VhewlWZormpFpSYgYT9D/8/YC1tjmWZXeBW44YTCRAtxvU e/7d1qR/a3YrPspN13jiQoIBRmcxVeQ+ObLpirXUq1aGf6DQOxAUEvJLxQ2N7zw5H6gr 6bIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758012943; x=1758617743; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YC1eyLkW8kkfRxrxHKWgJCFhgGa6NF0n+0escfroeEE=; b=BJxirOKfVAIZqFMx68sRMBSdJE0BN+5+N0NYV7iYq3fX3DU+u/yStZ9umkXRngTqgb SbLGzV4/Z0aRBzQX4i2KiXg5JOUATlUP1dkjxK7LnmXV7lZXuE5CM1otTwhX30lhhDKp O6Z8KZ7ZKLcIOwM2745wxzBSXYxRZdnk61NXGq4MHAxROT8NPG+ByZ75+8YkLaGXpZPX Z4R+sFSyXfbepc/AH+ZS8amMsM3utJx8X7IH0XWEsA/j2Z6y7l0hhMd3kbZvlMut2rPD YlARAyUg6AjPe/GQXaQq2oGEc4xSdVGgUZLn0PM28pHnkSd82CiAxZWwaVAT5fmnJlOT uGGQ== X-Forwarded-Encrypted: i=1; AJvYcCW6m4goXFUmidP4c08xGW5eEfzz58WZIdMMPCg5plYhSnDtYRQ1enpY9BsSioKXS81SB9u5vPYHQyb+bw==@sourceware.org X-Gm-Message-State: AOJu0YxJPP0NOy8sWvtLCYt+DewFLxBlcUIkgHI5F9lXB5NKn+19FKok 85r3V2Kzole+W8zuDKjtGzEa5i14DvUxev+CXfNZGEcorrMKBwN1XkMFPcchJqt0XBBgV/cWgIu BnB7C8owTDbYeehtO2K/W4bsNExw6KyE= X-Gm-Gg: ASbGnctJTkaZEu1V5PAevprVe5Ab2CLr4MuvjN2zoleNIivEX4wTo3aOunrgp+KGAuN 9eeZeUe7ra8FTg/28ADwYsgoUuL2y9pmRM9O223VDItgGYTV36nR+RCRX73BlgaGR7av81Ikr26 wC1sh//LkurEjSTvMV0TUQO/FHjMJQdfZLuLkTA5IxwSccWHEl7BrECuW4sVGn+KDUmJiP32EjX i2QrNU= X-Google-Smtp-Source: AGHT+IE2xKGgFU5jVY16+gnk+SVqbauRWjwEShJ0fnw9xyH0o5GnZB4KbIC8oSKOm5Mf74mBuNF871vtS5EcqEq3W1M= X-Received: by 2002:a05:6870:46ac:b0:32d:ecb:51d with SMTP id 586e51a60fabf-32e54f8b4admr8668220fac.16.1758012943153; Tue, 16 Sep 2025 01:55:43 -0700 (PDT) MIME-Version: 1.0 References: <20250624145052.4659642b@f41-zbm-amd> <874it8htc2.fsf@redhat.com> In-Reply-To: <874it8htc2.fsf@redhat.com> From: Luis Date: Tue, 16 Sep 2025 09:55:34 +0100 X-Gm-Features: AS18NWDSnBdusFaJkxfinX6VHsJHyap2msN0LFkjqiA8sk1feB_KTQxL8Ti9i5I Message-ID: Subject: Re: [PATCH] gdb/gdbserver: pass inferior arguments as a single string To: Andrew Burgess Cc: Kevin Buettner , gdb-patches@sourceware.org, Michael Weghorn , Eli Zaretskii , Guinevere Larsen Content-Type: multipart/alternative; boundary="000000000000fcbdc2063ee7484d" X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org --000000000000fcbdc2063ee7484d Content-Type: text/plain; charset="UTF-8" I think I'm running into a change in behavior for --args, where it now says no program was specified when previously it was ok. Just a standard.... ./gdb/gdb -ex run --args gdb/gdb gdb/gdb -ex start Did something change in terms of invocation format? On Fri, Sep 12, 2025, 11:13 Andrew Burgess wrote: > Kevin Buettner writes: > > > Hi Andrew, > > > > I have a few commit log nits - see (inline) below. > > > > On Tue, 13 May 2025 11:31:04 +0100 > > Andrew Burgess wrote: > > > >> GDB holds the inferior arguments as a single string. Currently when > >> GDB needs to pass the inferior arguments to a remote target as part of > >> a vRun packet, this is done by splitting the single argument string > >> into its component arguments by calling gdb::remote_args::split, which > >> uses the gdb_argv class to split the arguments for us. > >> > >> The same gdb_argv class is used when the user has asked GDB/gdbserver > >> to start the inferior without first invoking a shell; the gdb_argv > >> class is used to split the argument string into it component > >> arguments, and each is passed as a separate argument to the execve > >> call which spawns the inferior. > >> > >> There is however, a problem with using gdb_argv to split the arguments > >> before passing them to a remote target. To understand this problem we > >> must first understand how gdb_argv is used when invoking an inferior > >> without a shell. > >> > >> And to understand how gdb_argv is used to start an inferior without a > >> shell, I feel we need to first look at an example of starting an > >> inferior with a shell. > >> > >> Consider these two cases: > >> > >> (a) (gdb) set args \$VAR > >> (b) (gdb) set args $VAR > >> > >> When starting with a shell, in case (a) the user expects the inferior > >> to receive a literal '$VAR' string as an argument, while in case (b) > >> the user expects to see the shell expanded value of the variable $VAR. > >> > >> If the user does 'set startup-with-shell off', then in (a) GDB will > >> strip the '\' while splitting the arguments, and the inferior will be > >> passed a literal '$VAR'. In (b) there is no '\' to strip, so also in > >> this case the inferior will receive a literal '$VAR', remember > >> startup-with-shell is off, so there is no shell than can ever expand > > > > s/than/that/ > > > >> $VAR. > >> > >> Notice, that when startup-with-shell is off, we end up with a many to > >> one mapping, both (a) and (b) result in the literal string $VAR being > >> passed to the inferior. I think this is the correct behaviour in this > >> case. > >> > >> However, as we use gdb_argv to split the remote arguments we have the > >> same many to one mapping within the vRun packet. But the vRun packet > >> will be used when startup-with-shell is both on and off. What this > >> means is that when gdbserver receives a vRun packet containing '$VAR' > >> it doesn't know if GDB actually had '$VAR', or if GDB had '\$VAR'. > >> And this is a huge problem. > >> > >> We can address this by making the argument splitting for remote > >> targets smarter, and I do have patches that try to do this in this > >> series: > >> > >> > https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com > >> > >> That series was pretty long, and wasn't getting reviewed, so I'm > >> pulling the individual patches out and posting them separately. > >> > >> This patch doesn't try to make remote argument splitting. I think > > > > s/make/do/ > > > >> that splitting and then joining the arguments is a mistake which can > >> only introduce problems. The patch in the above series which tries to > >> make the splitting and joining "smarter" handles unquoted, single > >> quoted, and double quoted strings. But doesn't really address > > > > s/But doesn't/But that doesn't/ > > > >> parameter substitution, command substitution, or arithmetic expansion. > >> And even if we did try to address these cases, what rules exactly > >> would we implement? Probably POSIX shell rules, but what if the > >> remote target doesn't have a POSIX shell? The only reason we're > >> talking about which shell rules to follow is because the splitting and > >> joining logic needs to mirror those rules. If we stop splitting and > >> joining then we no longer need to care about the target's shell. > >> > >> Clearly, for backward compatibility we need to maintain some degree of > >> argument splitting and joining as we currently have; and that's why I > >> have a later patch (see the series above) that tries to improve that > >> splitting and joining a little. But I think, what we should really > >> do, is add a new feature flag (as used by the qSupported packet) and, > >> if GDB and the remote target agree, we should pass the inferior > >> arguments as a single string. > >> > >> This solves all our problems. In the startup with shell case, we no > >> longer need to worry about splitting at all. The arguments are passed > >> unmodified to the remote target, that can then pass the arguments to > >> the shell directly. > >> > >> In the 'startup-with-shell off' case it is now up to the remote target > >> to split the arguments, though in gdbserver we already did this, so > >> nothing really changes in this case. And if the remote target doesn't > >> have a POSIX shell, well GDB just doesn't need to worry about it! > >> > >> Something similar to this was originally suggested in this series: > >> > >> > https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/ > >> > >> though this series didn't try to maintain backward compatibility, > >> which I think is an issue that my patch solves. Additionally, this > >> series only passed the arguments as a single string in some cases, > >> I've simplified this so that, when GDB and the remote agree, the > >> arguments are always passed as a single string. I think this is a > >> little cleaner. > >> > >> I've also added documentation and some tests with this commit, > >> including ensuring that we test both the new single string approach, > >> and the fallback split/join approach. > >> > >> I've credited the author of the referenced series as co-author as they > >> did come to a similar conclusion, though I think my implementation is > >> different enough that I'm happy to list myself as primary author. > >> > >> Co-Authored-By: Michael Weghorn > >> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392 > >> > >> Reviewed-By: Eli Zaretskii > >> Tested-By: Guinevere Larsen > > > > Thanks for the detailed explanation. This makes sense to me. > > > > I also tested this patch and found no problems. > > > > Approved-by: Kevin Buettner > > Thanks for the feedback. I made these changes and pushed this patch. > > Thanks, > Andrew > > --000000000000fcbdc2063ee7484d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think I'm running into a change in behavior for --a= rgs, where it now says no program was specified when previously it was ok.<= div dir=3D"auto">
Just a standard....

./gdb/gdb -ex run --args gdb/gdb g= db/gdb -ex start

Did som= ething change in terms of invocation format?

On = Fri, Sep 12, 2025, 11:13 Andrew Burgess <aburgess@redhat.com> wrote:
Kevin Buettner <kevinb@redhat.com> writes:

> Hi Andrew,
>
> I have a few commit log nits - see (inline) below.
>
> On Tue, 13 May 2025 11:31:04 +0100
> Andrew Burgess <aburgess@redhat.com> wrote:
>
>> GDB holds the inferior arguments as a single string.=C2=A0 Current= ly when
>> GDB needs to pass the inferior arguments to a remote target as par= t of
>> a vRun packet, this is done by splitting the single argument strin= g
>> into its component arguments by calling gdb::remote_args::split, w= hich
>> uses the gdb_argv class to split the arguments for us.
>>
>> The same gdb_argv class is used when the user has asked GDB/gdbser= ver
>> to start the inferior without first invoking a shell; the gdb_argv=
>> class is used to split the argument string into it component
>> arguments, and each is passed as a separate argument to the execve=
>> call which spawns the inferior.
>>
>> There is however, a problem with using gdb_argv to split the argum= ents
>> before passing them to a remote target.=C2=A0 To understand this p= roblem we
>> must first understand how gdb_argv is used when invoking an inferi= or
>> without a shell.
>>
>> And to understand how gdb_argv is used to start an inferior withou= t a
>> shell, I feel we need to first look at an example of starting an >> inferior with a shell.
>>
>> Consider these two cases:
>>
>>=C2=A0 =C2=A0(a)=C2=A0 (gdb) set args \$VAR
>>=C2=A0 =C2=A0(b)=C2=A0 (gdb) set args $VAR
>>
>> When starting with a shell, in case (a) the user expects the infer= ior
>> to receive a literal '$VAR' string as an argument, while i= n case (b)
>> the user expects to see the shell expanded value of the variable $= VAR.
>>
>> If the user does 'set startup-with-shell off', then in (a)= GDB will
>> strip the '\' while splitting the arguments, and the infer= ior will be
>> passed a literal '$VAR'.=C2=A0 In (b) there is no '\&#= 39; to strip, so also in
>> this case the inferior will receive a literal '$VAR', reme= mber
>> startup-with-shell is off, so there is no shell than can ever expa= nd
>
> s/than/that/
>
>> $VAR.
>>
>> Notice, that when startup-with-shell is off, we end up with a many= to
>> one mapping, both (a) and (b) result in the literal string $VAR be= ing
>> passed to the inferior.=C2=A0 I think this is the correct behaviou= r in this
>> case.
>>
>> However, as we use gdb_argv to split the remote arguments we have = the
>> same many to one mapping within the vRun packet.=C2=A0 But the vRu= n packet
>> will be used when startup-with-shell is both on and off.=C2=A0 Wha= t this
>> means is that when gdbserver receives a vRun packet containing = 9;$VAR'
>> it doesn't know if GDB actually had '$VAR', or if GDB = had '\$VAR'.
>> And this is a huge problem.
>>
>> We can address this by making the argument splitting for remote >> targets smarter, and I do have patches that try to do this in this=
>> series:
>>
>>=C2=A0 =C2=A0https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.= aburgess@redhat.com
>>
>> That series was pretty long, and wasn't getting reviewed, so I= 'm
>> pulling the individual patches out and posting them separately. >>
>> This patch doesn't try to make remote argument splitting.=C2= =A0 I think
>
> s/make/do/
>
>> that splitting and then joining the arguments is a mistake which c= an
>> only introduce problems.=C2=A0 The patch in the above series which= tries to
>> make the splitting and joining "smarter" handles unquote= d, single
>> quoted, and double quoted strings.=C2=A0 But doesn't really ad= dress
>
> s/But doesn't/But that doesn't/
>
>> parameter substitution, command substitution, or arithmetic expans= ion.
>> And even if we did try to address these cases, what rules exactly<= br> >> would we implement?=C2=A0 Probably POSIX shell rules, but what if = the
>> remote target doesn't have a POSIX shell?=C2=A0 The only reaso= n we're
>> talking about which shell rules to follow is because the splitting= and
>> joining logic needs to mirror those rules.=C2=A0 If we stop splitt= ing and
>> joining then we no longer need to care about the target's shel= l.
>>
>> Clearly, for backward compatibility we need to maintain some degre= e of
>> argument splitting and joining as we currently have; and that'= s why I
>> have a later patch (see the series above) that tries to improve th= at
>> splitting and joining a little.=C2=A0 But I think, what we should = really
>> do, is add a new feature flag (as used by the qSupported packet) a= nd,
>> if GDB and the remote target agree, we should pass the inferior >> arguments as a single string.
>>
>> This solves all our problems.=C2=A0 In the startup with shell case= , we no
>> longer need to worry about splitting at all.=C2=A0 The arguments a= re passed
>> unmodified to the remote target, that can then pass the arguments = to
>> the shell directly.
>>
>> In the 'startup-with-shell off' case it is now up to the r= emote target
>> to split the arguments, though in gdbserver we already did this, s= o
>> nothing really changes in this case.=C2=A0 And if the remote targe= t doesn't
>> have a POSIX shell, well GDB just doesn't need to worry about = it!
>>
>> Something similar to this was originally suggested in this series:=
>>
>>=C2=A0 =C2=A0https://inbox.sourceware.org/gdb-patches/20211022071933.3= 478427-1-m.weghorn@posteo.de/
>>
>> though this series didn't try to maintain backward compatibili= ty,
>> which I think is an issue that my patch solves.=C2=A0 Additionally= , this
>> series only passed the arguments as a single string in some cases,=
>> I've simplified this so that, when GDB and the remote agree, t= he
>> arguments are always passed as a single string.=C2=A0 I think this= is a
>> little cleaner.
>>
>> I've also added documentation and some tests with this commit,=
>> including ensuring that we test both the new single string approac= h,
>> and the fallback split/join approach.
>>
>> I've credited the author of the referenced series as co-author= as they
>> did come to a similar conclusion, though I think my implementation= is
>> different enough that I'm happy to list myself as primary auth= or.
>>
>> Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de> >> Bug: https://sourceware.o= rg/bugzilla/show_bug.cgi?id=3D28392
>>
>> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
>> Tested-By: Guinevere Larsen <guinevere@redhat.com>
>
> Thanks for the detailed explanation.=C2=A0 This makes sense to me.
>
> I also tested this patch and found no problems.
>
> Approved-by: Kevin Buettner <kevinb@redhat.com>

Thanks for the feedback.=C2=A0 I made these changes and pushed this patch.<= br>
Thanks,
Andrew

--000000000000fcbdc2063ee7484d--