From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by sourceware.org (Postfix) with ESMTPS id 7A9D63858C83 for ; Mon, 6 Feb 2023 21:06:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7A9D63858C83 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f44.google.com with SMTP id y1so11719511wru.2 for ; Mon, 06 Feb 2023 13:06:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cPezxJaImYgyGgSvu8uF7gjynTPnxmCsRHyHiXCAiKY=; b=VzGUrD1r6dKFEfQcoO2PwLJirejKlEMBvV8G9keoRaW0iSsl0aeUc9Fz4d0eObBCKt sewcP7lEJaS0viK2zsAXYvxx3WLcMdaCLZ4yEZSXf/xJhOD5CN6aF1LQ6vm6CNs8YXPg PO5oHKCLlFljRQrUZfB+CIcgrqkruyL8wfghH7aA0mDcJ5F/6C/1Biok0nW7bozc6D8k iJ5u8boodSUAZCJ70f5H9Sos9aDj+GqxiBpfnuvvRFO4WSkswGB0x+YzeXzPk4JQE/Uq d6XJVQHSmWKQY9PIuuvFp9xZiWeikqSINtmTaKYfDwgR8ZRE12EV3FpkeAcE1tAilCWk egFQ== X-Gm-Message-State: AO0yUKWSiK9tVaWcboleRWaCBQIvz54UAeWuJUWmc4QCSgsw0DTM9dNi 98ODwjpi3CKvt7jM6ywYWuUsUXRkjWK93w== X-Google-Smtp-Source: AK7set+7R9TVQpCQ6XgrEVFfr0DWArzFQ/ULwhLCheF8iEmg9bs6HbjAJ0PBhH2Dkvc7U8ppbMX9bw== X-Received: by 2002:a5d:688d:0:b0:2bf:f024:de79 with SMTP id h13-20020a5d688d000000b002bff024de79mr380018wru.37.1675717586030; Mon, 06 Feb 2023 13:06:26 -0800 (PST) Received: from ?IPv6:2001:8a0:f92b:9e00::1fe? ([2001:8a0:f92b:9e00::1fe]) by smtp.gmail.com with ESMTPSA id t1-20020a5d4601000000b002bdfe3aca17sm9637591wrq.51.2023.02.06.13.06.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Feb 2023 13:06:25 -0800 (PST) Subject: Re: [PATCH v3 0/8] gdbserver improvements for AArch64 SVE support To: Simon Marchi , Thiago Jung Bauermann , gdb-patches@sourceware.org References: <20230130044518.3322695-1-thiago.bauermann@linaro.org> <28bdd610-982d-aebb-ebc7-17b6d5fd80ed@palves.net> From: Pedro Alves Message-ID: Date: Mon, 6 Feb 2023 21:06:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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: On 2023-02-06 8:05 p.m., Simon Marchi via Gdb-patches wrote: > >> Ah! I had also suggested to you something like that at the Cauldron (when we were in line >> for lunch. :-D However, IIRC, I had suggested that we should be able to cache the tdesc by filename. >> >> Let me explain -- when we fetch a target description, we actually tell the server >> to retrieve a tdesc _by a given filename_. By default, we ask for target.xml, like this: >> >> qXfer:features:read:target.xml >> >> but then, the retrieved target.xml file may "xi:include" some other file, like for example these do: >> >> gdb/features/s390-linux64.xml:14: >> gdb/features/s390-linux64.xml:15: >> gdb/features/s390-linux64.xml:16: >> >> (try grepping for xi:include in the gdb/features/ dir for a lot more hits.) >> >> and so when processing each of those xi:include's, gdb sends another qXfer:features:read packet, >> with the corresponding included filename, like e.g., >> >> qXfer:features:read:s390-core64.xml >> >> Here's what the manual says: >> >> @item qXfer:features:read:@var{annex}:@var{offset},@var{length} >> @anchor{qXfer target description read} >> Access the @dfn{target description}. @xref{Target Descriptions}. The >> annex specifies which XML document to access. The main description is >> always loaded from the @samp{target.xml} annex. >> >> So basically I am suggesting that instead a new ID mechanism, we should be able to >> use the preexisting annex/filename concept as key. That means that the stop reply and >> the thread listing would include a new "tdesc=foo.xml" attribute, instead of this >> ID that then is defined to map to "target-id-%u.xml", which is basically admitting >> that tdesc filenames exist anyhow. > > Just for completeness, how do you envision that working for SVE? > GDBserver would make up unique names for each configuration, like > "target-vq-%d.xml"? The string is free form, up to the server to decide what to use for names. Could be that, or "aarch64-linux-sve-vq-%d.xml" or whatever. Of course, for ports that wouldn't generate the tdescs on the fly, you'd want to use the same name as the real existing xml files that are embedded into gdbserver. > > If caching using filenames as keys, what is the scope of that namespace? > Per remote connection, per inferior? I think it wouldn't work per > remote connection, because fetching "target.xml" for two different > inferiors could give two different answers. Right, I think we'd make it per-inferior, at least by default, for backwards compatibility. But we can also think about the server telling gdb about the scope if we want, with qSupported or some such. And then if the stub tells gdb that the scope is connection, the stub would also tell gdb about the architecture of the main thread (in stop reply and thread listings), say, "the-right-secondary-arch.xml" so gdb would retrieve "qXfer:features:read:the-right-secondary-arch.xml", for that inferior, and not "qXfer:features:read:target.xml". Basically, gdb only fetches "target.xml" when it doesn't know better. > > Tangentially, I'm wondering if querying qXfer:features:read (mostly > fetching "target.xml" is going to become thread-sensitive. In other > words, if GDB set the general thread to a thread with vq == A, gets > target.xml, then sets the general thread to a thread with vq == B, then > gets target.xml, is it going to get two different target descriptions? > I think that it would make sense to do so *. I am not so sure about that making sense. As target.xml is documented as the main tdesc, it would continue that way, with "main" meaning the tdesc that the initial thread has when the process is first started. > Therefore, caching > target.xml per-inferior wouldn't be reliable either. And if included > files could vary per thread, you'd have to make sure to give them unique > names. With the numerical ID idea, you have to know which ID to read for the thread, before you read it. You don't just go and read the desc with ID 0 thinking that 0 is a different ID depending on thread, right? So it's no different -- the stop reply would say "tdesc=whatever-secondary-arch.xml", and GDB would fetch that xml file if not cached yet, and use the cached version otherwise. > > * I think that since we're going towards thread-specific tdescs, the > process-wide tdesc is going to become an obsolete concept, maybe just > kept for backwards compatibility for when an old GDB not aware of > per-thread tdescs talks to a new GDBserver aware of it, or vice versa. > > Simon >