From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74393 invoked by alias); 28 May 2018 19:13:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 74304 invoked by uid 89); 28 May 2018 19:13:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 28 May 2018 19:13:47 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w4SJDe2D030743 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 28 May 2018 15:13:45 -0400 Received: by simark.ca (Postfix, from userid 112) id 643DD1F21C; Mon, 28 May 2018 15:13:40 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 2C7291EF61; Mon, 28 May 2018 15:13:38 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 28 May 2018 22:06:00 -0000 From: Simon Marchi To: Ulrich Weigand Cc: gdb-patches@sourceware.org, simon.marchi@ericsson.com Subject: Re: [RFC PATCH] Read pseudo registers from frame instead of regcache In-Reply-To: <20180528174715.A954AD804AD@oc3748833570.ibm.com> References: <20180528174715.A954AD804AD@oc3748833570.ibm.com> Message-ID: <13ad2ec8a2cd7b6393613e4728d70736@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 28 May 2018 19:13:40 +0000 X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00745.txt.bz2 Hi Ulrich, Thanks for the feedback. On 2018-05-28 13:47, Ulrich Weigand wrote: > Simon Marchi wrote: > >> The problem: Reading pseudo registers from an upper stack frame does >> not >> work. The raw registers needed to compose the pseudo registers are >> always read from the current thread's regcache, which is effectively >> frame #0's registers. > > I think this may have been by design at some point. The idea being: > for the innermost frame, you construct your register set using the > ptrace > (or whatever) interface, possibly using arch-specific constructions > (the "pseudo" registers). But for higher frames, you construct *all* > registers directly via the unwinding logic. That make sense, I don't think my patch really changes that. What my patch changes is that we can reconstruct pseudo register values from unwound raw register values, which we couldn't before. In the simple rbx/ebx case I tried, next_frame will never have info about ebx (trying to use it in cfi_offset gives "bad register expression"), so it doesn't make sense to query it about the location of ebx. > For example, on a platform where a floating-point register was extended > to a vector register at some point, your ptrace interface may be split > between the original FP part, and the "remaining" piece, so to > construct > the full vector register, you'd have to make two ptrace requests and > combine them (using a "pseudo" register). But if you want to find the > value of the vector register in a higher frame, there will be unwind > info for the full vector register, and not the two pieces. > > (This construct actually exists on Intel as well, e.g. with the ymmh > register parts. However, since ymm is not call-saved in the Linux ABI, > we don't have unwind info either way ... In some other ABI, this could > be an actual problem, however.) Ok, I was assuming that it was never possible for the debug info to describe how pseudo registers are saved, only raw registers. Do you have an architecture in mind where it's possible to have a pseudo register mentioned in the unwind information? GNU as doesn't accept at all "ymm0" or "ymm0h" as an argument to .cfi_offset, so I don't know how ymm0 would be represented if we wanted to save it (despite it not being callee saved according to the ABI). If the unwind info can indeed contain explicit information about pseudo registers (and therefore implicit info about the raw registers that compose it), can't it lead to very difficult situations? There is normally only one way to reconstruct a pseudo register value from raw registers. But a raw register can be part of many pseudo registers. So if we need to unwind a raw register value for which the next frame has no explicit information, then we need to check if it has info about all the possible pseudo registers this raw register is part of? > So this change: > >> - /* Ask this frame to unwind its register. */ >> - value = frame->unwind->prev_register (frame, >> &frame->prologue_cache, regnum); >> + struct value *value; >> + if (regnum < gdbarch_num_regs (gdbarch)) >> + { >> + /* This is a raw register, we can directly ask the next frame >> to unwind >> + the register. */ >> + value = next_frame->unwind->prev_register (next_frame, >> + &next_frame->prologue_cache, >> + regnum); >> + } >> + else if (gdbarch_pseudo_register_read_value_p (gdbarch)) >> + { >> + /* This is a pseudo register, we don't know how how what raw >> registers >> + this pseudo register is made of. Ask the gdbarch to read >> the value, >> + it will itself ask the next frame to unwind the values of >> the raw >> + registers it needs to compose the value of the pseudo >> register. */ >> + value = gdbarch_pseudo_register_read_value (gdbarch, >> next_frame, regnum); >> + } > > in effect changes what unwind info GDB expects. Now maybe it is still > the > correct change, but this at least needs a review on how pseudo register > unwind info is currently handled across all architectures ... I'll do what I can, but don't expect me to be an expert of all CPU architectures anytime soon :). Simon