From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id 5D87E3858D33 for ; Tue, 22 Aug 2023 02:39:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5D87E3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-ot1-x32b.google.com with SMTP id 46e09a7af769-6bb07d274feso3089905a34.0 for ; Mon, 21 Aug 2023 19:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1692671975; x=1693276775; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=bW2k+tehGUiWq4RvYydSXDaT9a+lUWwbcmfvbpm576A=; b=pMLDT87r2uanomjD2bwZbX0RjH/OYka40MvgRGQvKlZ5ZxxzQmr78ob7zeRd+ij73l f4O1DJFjTvrP1iB0ouhmTX+R4rXpX+5mejPrbeGplDWbngua+rtD8A0kdjpBTELpMWXq ahArBTR5CgZTtWVs+nky70rcrdAn+QahobIw3/5k4gdHPFy8XOmuyob2hT7hUAgRjEVh aa/5Co6KBsgepRpoKoGRf0T6jrRDGecEODq/6R4CjgZ2t+DeUp5a0zB8eKJWI7lz410e NzC5LGs77G3WfZZs+30vzptbulT7lreFzj+DVXcbdNZICS3UeA+ohIPtETSv0zlndX/U 20WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692671975; x=1693276775; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bW2k+tehGUiWq4RvYydSXDaT9a+lUWwbcmfvbpm576A=; b=Ue9FK1i1CXsKbYhcTYBoUDdGVaB80W13nDUaxl3Sm2G768jgUWH87M1bAN/AaqF5uK +JvQ4KOwZnBEu9zxQtfLa4zld1b6KQrsDC1M2xILP8aQ8t1feuBK62jIR3LpM0L8dxwr UWpzuPcWV7KHmd3bczqli88tba0Y1ZVXFD6MQR8zzmaZ2pbN+Ov2BQUdBOw7ne1zd/ig //2fwbdBubsAPZKlN2qi8ZNZApjysdI7FUIR1ub5ej0uRpT/ZzTYkNp85FSj/r5VVB6l G3pphtSUjerp4ThwoupWiz3Fc9A5EVCiOORAoEjNfW1YVtO7iuUCCZHniHS6J+4chHq8 iX1g== X-Gm-Message-State: AOJu0Yx4gFaSNYtXaPT4IgYXaz38/tESDr5C38HKhukhg+N8c4mStYQw wdMGE08AQpOGc0RA+cSX3B2Ldg== X-Google-Smtp-Source: AGHT+IH/NgBRD0v/r8S5WOjU21Sq+30oN+VJevhuuLivbPgYxc9YToOM8VRtFoPiFcx44Rls2r4v9w== X-Received: by 2002:a05:6830:108d:b0:6bd:67c:ba9c with SMTP id y13-20020a056830108d00b006bd067cba9cmr10233343oto.35.1692671974770; Mon, 21 Aug 2023 19:39:34 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8470:4be6:723d:5360:d64b]) by smtp.gmail.com with ESMTPSA id i10-20020a9d624a000000b006b9848f8aa7sm4154368otk.45.2023.08.21.19.39.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Aug 2023 19:39:34 -0700 (PDT) References: <94e68e6c1400ede2e9e46fc8ef76bd82aa533e0e.1692200989.git.aburgess@redhat.com> User-agent: mu4e 1.10.5; emacs 28.2 From: Thiago Jung Bauermann To: Andrew Burgess Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 07/10] gdb: add qMachineId packet In-reply-to: <94e68e6c1400ede2e9e46fc8ef76bd82aa533e0e.1692200989.git.aburgess@redhat.com> Date: Mon, 21 Aug 2023 23:39:31 -0300 Message-ID: <87fs4ber6k.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello Andrew, This is a very interesting feature, thanks. For now at least, I have just one comment on the machine-id for Linux: Andrew Burgess via Gdb-patches writes: > Generating a suitable machine-id is, I think, always going to be > target specific. As such, I've structured the code in a way that > allows different targets to provide their own implementations, but > I've only implemented a solution for the Linux targets. > > The reply to a qMachineId packet looks like this: > > predicate;key=value[;key=value]* > > the idea being that the reply consists of a number of key/value pairs, > each of which must match in order for GDB to consider the machine-id a > match. I currently propose just two keys: > > linux-boot-id - this returns the value from the file > /proc/sys/kernel/random/boot_id, which, if I understand correctly, > should be unique(ish) for each boot of each machine, and > > cuserid - this returns the value of the cuserid call. > > My thinking is that if we know we are on the same machine (thanks to > linux-boot-id), and we know we are the same effective user (thanks to > cuserid) then there's a pretty good chance that GDB and the remote can > access the same set of files. Unfortunately the two keys above won't detect when GDB and gdbserver are running on the same machine but in different containers. I suggest adding a new key for that: mountinfo - The hash of the contents of the target's /proc/self/mountinfo file. The hash algorithm could be either SHA1 or MD5, which have implementations in libiberty. Disclaimer: I'm no expert in Linux containers, so I wouldn't be surprised if there were a better way to differentiate containers (or, more specifically for this use case, filesystem namespaces). -- Thiago