From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id A32723858C52 for ; Thu, 2 Feb 2023 19:52:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A32723858C52 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-oi1-x22c.google.com with SMTP id dt8so2410082oib.0 for ; Thu, 02 Feb 2023 11:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding: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=mhZaRi9/pIhh653Q1eBVpPXM1gWIhaNPKTK2qo/CLeY=; b=nyNlEEhIQ/4RVjkrgZPFMTYOZ9BRlyAcqMYG3yY54pnFk8OIiGVHnb7kNgcKFrTu+5 35Q4VkSeafIxKNWwRb+X8S4qFgFHKtwncqZqopfuHfLPTo47TnlfYTxN3PedOWYJX0kY DWQGMVXYNTpyzYu85pnaUEX2OWkJJx06tUHaCtCx+3plLqyoJWmqNs+joup1kLFHTE+T 5fF6vanLNhJTy+Y9sjFvYzkJmax0gSmQwgzFWbmt8jfo1QBPOdpS+v56ZKesOOaupJoo l5n47/mOOTTIMSA5Jn8ZNQIBrUijIJGaNyDaGcKZUVdPRdyIEimY9xyRLEOIp630rQNC n5ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=mhZaRi9/pIhh653Q1eBVpPXM1gWIhaNPKTK2qo/CLeY=; b=vq5xKRVg87Io6UHbumVhn0oRjAxR6wQMD7iWZUKEnMfeRTZRLj71+b4gxR2bHYPqCS c4Lbj0VpA3BKK5tmZ+DA8ZUff+Qgzswrotw5wnffqpzLCyH6wobxurdJIxsGdQzrrjn8 +EVnsZBJz5lPM5phb0Pa1d+WT8dXmefNJkP4b+PKkT2j6CSVVazT9gSziULoaItTqy6K eQoyfr1rMpKV2j0wzX//Hvvz4vji0dSsTYeRTjNqXIPccxr4gn9Gst3VwWd0hY7mvD8G S5NB+43QohHdi6qLpZoRkAQcAyzxA2CkLdF/La7v1VPz0nRlYOjXduncPWq4/yunmguf iZTQ== X-Gm-Message-State: AO0yUKWSGQwoP4uEdd/igBpEGNFlT/Rcy7DFmRKtVOe5NAsilBrMDIza 878117RctYu3A7ciiEfkMvn6ew== X-Google-Smtp-Source: AK7set9/H3CfGvfKLLoI4fo2OQ3FdRDGNEeexn5/+FwjB6KaXpPwNXPL1ATIGsmnb3M/XENswWCjlg== X-Received: by 2002:a05:6808:16a6:b0:36e:b867:76d0 with SMTP id bb38-20020a05680816a600b0036eb86776d0mr3991817oib.58.1675367561452; Thu, 02 Feb 2023 11:52:41 -0800 (PST) Received: from localhost ([2804:14d:7e39:8470:7132:fbe:2b2e:ae3e]) by smtp.gmail.com with ESMTPSA id v7-20020a056808004700b003785996ef36sm59961oic.19.2023.02.02.11.52.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Feb 2023 11:52:40 -0800 (PST) References: <20230130044518.3322695-1-thiago.bauermann@linaro.org> <20230130044518.3322695-6-thiago.bauermann@linaro.org> <87bkmdtp4n.fsf@redhat.com> <502f0bd0-9b18-9a31-0094-7a9bd4778bd2@simark.ca> User-agent: mu4e 1.8.13; emacs 28.2 From: Thiago Jung Bauermann To: Simon Marchi Cc: Andrew Burgess , Thiago Jung Bauermann via Gdb-patches , Simon Marchi Subject: Re: [PATCH v3 5/8] gdbserver: Transmit target description ID in thread list and stop reply In-reply-to: <502f0bd0-9b18-9a31-0094-7a9bd4778bd2@simark.ca> Date: Thu, 02 Feb 2023 19:52:38 +0000 Message-ID: <87r0v7alq1.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.5 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: Simon Marchi writes: >> Having read some of the later patches, I have some additional thoughts >> here: >>=20 >> I think we should make it explicit here that IDs are connection wide, >> not per-process. We should also make it clear that GDB might[1] cache >> target descriptions per remote connection, and so a remote target should >> not reuse a target description ID except where the target description is >> identical. Ah, good point. I will make that clarification. >> [1] I say "GDB might" here because if we say "GDB will" then this would >> imply each target description will only be asked for once. And I >> figure, why be overly restrictive. > > Thanks for pointing this out, I had the same thought while reading the > patch. > > In my original idea, I imagined that target description IDs could be > some hashes computed from the XML content (a bit like git hashes or ELF > build IDs), such that a given target description would always have the > same ID. This would give clients the possibility to cache target > descriptions locally, a bit like the index cache. It did sound nice, > but perhaps it's not really important. Ah, sorry I misunderstood this part of your suggestion. I thought that the caching was supposed to be limited to the duration of the connection, and thus the m_tdescs map in struct remote state would be enough to provide that functionality. Do you mean that the cache should be on disk, so that it survives GDB quitting? I can look into that if you want and implement it, if not complicated. In this case, I think the tdesc ID should be of the format :, so that can be =E2=80=9Csha1=E2=80=9D,= =E2=80=9Csha256=E2=80=9D etc to indicate that is a hash with the given algo, or even =E2=80=9Cnumber=E2=80=9D to indicate that it's a simple integer like it is = today. Perhaps we can do the prefix thing even if not implementing the cache, to leave the possibility of adding it in the future? --=20 Thiago