From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id 2D8E63858D20 for ; Sat, 11 Nov 2023 20:11:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2D8E63858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2D8E63858D20 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=96.47.72.81 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1699733493; cv=pass; b=p3JeOaHnXDZ9wsbMZN/Z2e6jPp9Il5ExljW2D3tk0DNygo5+NPcL0eYMK/u03Vo+qS+0ydlpbcT7SGokefvA3bMD/YS+R0AkK/c3D002w2sII26gXS/jlr7KuR7UM3/o3WmfKigHZCvPdSy7wu4+h+oCcoktpdWxTdm1KPZXjqU= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1699733493; c=relaxed/simple; bh=y1EBc6wc1mDHpP6DoHxH0NTbevnHY+Ihk7Nk9N29sjo=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=P+HmVxJirS7RR2/XQb9tc9EfJddvhF6A+ADDGV/UAiYsIhkY4ew8YIPlDpzx7A7hDrlAyiL18BCLgCSNumtg7ZcxmAguPjVT5Duk7eKblzVm3LOWA9ju3u/pK01Kshp/r+vwA1FFmj6ysHFZaxPU/d7YdWWIKQCTQ2ix+GcmWxw= ARC-Authentication-Results: i=2; server2.sourceware.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 4SSRfW6cHsz3Blv; Sat, 11 Nov 2023 20:11:31 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SSRfW5sChz3P3T; Sat, 11 Nov 2023 20:11:31 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1699733491; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5H0Z3xUGnPcKTeDD2dLaSifsj+4oO3fHYpi35ypRbBI=; b=q6hhiHqk17bfPHcH/myVxFHSevfrOwglZ3dwx2KqsNbHeBKTKJvMVLVd5U2DvAI3Pqu7YZ pIlqDi0s4+sf959shS+NiNF95ej41JfHXam4CPFZN2fejmfY8yqlgRK6VIdy5dtXDD/ZMM 3n0phWBK5dEaC1O83BoEKrv3F9kWNnGYG+C4iOqbEc7rfYaqQsbBHDlgT6LlonzcM6DgUq 9pHppg4IXH/el+6EGaGk2AkePCbvbbyP4G5PcnpQazMhlpaPsHXuKgaCD0R3ACud1VGIjf lyqiuMIft/qIleTpTV7+onrB4BE2bNQJwdvDphIDxzxpgMdHHZobW5W45GhSMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1699733491; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5H0Z3xUGnPcKTeDD2dLaSifsj+4oO3fHYpi35ypRbBI=; b=Xnt/o5RUGKpTPZjLpP37UwUEfKrgO6dMYsD0I/Gf7ndC45EFkSDflw1g2rQHVPo/c86hin +USZj1yD1Pbd1BOdxj6oYTU24A5aalfL2tUE22pn2JGBg2S6HslndTIreH2hY6yxX2xQsJ zVa9W4FRBphljUSI/jMG7/hVDkEEOT10bsDE4QcQFA9fq/KdkquC9eBzHq1382ilqlttum 5FGZouREeCGBf/ssSXfW8+pYsd239JuV1+rQT6mv1E6DoH079yz1dXuY5tsn/x7eER4KmM 8R3peUmXqytnDsRT0HdrQf8nucxUKCDHpLaYMOQXhfcXPv8I0QUTWtS03nl6sA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1699733491; a=rsa-sha256; cv=none; b=pesQKK0lFA8fhxuA8saxijYZbuzVSJl3eOmx1kTjviEagJAIf6oe0z0/1E0LioSgRgnF2F drJdD3YsfotHUh6AfW+ZJayAl02kZErg7HP2u+3+oC91wbYLbvulgiUwIECIJKlC5ecWBo mG3L7di7tuvuZnr59iWpbcYDDO0q0c1ZoZqUK8Ovh8uLB61aViDuzeu1ufqlnmyQ1T7RY1 gicEY4JDyKaz7iK7LkDooO4yAV0JOpawh8HY17JF8zVSJx7ZKH9Fgu9APWbNLP2cfKHh6b xQjBANsGKFZ3Llxt/9yQDXKnfUmmSiOEQtpVZ6zZIGpWYSMyWquzZg2PqDn+UA== Received: from [IPV6:2601:648:8384:fd00:8dc8:68:d931:e24b] (unknown [IPv6:2601:648:8384:fd00:8dc8:68:d931:e24b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4SSRfW2Lqrzk5F; Sat, 11 Nov 2023 20:11:31 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <970ec0bf-e2ab-4dfe-8a0a-9eadb97784c4@FreeBSD.org> Date: Sat, 11 Nov 2023 12:11:29 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 14/24] gdb: read pseudo register through frame Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org Cc: Simon Marchi References: <20231108051222.1275306-1-simon.marchi@polymtl.ca> <20231108051222.1275306-15-simon.marchi@polymtl.ca> From: John Baldwin In-Reply-To: <20231108051222.1275306-15-simon.marchi@polymtl.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 11/7/23 9:00 PM, Simon Marchi wrote: > From: Simon Marchi > > Change gdbarch_pseudo_register_read_value to take a frame instead of a > regcache. The frame (and formerly the regcache) is used to read raw > registers needed to make up the pseudo register value. The problem with > using the regcache is that it always provides raw register values for > the current frame (frame 0). > > Let's say the user wants to read the ebx register on amd64. ebx is a pseudo > register, obtained by reading the bottom half (bottom 4 bytes) of the > rbx register, which is a raw register. If the currently selected frame > is frame 0, it works fine: > > (gdb) frame 0 > #0 break_here_asm () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:36 > 36 in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S > (gdb) p/x $ebx > $1 = 0x24252627 > (gdb) p/x $rbx > $2 = 0x2021222324252627 > > But if the user is looking at another frame, and the raw register behind > the pseudo register has been saved at some point in the call stack, then > we get a wrong answer: > > (gdb) frame 1 > #1 0x000055555555517d in caller () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:56 > 56 in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S > (gdb) p/x $ebx > $3 = 0x24252627 > (gdb) p/x $rbx > $4 = 0x1011121314151617 > > Here, the value of ebx was computed using the value of rbx in frame 0 > (through the regcache), it should have been computed using the value of > rbx in frame 1. > > In other to make this work properly, make the following changes: > > - Make dwarf2_frame_prev_register return nullptr if it doesn't know how > to unwind a register and that register is a pseudo register. > Previously, it returned `frame_unwind_got_register`, meaning, in our > example, "the value of ebx in frame 1 is the same as the value of ebx > in frame 0", which is obviously false. Return nullptr as a way to > say "I don't know". > > - In frame_unwind_register_value, when prev_register (for instance > dwarf2_frame_prev_register) returns nullptr, and we are trying to > read a pseudo register, try to get the register value through > gdbarch_pseudo_register_read_value or gdbarch_pseudo_register_read. > If using gdbarch_pseudo_register_read, the behavior is known to be > broken. Implementations should be migrated to use > gdbarch_pseudo_register_read_value to fix that. > > - Change gdbarch_pseudo_register_read_value to take a frame_info > instead of a regcache, update implementations (aarch64, amd64, i386). > In i386-tdep.c, I made a copy of i386_mmx_regnum_to_fp_regnum that > uses a frame instead of a regcache. The version using the regcache > is still used by i386_pseudo_register_write. It will get removed in > a subsequent patch. > > - Add some helpers in value.{c,h} to implement the common cases of > pseudo registers: taking part of a raw register and concatenating > multiple raw registers. These are quite a nice change and reduce a lot of the copy/paste that would otherwise be present. > - Update readable_regcache::{cooked_read,cooked_read_value} to pass the > current frame to gdbarch_pseudo_register_read_value. Passing the > current frame will give the same behavior as before: for frame 0, raw > registers will be read from the current thread's regcache. > > Notes: > > - I do not plan on changing gdbarch_pseudo_register_read to receive a > frame instead of a regcache. That method is considered deprecated. > Instead, we should be working on migrating implementations to use > gdbarch_pseudo_register_read_value instead. > > - In frame_unwind_register_value, we still ask the unwinder to try to > unwind pseudo register values. It's apparently possible for the > debug info to provide information about [1] pseudo registers, so we > want to try that first, before falling back to computing them > ourselves. Only updating read_value to use a frame seems sensible to me as a plan. I had to stare at the update to handle reading the BND pseudo registers for i386 for a while, but it does look correct to me. Reviewed-by: John Baldwin -- John Baldwin