From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id qOOzJOYe3GMDWigAWB0awg (envelope-from ) for ; Thu, 02 Feb 2023 15:36:54 -0500 Received: by simark.ca (Postfix, from userid 112) id 92E551E128; Thu, 2 Feb 2023 15:36:54 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=UALcaDWF; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 0887A1E110 for ; Thu, 2 Feb 2023 15:36:54 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6FBBE385842D for ; Thu, 2 Feb 2023 20:36:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6FBBE385842D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1675370213; bh=AN44lC3voRhU2iCtdvxLimRCIhBN3ArARnnGb16Chnw=; h=References:To:Cc:Subject:In-reply-to:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=UALcaDWFdkWz2fSEH0te0fK/t91V1BGLjWWk2YjDNMQn5KmeVSd1JttFaJQ9/JNYz U3vvrWFJj+01rclpMmePXWkdRZ2d/uyMORxQHgvT1JZMkOzNxwsIFu3KOPUvJkPiOV P0hnnFJGba7YCz6QeW5PlDLzeWXG4NqHOtdmz14U= 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 Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-15f97c478a8so4063390fac.13 for ; Thu, 02 Feb 2023 12:36:32 -0800 (PST) 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 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-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Thiago Jung Bauermann via Gdb-patches Reply-To: Thiago Jung Bauermann Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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