From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id BRcMBR14ymhytgcAWB0awg (envelope-from ) for ; Wed, 17 Sep 2025 04:58:05 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=OAqSO4/E; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 022661E0BA; Wed, 17 Sep 2025 04:58:04 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 F36ED1E047 for ; Wed, 17 Sep 2025 04:58:03 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 833D2385843B for ; Wed, 17 Sep 2025 08:58:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 833D2385843B Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=OAqSO4/E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 76C243858C41 for ; Wed, 17 Sep 2025 08:57:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 76C243858C41 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 76C243858C41 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1758099449; cv=none; b=UOmjSGD45j5nx8q2lWXSAzL+wA1Z4AbDxDnuX0HxwILPSMl2kxJLhNcD53wAzLPIN4H5HLsbDNJeXve+aTfdjvp/iyJCXDmt+T2I5/SZN8HF2WTRwnrSOi6fqMtxXOvBbCQLzcV7ZtI0OE5CzHWdojrhjthfXCScQG0ynEmwKLw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1758099449; c=relaxed/simple; bh=E/f9O4dlfW1sHhaSvBELlvuLRif7NzN2BdhNR0/JrGg=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=DOx+aMKSLbe2GuZLp474F3S0lnV22eQWBj9+3AfXN902933l+YDiVj4scZ6Q5NyquaaV3jy0MEHjjV8LLryjDIS7XR7Eej61kGnuilZHUBS/0NGOXma3/doFEfYHH37mZ0efEH2DHZIJ1LqR8O3Lppco/wacHEfbrwPejPD4P3s= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 76C243858C41 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1758099449; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=j8tykEEira3u9WaHlcIqzAiJb9L+kPNfbEx/zzfvyBY=; b=OAqSO4/EdpiAJRIaVGoWaJWB1JsDKjOjNL5tWJOj/kHqt9j024n8a75+7Tc2g74BeB/Dc8 kKlDrCwpBkO4eDTm7iQaSajZfUbKUW0L/YuXnzNDSlo+3bHVKHfxP2p+Qb/FxZYCLwOHP1 LCvE27YLpeKWwksZdPT/zBmEQ3G+whc= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-38-dhJQYK9HP2SGgLTHlVY2fQ-1; Wed, 17 Sep 2025 04:57:28 -0400 X-MC-Unique: dhJQYK9HP2SGgLTHlVY2fQ-1 X-Mimecast-MFC-AGG-ID: dhJQYK9HP2SGgLTHlVY2fQ_1758099447 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-45cb604427fso40364665e9.1 for ; Wed, 17 Sep 2025 01:57:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758099447; x=1758704247; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RN0JXmPcjRXF1q4w9N+2GNtL9rGfgYnjltmnm3rzCnc=; b=BjQvctZUxTaS6PTVwLdjNDxzK4JtCngh/NjwLFpbA5+nd5r8tgW3Ec861Vo1AEG+z4 BaYurZDTnxc0tczbceW0/lQsyr/kNINuHuUodPXgTP2+3zzWk+jVZ+hphLzCkxpg5xRl hzcqJQdfPCzjt/KMEs+TH+yxW13f3HNVeYEFuQea2scFYhi2X1tR15+NWk+YIWZFnMlK 5R194Yvsw9VC5l4exwJ0HTiok3WEuI1gnohvI4JRwmp5ZutXzoQPomC6FjHge3HwdKb4 gYkWnSPkFa+oST1DVnMw7o/MiECffcKk9wPKndJkH/Eb3HjoeN6Rn/SiOnm8nrzLruP7 AMHA== X-Forwarded-Encrypted: i=1; AJvYcCUQGKpLclR7lUkfSNM8Sl4NosbTH/jrCkFoI4ibarkGwP3sjgjEJuQvKrgL8ZgAdpb2m/sWGhTCQCDjww==@sourceware.org X-Gm-Message-State: AOJu0YyFhi8r12dyR0X7Fg6I7vyHGKyP03M3gl87KHkb687qvAMFK6Ae k7oXsiek9LEWHOJrqmBt7xbYhq6WZ91curiaIp1Wz88po0N26JRspV+e4ZcXdWZbZjrmi71160g n4LnsCfVrA1NmJLXYoikowanDFvJFDBuyY4PLTMD6q/fh5R4cThp3NL2Q4ErQ6M8= X-Gm-Gg: ASbGncvW7Li9mxf1mUFUV0ANHgXqyfQmm+x/1g2wf+byjrIMChDfFNS/eQVjmQbismv QE242o94oV3tnTLwwqId5f51/7vHrCmCJFDXbvu+tx9VS2RKlImx2yvVrIf5gyFHxXWW0iw7+eP Cy86aBeRto1RpZLg0Rb78Yb2hL4dvJ+1tamLFw2SgMQkFWpxPmqXLtZG/HJLGgUkrRCdZ165Peb ndX9wIBkcMovL9YybDkLUjJHSDZlYeS/w1UmGaikFkWYKQLKqQY+KMBL1hRWFw+Rql/+8TO6IZ0 neuFRw5JkXhyXWy6GoRuSjPWoIqVfUP2Qlg= X-Received: by 2002:a05:600c:350e:b0:458:a7fa:211d with SMTP id 5b1f17b1804b1-4620683f829mr11192525e9.29.1758099446812; Wed, 17 Sep 2025 01:57:26 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFgQhsIOgT+0x/0B2KY2XXSjG8uUJHmwbbAQEdrfLXx7sm1vfJTYPQy3gw+G7HAtYMM7EDiPA== X-Received: by 2002:a05:600c:350e:b0:458:a7fa:211d with SMTP id 5b1f17b1804b1-4620683f829mr11192245e9.29.1758099446235; Wed, 17 Sep 2025 01:57:26 -0700 (PDT) Received: from localhost ([31.111.84.207]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-46137c0f606sm28056645e9.9.2025.09.17.01.57.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Sep 2025 01:57:25 -0700 (PDT) From: Andrew Burgess To: Luis Cc: Kevin Buettner , gdb-patches@sourceware.org, Michael Weghorn , Eli Zaretskii , Guinevere Larsen Subject: Re: [PATCH] gdb/gdbserver: pass inferior arguments as a single string In-Reply-To: References: <20250624145052.4659642b@f41-zbm-amd> <874it8htc2.fsf@redhat.com> <87ikhigygr.fsf@redhat.com> Date: Wed, 17 Sep 2025 09:57:24 +0100 Message-ID: <87frclh2x7.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: wlsOLD196S2DoL8Brv58eVfuMYWnmZsIKczSuuZB-PE_1758099447 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 Luis writes: > On 16/09/2025 17:21, Andrew Burgess wrote: >> Luis writes: >>=20 >>> 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? >>=20 >> Here's a proper fix, with tests. >>=20 >> Let me know what you think. >>=20 >> Thanks, >> Andrew >>=20 >> --- >>=20 >> commit 5dfd9f9da130c5deae9ac81fcda1bd18f8951eac >> Author: Andrew Burgess >> Date: Tue Sep 16 17:02:01 2025 +0100 >>=20 >> gdb: fix --args handling when inferior argument have dash >> =20 >> After the commit: >> =20 >> commit e5e76451fa82e0bc00599af96382b361c3d6ac32 >> Date: Fri Oct 22 07:19:29 2021 +0000 >> =20 >> gdb/gdbserver: add a '--no-escape-args' command line option >> =20 >> Inferior argument handling on the GDB command line was broken: >> =20 >> $ gdb --args /bin/ls --foo >> ./gdb/gdb: unrecognized option '--foo' >> ./gdb/gdb: `--args' specified but no program specified >> =20 >> Before the above patch the definition of the '--args' argument in t= he >> long_options array (in captured_main_1) was such that the >> getopt_long_only call would directly set the 'set_args' variable to >> true if '--args' was seen. >> =20 >> This meant that, immediately after the getopt_long_only call, we co= uld >> inspect set_args and break out of the argument processing loop if >> needed. >> =20 >> After the above patch '--args' (and the new '--no-escape-args') no >> longer set set_args directly via the getopt_long_only call. Instea= d >> the getopt_long_only call returns an OPT_* enum value, which we the= n >> use in the following switch statement in order to set the set_args >> variable. >> =20 >> What this means is that, immediately after the getopt_long_only cal= l, >> set_args no longer (immediately) indicates if --args was seen. Aft= er >> the switch statement, when set_args has been updated, we go around = the >> argument processing loop again and call getopt_long_only once more. >> =20 >> This extra getopt_long_only call will, if it finds another argument >> that starts with a dash, update the global optind to point to this >> option. At this point things have gone wrong, GDB has now lost tra= ck >> of the argument containing the program name the user wanted us to >> start. This leads to GDB existing with the above error. > > s/existing/exiting? > >> =20 >> The solution is to move the check of set_args to either before the >> getopt_long_only call, or to after the switch statement. I chose t= o >> move it earlier as this keeps all the loop exiting checks near the >> beginning. >> =20 >> I've added more tests that cover this issue. >>=20 >> diff --git a/gdb/main.c b/gdb/main.c >> index 04c33638bec..f3049600a06 100644 >> --- a/gdb/main.c >> +++ b/gdb/main.c >> @@ -866,9 +866,14 @@ captured_main_1 (struct captured_main_args *context= ) >> { >> =09int option_index; >> =20 >> +=09/* If the previous argument was --args or --no-escape-args, then >> +=09 stop argument processing. */ >> +=09if (set_args !=3D NO_ARGS) >> +=09 break; >> + >> =09c =3D getopt_long_only (argc, argv, "", >> =09=09=09 long_options, &option_index); >> -=09if (c =3D=3D EOF || set_args !=3D NO_ARGS) >> +=09if (c =3D=3D EOF) >> =09 break; >> =20 >> =09/* Long option that takes an argument. */ >> diff --git a/gdb/testsuite/gdb.base/args.exp b/gdb/testsuite/gdb.base/ar= gs.exp >> index 573543cc1f8..03e5e57ee20 100644 >> --- a/gdb/testsuite/gdb.base/args.exp >> +++ b/gdb/testsuite/gdb.base/args.exp >> @@ -186,6 +186,18 @@ proc run_all_tests {} { >> =09set ::env(TEST) "ABCD" >> =09args_test "shell variable" {{$TEST}} {\\$TEST} {{ABCD}} >> } >> + >> + # At one point we had a bug where, if the last inferior argument, >> + # appearing after --args, looked like an option GDB might be able >> + # to process, e.g. started with a dash, then GDB would try to >> + # process it. This would mean all leave GDB in a broken state, > > Maybe a typo in "mean all". It doesn=C2=B4t sound clear to me. Maybe you= =20 > meant "we'll"? > > If you think it is worth it, we could mention the specific example of=20 > the invocation that ran into issues. I made the fixes you suggested, and pushed this patch. Thanks, Andrew