From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x31.google.com (mail-oa1-x31.google.com [IPv6:2001:4860:4864:20::31]) by sourceware.org (Postfix) with ESMTPS id 5EA4A385840D for ; Thu, 2 Feb 2023 20:36:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5EA4A385840D 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-oa1-x31.google.com with SMTP id 586e51a60fabf-15f97c478a8so4063390fac.13 for ; Thu, 02 Feb 2023 12:36:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; 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=AN44lC3voRhU2iCtdvxLimRCIhBN3ArARnnGb16Chnw=; b=wYyQbtANwl5Y/71hkwG0dhqrwIA6KBtRFRPa0izcrEomFAF1qHyy7CuS4GQMl2HQ/4 I7GxJKuZp6v7bPPWjoab7S4K1LAneBOYp00QizatE7Fr8lKBQ69yvkjtbWSAzRGZHRbG 01syd9jgkLbqJvJduaSXOWOrY3ZSrsKyVa4Ma1k8/5yjvzCJXm4uH6jRzI8gGZNFzcYn wSJybNNNKTIbNnhAvOYS04mfubdoGZVXEehT6TY1n+Gj1aSuc3dfv6x1TQJk8WkkbWDp Op76wbt8+Jbr32KR+ifrLDAEjbvv+e+yNrt08jZRJNs4dOiWIdnh9fZdYYa8Xcx5kw73 tm1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=AN44lC3voRhU2iCtdvxLimRCIhBN3ArARnnGb16Chnw=; b=tIyYx287RD3E+v99WcV2Lrf+aydn/VqlVr+f5Tl/jQnyXp3wTtIEUzYSsrIRVrsYt+ JOpOp1PahY76tXWIPnaDPZu/Ms1HE+dnXWnEWuUsKpWcmeCb420cZK+Uh+iJhvrPJW34 bEVugOdGqxK22JkkDQCEfvVSOwjGf+mHKMH3tpXXoMa01MkzIVmIARXlzc91jfYKpj7Z 31y5RO9cYSKWiHhem1obym/yQBb2TAP3BX0TK0XhBlpIZLNVMI+WJPO1ZbpAaxGR2jak V6PPsNW9dIIxd3D7A/r3zQ99zyzsUdopczZVD/amC5fSy68LS06d58yUiYiUYmZcv7Vy 1hng== X-Gm-Message-State: AO0yUKUJ2L5f+JOKChUwRsvR0tR4q77Rr2IFbYnh9ZQB/k2c2gCyJUp9 RMdHoZYIkSha/T4nsnXeqMkIOItApz8Ro5fe X-Google-Smtp-Source: AK7set9U89jEaOnaAIMFctjkSXwAlRCox01NucMFXnqoTiAjeL/7j6dU9xN2VKsZg2zpnCOtxq+7rQ== X-Received: by 2002:a05:6870:73ce:b0:168:5cec:4182 with SMTP id a14-20020a05687073ce00b001685cec4182mr1703433oan.33.1675370191691; Thu, 02 Feb 2023 12:36:31 -0800 (PST) Received: from localhost ([2804:14d:7e39:8470:7132:fbe:2b2e:ae3e]) by smtp.gmail.com with ESMTPSA id n21-20020a056870a45500b001676a4dc22bsm148146oal.58.2023.02.02.12.36.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Feb 2023 12:36:31 -0800 (PST) References: <20230130044518.3322695-1-thiago.bauermann@linaro.org> <20230130044518.3322695-6-thiago.bauermann@linaro.org> <87lelhtwqv.fsf@redhat.com> 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: Date: Thu, 02 Feb 2023 20:36:28 +0000 Message-ID: <87mt5vajoz.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain 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: > On 2/1/23 07:07, Andrew Burgess via Gdb-patches wrote: >> Thiago Jung Bauermann via Gdb-patches >> writes: >> >>> Now that an inferior thread can have a different target description than >>> its process, there needs to be a way to communicate this target >>> description to GDB. So add the concept of a target description ID to the >>> remote protocol, which is used to reference them and allows them to be >>> transferred only once over the wire. >>> >>> The ID is an unsigned integer, and is sent in the 'T AA n1:r1;n2:r2;...' >>> stop reply packet as a new 'n:r' pair, where n is "tdesc" and "r" is an >>> unsigned integer containing the ID. >>> >>> It is also sent in the threads list XML in the response of a >>> qXfer:threads:read request. The ID is sent as a new "tdesc" attribute of >>> the node. >>> >>> To request the target description XML of a given ID, GDB sends the >>> qXfer:features:read request with "target-id-%u.xml" as the annex, where %u >>> is the target description ID. >> >> Luis already commented that in some locations the ID is hex, while in >> others it is not explicitly stated if the value is hex or decimal. I'd >> like to second that feedback, and suggest that we pick one, and use that >> consistently throughout. >> >> My thinking is that it will be easier to understand remote packet traces >> if target descriptions are requested using an ID in the safe format as >> was sent to GDB, and if IDs in different packets match up. >> >> Thus, I would suggest we switch to using 'target-id-%x.xml' here, and >> send the ID as hex in the threads reply packet. > > Not that I disagree with you, but I just wanted to note that this > decimal / hexadecimal mismatch already exists for the core field. It's > hex in stop replies, decimal in XML. The thread id, however, is always > hex (the special thread-id syntax). > > Regardless how this new field is formatted, it would be nice to be > explicit about the core field too. I agree it makes more sense to use hex everywhere. In the case of XML attribute fields, enforcing hex would mean adding a base parameter to xml_parse_unsigned_integer (which currently accepts decimal, octal and hex). I'll do that. In the case of the core field, to avoid breaking existing stubs it's probably better to document that it can accept any of the three bases. -- Thiago