From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id O/vUICdUSWgzegkAWB0awg (envelope-from ) for ; Wed, 11 Jun 2025 06:02:15 -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=Q6lEc5Q+; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 6ECDC1E11C; Wed, 11 Jun 2025 06:02:15 -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 F1F3D1E089 for ; Wed, 11 Jun 2025 06:02:14 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8A7903857C67 for ; Wed, 11 Jun 2025 10:02:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8A7903857C67 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=Q6lEc5Q+ 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 A7D573858C2A for ; Wed, 11 Jun 2025 09:58:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A7D573858C2A 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 A7D573858C2A 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=1749635931; cv=none; b=aIWq9clKP7bLoi4e8BkXeDxHuQ+w/C1DuVkWaCEl5j0gcvo2uYVF+cLNjBoxYroZKJ3IN1fdT+yHOqKd06M5KCueQdPyFcffzWon0oy4b6Sgxuhf7TyI4guZUZhMKjR9Wm4iB99jMoNFBzwILk52MYLXfMODMTUHwJcwLoBFX4E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749635931; c=relaxed/simple; bh=3+3G/7KcFuDSiFDBoox8zB2CqQQAM0U9c3tzGTuSNdA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=P9/i/Gkd3zparA1MxJfxka4GG15g/0jmcd5kSSZw9QRHN/XURqyDfg/nuYgmeYGPtm3kCDeylIQfyEWJrmyds9a/Nz3PxGWSOfK+aoJ0+W5n1Gq5J3z0EuA6OSiHIypvheNXfdcbtS3lV9u4VaQ6oUgK1S4qVH5P/xWF39BJw+4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A7D573858C2A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1749635931; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8VJao6M5B72NN0REAM3QUdycD1dnWgubwl0sFRuFKrY=; b=Q6lEc5Q+pRLWtvK/7ayCMNoKAGJx+Y+x39MPBLoiOLTOIjioCWdWsRjrfiE0dx5CH+mj7d pv7vb0dIj6qow78yIMmHzFpntaSQFZ5pCHguV9tLjGXuZmjp+IQJnqF1r0jHZX7u6tunDI eFtxz1x6hWPZ6kndW/400SQdoBo7J3k= 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-197--DcQ4qoCP0G98Bii9f53CQ-1; Wed, 11 Jun 2025 05:58:49 -0400 X-MC-Unique: -DcQ4qoCP0G98Bii9f53CQ-1 X-Mimecast-MFC-AGG-ID: -DcQ4qoCP0G98Bii9f53CQ_1749635929 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-453018b4ddeso21148045e9.3 for ; Wed, 11 Jun 2025 02:58:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749635928; x=1750240728; h=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=8VJao6M5B72NN0REAM3QUdycD1dnWgubwl0sFRuFKrY=; b=hfjMzqMOTNtPw8CvMFAm5iKwyn5QRbKLY07+SFfs2FKIrMMAw35M+4czO+eARB7hxU r3dZp+sbS4I5mkVvElisX/rPp9w8Z/a3V704u+Smo+Zx3MWXabXH5zId8CJnxKroYNfK umFk1wrRy/m+pgnBFeUFRHfe2gecYn8yI+AXnFRnQuqk75wucdJKx95GmKizoYiaCRdq WZYQna4XqqFRYiN8r5LsxLghx0ybZE4fyOpXLQDNZpG/hb0inBTGF/yFaT/dA+Njgo9o FCHsVoq++dqB+6MKCl0+wR/pGwdIB6Dx/tkEv9zG50THxL5084s16dFdK53hZ8Bp61l0 oTjQ== X-Forwarded-Encrypted: i=1; AJvYcCWND8oNyVU79s9kT6E4ixPDdOP7rlcC3TbYG/jZW09O/AgOznNhFrsubApqherVgzxw2Ky/eV6dywYu7A==@sourceware.org X-Gm-Message-State: AOJu0YytFE6SeLyR8BkLgGk8E7PwDFVJr3EEwJZMvx5IwGsRG4C7cO/h n/x3g9s0xdz6CqAD4PGM+lwQhkKeTd5J+0yLSgHbOM5OTy7K1fzQtCPi46TtPK0uj8uuoYQ8U9X +h44Ubsn8ZJomgmmkUmzZbknzFZU//VdcgheHgBX2bwHT2HSizptXTS4lWOd0vEFwanh9s7s= X-Gm-Gg: ASbGncvbsNVoxGTQOj8rBI1klzEWAvrM0/ZwZNEdUjrUqbtAaxO0JOnGuK6N80SwJ7X yD1KIgGHX/LmnddPgeqNsMOQf698vt9bfTm/rDnfdEpxjZw9BUczX3S0GpCD9ST+FAfeS0X95Ti jjZaWGo5oOOGHn2uqsI/ht5PjaCi9Jq6CUTNvFZEghTDX+GJBA7RDlGyLp3/DJZrl8v7KM/i1Oc 6S+CelMtR4Z60YloxRFVCM+b0d8sM6JF2aA3aCfegu/Y343CttuW+8nWgfrDac1xfep4P+bf41M +E3wW1uqtS5OmN/AY7ghTWsGfvpSx88S9OLKFLhnf3DI5io= X-Received: by 2002:a05:600c:354a:b0:453:1058:f8c1 with SMTP id 5b1f17b1804b1-453248a0720mr27056465e9.3.1749635928397; Wed, 11 Jun 2025 02:58:48 -0700 (PDT) X-Google-Smtp-Source: AGHT+IENXzddBOiiYW2efkpRdjXEUvHM5QE20R9AXY+CBWXqwyX2uHldhoiV3SKNuwZJwsdaJukJvw== X-Received: by 2002:a05:600c:354a:b0:453:1058:f8c1 with SMTP id 5b1f17b1804b1-453248a0720mr27056185e9.3.1749635927991; Wed, 11 Jun 2025 02:58:47 -0700 (PDT) Received: from localhost (75.226.159.143.dyn.plus.net. [143.159.226.75]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-45324fc3b52sm16705145e9.0.2025.06.11.02.58.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Jun 2025 02:58:47 -0700 (PDT) From: Andrew Burgess To: 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: <87zfeehany.fsf@redhat.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> Date: Wed, 11 Jun 2025 10:58:46 +0100 Message-ID: <87wm9iha5l.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 2gS3OI5auHN5u8MSphn5Yc-GfZMYP4_rXacJMvQW14k_1749635929 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 Andrew Burgess writes: > Fabian Kilger writes: > >> While looking at it, I've noticed all implementations of stat functions >> actually use lstat and not stat. This maybe should be modified in the >> namespace case as well and I'll be changing this for v2. However, I >> could not directly find a rationale behind why *_stat functions call >> lstat instead. Possibly, it might make sense renaming the >> target_fileio_stat to target_fileio_lstat as well, though this would be >> an independent change. > > Without digging into the history I say for sure why it's lstat over > stat. > > I agree with you that renaming the API might make some sense, though I > suspect we're really a little stuck, the remote protocol packet is > called 'stat', which is unfortunate, we cannot really change that. OK, so I dug into the history, and it would appear that (a) it was just a mistake, and (b) it was all my fault :-/ The code in question does want lstat, so really the whole API should have been called lstat. Most of this can easily be fixed, but the remote protocol part we're unfortunately stuck with. Though I wonder if we can "fix" this by just have a 'stat' and 'lstat' remote protocol packet, change 'stat' to do an actual 'stat', then on the GDB side we'll change the internal target API to be called 'lstat'. This would effectively orphan the remote 'stat' packet, as nobody would use it, but that's OK I think, and only minimal overhead. I'll take a look at rolling something like this together. For you, right now, you should name your functions 'stat', but do an 'lstat' to be consistent. Thanks, Andrew