From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109664 invoked by alias); 28 May 2018 17:47:25 -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 109655 invoked by uid 89); 28 May 2018 17:47:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=*all*, ymm, ptrace, HContent-Transfer-Encoding:8bit X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 28 May 2018 17:47:23 +0000 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4SHdCft110331 for ; Mon, 28 May 2018 13:47:21 -0400 Received: from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110]) by mx0b-001b2d01.pphosted.com with ESMTP id 2j8ntrh8ym-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 28 May 2018 13:47:21 -0400 Received: from localhost by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 28 May 2018 18:47:20 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 28 May 2018 18:47:16 +0100 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w4SHlGJR22675656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 28 May 2018 17:47:16 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0EAF242041; Mon, 28 May 2018 18:37:50 +0100 (BST) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F189C4203F; Mon, 28 May 2018 18:37:49 +0100 (BST) Received: from oc3748833570.ibm.com (unknown [9.152.213.77]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 28 May 2018 18:37:49 +0100 (BST) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id A954AD804AD; Mon, 28 May 2018 19:47:15 +0200 (CEST) Subject: Re: [RFC PATCH] Read pseudo registers from frame instead of regcache To: simon.marchi@polymtl.ca (Simon Marchi) Date: Mon, 28 May 2018 19:13:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, simon.marchi@ericsson.com (Simon Marchi) In-Reply-To: <20180526002406.18166-1-simon.marchi@polymtl.ca> from "Simon Marchi" at May 25, 2018 08:24:06 PM MIME-Version: 1.0 X-TM-AS-GCONF: 00 x-cbid: 18052817-0044-0000-0000-00000557B1D0 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18052817-0045-0000-0000-00002899BBE5 Message-Id: <20180528174715.A954AD804AD@oc3748833570.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-28_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805280212 X-SW-Source: 2018-05/txt/msg00743.txt.bz2 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. 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.) 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 ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com