From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id dFSQKQ5FvmC9OwAAWB0awg (envelope-from ) for ; Mon, 07 Jun 2021 12:10:54 -0400 Received: by simark.ca (Postfix, from userid 112) id 9A1E51F163; Mon, 7 Jun 2021 12:10:54 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 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 D65B31E939 for ; Mon, 7 Jun 2021 12:10:53 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 712773894407 for ; Mon, 7 Jun 2021 16:10:53 +0000 (GMT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id 1F4743886C7A for ; Mon, 7 Jun 2021 16:10:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1F4743886C7A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-wr1-x42d.google.com with SMTP id q5so18288987wrm.1 for ; Mon, 07 Jun 2021 09:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=3HeY9NnHsOxbXwkeX9vu1qzIKniZjCRUkrDqt4PWm1o=; b=dPv3YM1/WdH1f56JcDyw8YsTzAB+EsMXR2XB2Acu1slzN4WXfEbI7AD9fiPMbYLFna h9GF+VU1P3ndYOnjpUvAqiVLBiVsf490S+S8RQDdpQSQa8E2OGlJGytNN/fE3wAqcvNA uDMhkU4jz0nh8CH/9TMuQArJBQTL90WyRfpmr6AeBL3e5wqQNJkuK0gDjNiFeZFwroCL JGwJ+rBuUdYFmZUH+VG5zvnBGHXNqNi1d155AhLwH6BTlBW8g8knPotuQ3Ne0b7tGQIw j8r9YpS6U5YuzO7wxXesn/LkWk2RFjZMv1aefncPMHTWyHbf1Zt//dfUNmfVdnspgu4t u3IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3HeY9NnHsOxbXwkeX9vu1qzIKniZjCRUkrDqt4PWm1o=; b=sd+jrNWBRz3oExBFgg4AAnx2WrMFytpBxwwTg/HW3gznoztiA2peMT1+cOnvftNGz9 HD4ewNm20hpCZnk7qzO5cVwzeYB2FjcPVzYEZ78h1+FLNQ1wchEwc22q8RjQolYlW/5y HzzRkyFh2e1ho532wvhlJA2n89hUHicdMrAwVrFvJ5J519aB2eKernqHKBqzt2MkipjY EZ2Ozy32p3guVQcV2+FGoaoQ7l15N2OcKssTy8jjOdrz0JxJ8xKMmIBbgcoMA4q1rEp7 4KHiXlXJPJFyXjCanE4qzrClWlh+9w0CBNEnfO531MgnCLKJTXFBiTRDTp2W/UaYJutH qCAQ== X-Gm-Message-State: AOAM533Pzu0dqpWjLfBgoXsjpx8m3UsSxOTLKBGvKMWpqq4rcsE14ZoM 6IS6yhTDxFZvQAHn5DmKxDyZ6Q== X-Google-Smtp-Source: ABdhPJzRKP/1ytYeFRXUHOgirv1tDKiYbqG/RpFodO9acwJ0RaM3CfILzomw/uQ2OZSk8cSKb4iM9w== X-Received: by 2002:adf:ec43:: with SMTP id w3mr17332688wrn.270.1623082232141; Mon, 07 Jun 2021 09:10:32 -0700 (PDT) Received: from localhost (host109-151-46-70.range109-151.btcentralplus.com. [109.151.46.70]) by smtp.gmail.com with ESMTPSA id h46sm19039263wrh.44.2021.06.07.09.10.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Jun 2021 09:10:31 -0700 (PDT) Date: Mon, 7 Jun 2021 17:10:30 +0100 From: Andrew Burgess To: Tom Tromey Subject: Re: [PATCH 1/5] gdb/python: handle saving user registers in a frame unwinder Message-ID: <20210607161030.GU2672@embecosm.com> References: <877dj5n2y7.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877dj5n2y7.fsf@tromey.com> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 17:02:44 up 19 days, 5:46, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] 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: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" * Tom Tromey [2021-06-07 08:50:56 -0600]: > >>>>> "Andrew" == Andrew Burgess writes: > > Andrew> So, in this patch I propose that in the unwinder code, when > Andrew> add_saved_register is called, if it is passed a > Andrew> user-register (i.e. non-cooked) then we first fetch the register, > Andrew> extract the real register number from the value's location, and use > Andrew> that new register number when handling the add_saved_register call. > > Andrew> If either the value location that we get for the user-register is not > Andrew> a cooked register then we can throw a 'Bad register' error back to the > Andrew> Python code, but in most cases this will not happen. > > I was worried that requesting this would require unwinding the register, > which is what is currently being done. But I suppose the idea is that > the value is normally lazy, so it isn't actually unwound? You are correct, accessing any register from an unwinder is going to give us a lazy register value, which we'd expect (in this case) to have the real register number for $pc, and the frame-id of the next frame. When you open with "I was worried that requesting this would require unwinding the register...", was our concern just that this unwinding might be expensive? Or are you worried that trying to do that might break in some way? Remember, the user can already do: PendingFrame.read_register('pc') which is going to fully fetch the register value (so create the same lazy register value as above, and then make it unlazy), so I don't think there should be any technical problems here, even if it turns out that the register value is not lazy. I guess what I'm saying is, that yes it will be lazy, but I hadn't really considered that an important part of the system. Thanks, Andrew