From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) by sourceware.org (Postfix) with ESMTPS id 490B83858C52 for ; Sat, 4 Feb 2023 15:26:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 490B83858C52 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-oo1-xc2b.google.com with SMTP id z25-20020a4ad1b9000000b00517affa07c0so764832oor.7 for ; Sat, 04 Feb 2023 07:26:55 -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=ZvmonPSSy6hV3O739VZmvLfXmPCjpXHDc1yoOIQsXhc=; b=jzuN5C7OGkgmPRbaSJtQGakYUn/pt5sGD0tvSecIBoNSQjJXWbgo3HXSpPZinqr186 uEpcJaT5BC7lPRt89zWMWQrgkPJszLpzMVbV1B9NFZT2TOa2xiRjLvlTjMCwTUC+3C8I otwKLD21VepZERzCfhNQ/2yIBpLtsc7t//tRaNOcc0CtrTH+K3sp45CQhkXP59IChyU0 7lDV6zwnmB3ncxaEHqYibCJ8QIRAfuHip1RWCq5qS06bAjxXhppj/BBoeLr68tAehJ6/ xutk7eRjcV2l+cYJ7/pCNTnXwXOTjsfhapQ+wDTWwOflxP0PYix/7n4Nvfk4kV8YRkrE Phjg== 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=ZvmonPSSy6hV3O739VZmvLfXmPCjpXHDc1yoOIQsXhc=; b=iIU66AmhEuS85TJHQiQkOQ+JHtlEE5qVNnZAIaonQ5BMh0IAeanYsQdwbdOEkJxDRJ IvuHUKIfi3XXIpUUhb+jcURSjnAK2r7ER4IjV+z0RpYhDlYVX5vrFISsWC9ezJQMehBi BkeHlAMRhw4x2KZtQuLqk2d32Ociqq7S1FcF3f4zQjiUJ2PqMEdcgIGpghI/Zf+r3t/Z pO+H+5k8b4lzrGdBRTbWzkuH4gRFlDe1hroswwxb3+rsP900dYeBK50sS932MY2Oh0ax DlkCbeHPStW33VQ0SgNSsbm3W6Tcw1NS2E3fIs7mw0xpyjSbop0YOgzs2oAYTh+qmK5r PNcA== X-Gm-Message-State: AO0yUKVRhIBx5qApUo+rBHHpfy5Xbsqmneb2ujzZ9mX6PnC92xo+B+RK M/6MTFN2PFa7f5GweRxw1rX7hw== X-Google-Smtp-Source: AK7set/VhgP88/0WcpZoKPN3X/H39yg9oXnNkhroewsm1AyjID4C+xlMlECF6NMyWAraAYZb7PPUdw== X-Received: by 2002:a4a:49ca:0:b0:51a:7265:5055 with SMTP id z193-20020a4a49ca000000b0051a72655055mr787207ooa.0.1675524414523; Sat, 04 Feb 2023 07:26:54 -0800 (PST) Received: from localhost ([189.100.172.221]) by smtp.gmail.com with ESMTPSA id v8-20020a4aa408000000b005178a98b6d2sm2121529ool.30.2023.02.04.07.26.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Feb 2023 07:26:54 -0800 (PST) References: <20230130044518.3322695-1-thiago.bauermann@linaro.org> <20230130044518.3322695-5-thiago.bauermann@linaro.org> <87pmattzjw.fsf@redhat.com> <7970ac03-1123-d5f6-7b17-808832d43be6@simark.ca> <9a85e2fe-078a-e2ee-7e49-53fe0ceef492@arm.com> <87y1pgaib6.fsf@linaro.org> <871qn79zqk.fsf@linaro.org> User-agent: mu4e 1.8.13; emacs 28.2 From: Thiago Jung Bauermann To: Luis Machado Cc: Simon Marchi , Andrew Burgess , Thiago Jung Bauermann via Gdb-patches Subject: Re: [PATCH v3 4/8] gdbserver/linux-aarch64: When thread stops, update its target description In-reply-to: Date: Sat, 04 Feb 2023 15:26:50 +0000 Message-ID: <87h6w1moxx.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Luis Machado writes: > On 2/3/23 03:47, Thiago Jung Bauermann wrote: >> Simon Marchi writes: >>> On 2/1/23 21:54, Thiago Jung Bauermann wrote: >>>> Luis Machado writes: >>>>> Moving towards thread-specific target descriptions/gdbarch would >>>>> be a positive thing given the SVE precedent. The process-wide >>>>> target description/gdbarch no longer reflects the correct settings >>>>> for each thread on AArch64's with SVE support. >>>> >>>> In the first version of these patches I removed the process-wide target >>>> description and moved it to thread_info, but it was a big patch that >>>> touched many targets. I can bring it back if you think it's worth it. >>> >>> At least for the register description, if we decide it's now a >>> per-thread thing, what does it mean to have a process-wide description >>> anyway? I think it would make sense to get rid of it, that could help >>> confirm our model works (and it would remove the chance of using the >>> wrong tdesc by mistake for a thread that has its own tdesc). It's >>> probably something that can be done incrementally though. >> >> Would it be done incrementally by keeping process_info->tdesc but >> changing each target in turn to use thread_info->tdesc and ignore the >> process_info one? > > Given only AArch64 has this requirement at the moment, it may be > easier to leave the process-wide tdesc up until the point we can > safely/easily switch to thread-specific ones. > > After that, AArch64 will have potentially distinct thread tdescs while > other architectures will have threads sharing the same tdesc. Ok, sounds good. Thanks for the clarification! -- Thiago