From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id MA5JKyqXSWjhtQkAWB0awg (envelope-from ) for ; Wed, 11 Jun 2025 10:48:10 -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=TRSHxl3E; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 94C751E11F; Wed, 11 Jun 2025 10:48:10 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-10.1 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, RCVD_IN_VALIDITY_RPBL,RCVD_IN_VALIDITY_SAFE 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 C42ED1E089 for ; Wed, 11 Jun 2025 10:48:09 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5F4563858290 for ; Wed, 11 Jun 2025 14:48:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5F4563858290 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=TRSHxl3E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 938FA3858D20 for ; Wed, 11 Jun 2025 14:47:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 938FA3858D20 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 938FA3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749653254; cv=none; b=RgkzFw7f9irESnBJYUTgw0MwmDxXBIEvF0TuMkayvotQ7hvmNsyr7RLpW8NJocIBgQGesiJy75huZOpVf0V+tIG6yJ/9FvMo6HNGBJ/1ryvRzXxO8gsRJBM/b+r3e6JHZUQxFRJh9nOGDwkb/q/+B2+NWNDk/ug9eVvIV6sggFc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749653254; c=relaxed/simple; bh=XyDHKP1xREMwlU6eX7yVYGeZ0ByUnQnua5UfSW2jOHg=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=SC+UuhqRdwEVL6M6dsKcMzktwYqHUK4slkAgNI3jcmM0WscZYlqIOMJlPnctLQjNj2j0B2ZNe+8PG0fn71lMmc8eOAu2worwoP449gkNTcMplGhbNySVEkxtyOn6Lshhpt5iWSlVQhz+9+2Hi1IRGVv+yjwL405O+1rvQ4eKCc8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 938FA3858D20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1749653254; 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: in-reply-to:in-reply-to:references:references; bh=WVams2bzWVkiGLGT56E1xqWo95tzj9EvKp614qYfEu0=; b=TRSHxl3EjWMOGq3karBryIczLNaxMCKOSr0fQ61cDL7P+Emtes2sH85APjl9vmdTBfhCg8 MqfA8u8WeBiStAmKMX8r30JP8NjSY+JLGWtr2nLWQjhKRWr1bz/spKjT4GQa6eDPQHalkJ wkCCctcCyrJylU/dl7bSDYnWkdtLHrI= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-225-IfhqeqJjN16yerM8ibp67Q-1; Wed, 11 Jun 2025 10:47:33 -0400 X-MC-Unique: IfhqeqJjN16yerM8ibp67Q-1 X-Mimecast-MFC-AGG-ID: IfhqeqJjN16yerM8ibp67Q_1749653252 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4530c186394so17247525e9.0 for ; Wed, 11 Jun 2025 07:47:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749653252; x=1750258052; h=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=WVams2bzWVkiGLGT56E1xqWo95tzj9EvKp614qYfEu0=; b=pvPVrS0AxGi5nqeG4XGwAgTCv6M1VSbox6EbXzyX9991c5XaHTozpbayL8r6HtZSpD 8vbDBMiab2qAVe5JU9rRFcYm0AxT1oQKbHwEiwl+4LvE6KQ6izoYCqM/4na+yrsSK9KE F8418U+KORRWVTtf4SxKfkMMl7VJJIGSyy/OKnOYopG5/IbXyrdaOk3wiCs2+Tv5D1tt 1/SBxHpLXZNtcazRv/ogTr5nIbSXHdc6YCNSZApuWYx5Wu4uKAryrnX731ol4D/8xBI0 9JbbkOinQAxE+oe4PTEJ2EIC7h3WpdXUB8LoIkDDgvbt/cm2rs6SJUm0fDqetLzLlqOF BE3g== X-Forwarded-Encrypted: i=1; AJvYcCVMCiA3Hx+BK59AlRpHTkHnFLOKfr4R3F6l1GOY9lrtpUZ/DDQkzUF3y6Mf68IYlA4WwlKM1EYE/ziYhg==@sourceware.org X-Gm-Message-State: AOJu0Yxv9O3+J7ZxyP0iX+hZphbKOxezvQ6VlFJzfWIYIw1CbNO02xm/ pjZMC5UidtQLYUVVtvUZPTFx1GzoszuXZ/nDAJlDnI2CC82njEDrZqq4ZnWNnim07ThWV6k1Yar tX1ijIiO96XmbW0t3ln5yyIwz4neTFgAfpnz0vIgPI2DYPLB5ak35Mcl9l91GomY= X-Gm-Gg: ASbGncvubPaDFyJYREkngy/VFTpXpKgO53r4L1h9h2NnhUsmPgrPUnOTTp58jk7K7xx JBsJOkRZvSaQ1fQstM9IWUH1nkQYvyMVX4WArUEecvx+y/+VnHY5X6FORZ3+/BNhq8Qd1B2DOa+ MKR3h++7vIvU69zC9DGV8bWv5LOxfw/shENbe/PyMMpHwiDVE99n+8AWhJ13SX4fIxho8uIMTsg 3irQ2LA4Dwe3RwXqzMK8vTju4mM8GGnHtNtTDQurZ9Tm3ct1D1qge7Yh+qyGosOj02dVglVvFDO 2RBy4mBdzmLSWy6MVIZiVpX88rJWN3pKkPtz+12ZRA1eJEU= X-Received: by 2002:a05:600c:4e16:b0:44a:b9e4:4e6f with SMTP id 5b1f17b1804b1-4532b916069mr833875e9.16.1749653251976; Wed, 11 Jun 2025 07:47:31 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGeDfTCb+FxFNy6MAq9diz4dqXhTci6yGNTwHPcb+yF9RynmGEZ+duMzMK8EqSnQmuuTJG9ow== X-Received: by 2002:a05:600c:4e16:b0:44a:b9e4:4e6f with SMTP id 5b1f17b1804b1-4532b916069mr833675e9.16.1749653251595; Wed, 11 Jun 2025 07:47:31 -0700 (PDT) Received: from localhost (75.226.159.143.dyn.plus.net. [143.159.226.75]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a53229d9adsm15312225f8f.9.2025.06.11.07.47.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Jun 2025 07:47:31 -0700 (PDT) From: Andrew Burgess To: Tom Tromey Cc: Fabian Kilger , gdb-patches@sourceware.org Subject: Re: [PATCH 1/2][PR GDB/32956] gdb: implement linux namespace support for fileio_stat In-Reply-To: <875xh2o18y.fsf@tromey.com> References: <20250511150113.3163767-1-kilger@sec.in.tum.de> <20250511150113.3163767-2-kilger@sec.in.tum.de> <87y0umgub1.fsf@redhat.com> <73be8b96-3a2a-4e64-885e-76f7b7ed6be1@sec.in.tum.de> <784e0c86-f879-46d5-8631-702e6ae611bc@sec.in.tum.de> <87zfeehany.fsf@redhat.com> <87wm9iha5l.fsf@redhat.com> <875xh2o18y.fsf@tromey.com> Date: Wed, 11 Jun 2025 15:47:30 +0100 Message-ID: <87tt4mgwsd.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: OSj6f2_zPxAvHkadYNDct1kCgRBcL8RpLcrg8ZtKMXc_1749653252 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Tom Tromey writes: >>>>>> "Andrew" == Andrew Burgess writes: > > Andrew> OK, so I dug into the history, and it would appear that (a) it was just > Andrew> a mistake, and (b) it was all my fault :-/ > > A classic programming story, I can't tell you how many times I've been > there. > > Andrew> Most of this can easily be fixed, but the remote protocol part we're > Andrew> unfortunately stuck with. Though I wonder if we can "fix" this by just > Andrew> have a 'stat' and 'lstat' remote protocol packet, change 'stat' to do an > Andrew> actual 'stat', then on the GDB side we'll change the internal target API > Andrew> to be called 'lstat'. This would effectively orphan the remote 'stat' > Andrew> packet, as nobody would use it, but that's OK I think, and only minimal > Andrew> overhead. I'll take a look at rolling something like this together. > > Wouldn't this negatively affect any existing remotes that implement stat-as-lstat? > (I don't know if any of these actually exist.) Yes, you are correct. But: - The vFile:stat documentation is pretty vague, it just says: get information about a file. So if there are other remotes that implement this then they probably implemented 'stat' anyway as that would be the logical first choice. I would propose, as part of this change, to better document what is expected from 'stat' and 'lstat'. It could (maybe) be argued that the current 'lstat' implementation was a bug, and it should have been 'stat'. - The vFile:stat packet was only added in GDB 16, and there's only the one use of it from GDB. In most cases implementing vFile:stat as an actual 'stat' will go unnoticed, though the GDB testsuite does rely on it being an actual 'lstat', so if someone is testing a custom remote against the GDB testsuite they might have figured out that they needed lstat instead of stat. My hope would be that adding a new vFile:lstat packet, and noting in the NEWS file that the vFile:stat should _really_ be 'stat' would allow any other remotes to course correct. If you feel strongly though then we can for sure just leave the vFile:stat packet implemented as 'lstat' and document it as such. Thanks, Andrew > > It might be better to just document it. > > Tom