From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0C/zB5g43WO8CikAWB0awg (envelope-from ) for ; Fri, 03 Feb 2023 11:38:48 -0500 Received: by simark.ca (Postfix, from userid 112) id 1CF131E128; Fri, 3 Feb 2023 11:38:48 -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=NRC3uKb8; 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=-7.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, 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 B79C71E112 for ; Fri, 3 Feb 2023 11:38:47 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EF3343858416 for ; Fri, 3 Feb 2023 16:38:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EF3343858416 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1675442326; bh=6YAr1O+uonDxZkOLEbJwaTIW7teDNLcsK+O/iwjrFXs=; h=To:Cc:Subject:In-Reply-To:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=NRC3uKb8oUNea1blpw4b8iT49RIz0/lJyhFb8eu5EPBNOv0+iMVGogTE7EYOWPZxW tllndFiXwDeTiauAmCd8IkYqH/pqD2y24NygD/rWT37hdDXZEb8BT4VT6fNJ8gLTcJ Vs3ymeBZDvDMb3MZZrYUPmtZupeEgJoXFtyoBvjo= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id AB38B3858C52 for ; Fri, 3 Feb 2023 16:38:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AB38B3858C52 Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-616-97LOY62fPhS7SlOeQNJUiw-1; Fri, 03 Feb 2023 11:38:23 -0500 X-MC-Unique: 97LOY62fPhS7SlOeQNJUiw-1 Received: by mail-qv1-f71.google.com with SMTP id e5-20020a056214110500b0053547681552so2993062qvs.8 for ; Fri, 03 Feb 2023 08:38:23 -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:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6YAr1O+uonDxZkOLEbJwaTIW7teDNLcsK+O/iwjrFXs=; b=0W76im5aI68hl9HpIddv7Ft5aoBLLQDw5kjhP3NQa9kv3157DxV1Bj0U3h9n4fjh4+ HsFLmPf2HxWOUU1E6f27WCDlzwFafzq8qoH8bK8iARbf6ccPGbxbMict8TegJ/kN6FT5 Ng/gZsw8ZG1gaaPEur2I0U9yCo0Sv/4CPLY9gjJhEAFLLnO/CKjniJvhcoOnOXhjgVbD 6JnYDbXlIzTYaZel9EdVTyzvwW51Us0+6kkJI/SxYOzvv6ZHq/oI7FT8IW3iWETF7zxE kz8zKjc6Vd49LP55S6Th6RJRJ3z2KToKBScOMwWguWBy7eR2SYlMvOiR5+Ui4Pf8IYoC 2AbA== X-Gm-Message-State: AO0yUKX3qNPuszvwZRUOauST79v7FZA8vwQvahsSeTQfNY0phRndCk0i I5jPpkC+eERHoriMxPDTArjSDvk7RsXrDjw3k7gz2aw+dnJm1lXNkX7E0EyAJjIQureGaesDA+X RZJdLkpcNUXPxntlSWDAnyQ== X-Received: by 2002:a05:622a:312:b0:3b7:ec1b:1fa7 with SMTP id q18-20020a05622a031200b003b7ec1b1fa7mr19508128qtw.43.1675442303301; Fri, 03 Feb 2023 08:38:23 -0800 (PST) X-Google-Smtp-Source: AK7set+9B2j4D46Qapu1nKfcu21fGx1bCsgn1mFw0hmJ63I3HE/eCVqzOKvfpZPVNB8naRxsnRVCjQ== X-Received: by 2002:a05:622a:312:b0:3b7:ec1b:1fa7 with SMTP id q18-20020a05622a031200b003b7ec1b1fa7mr19508109qtw.43.1675442303058; Fri, 03 Feb 2023 08:38:23 -0800 (PST) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id f3-20020ac84703000000b003b2d890752dsm1798539qtp.88.2023.02.03.08.38.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Feb 2023 08:38:22 -0800 (PST) To: Simon Marchi , Thiago Jung Bauermann via Gdb-patches Cc: Thiago Jung Bauermann Subject: Re: [PATCH v3 7/8] gdb/aarch64: Detect vector length changes when debugging remotely In-Reply-To: <70edf893-10e4-f55d-dd2d-c57747e01def@simark.ca> References: <20230130044518.3322695-1-thiago.bauermann@linaro.org> <20230130044518.3322695-8-thiago.bauermann@linaro.org> <878rhhtnis.fsf@redhat.com> <70edf893-10e4-f55d-dd2d-c57747e01def@simark.ca> Date: Fri, 03 Feb 2023 16:38:21 +0000 Message-ID: <87pmaqr9fm.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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: Andrew Burgess via Gdb-patches Reply-To: Andrew Burgess Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Simon Marchi writes: >> I guess the point I'm driving towards is that maybe instead of a new >> gdbarch method we should add something like gdbarch_from_tdesc into >> arch-utils.c (like we have gdbarch_from_bfd and gdbarch_find_by_info), >> which just does a lookup from tdesc. > > One thing I would like to add: I presume that this process > (gdbarch_find_by_info) is somewhat expensive. Is there an easy way to > short-circuit things earlier? Maybe if we detect that a thread has the > same target desc id as before, we can avoid recomputing the gdbarch? > Or, we can cache the gdbarch in the remote_target. Or could we cache the gdbarch in the tdesc itself? As you pointed out for the previous patch, passing the same XML string will result in the same tdesc object. So if we had gdbarch_from_tdesc, this can do the expensive gdbarch lookup, then store the gdbarch in the tdesc object. Next time we call gdbarch_from_tdesc we can just check for a cached gdbarch within the tdesc and return that... ...maybe? Thanks, Andrew > The > remote_target::m_tdescs would hold both the target desc and > corresponding gdbarch as values, instead of just the target desc. > Actually, maybe the remote target wouldn't need to hold the target_desc > at all, once it has the gdbarch. Other than maybe for lifetime reasons, > which are discussed with the previous patch. > > Simon