From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675442305; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6YAr1O+uonDxZkOLEbJwaTIW7teDNLcsK+O/iwjrFXs=; b=FIQin1D1Koob2+svOg8oqt4rrKXFKcf7OKd3ufkJPjqwcVsLbe9AGdgV91YlE1YqC8hTp4 qBmnL4XOeyk2c3dVR31kx95R2i9FFAD8KNqzuy6Avr8TjXeUSOVESfS2HZqrX3GY77IiIP ZVye+Rhio+51NTUDonrhAg/oawH/aPY= 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) From: Andrew Burgess 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-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: >> 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