From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117805 invoked by alias); 29 May 2018 13:12:11 -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 116565 invoked by uid 89); 29 May 2018 13:12:10 -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= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 May 2018 13:12:09 +0000 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4TD8J0M133631 for ; Tue, 29 May 2018 09:12:07 -0400 Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108]) by mx0a-001b2d01.pphosted.com with ESMTP id 2j953hf4sw-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 29 May 2018 09:12:07 -0400 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 29 May 2018 14:12:04 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Tue, 29 May 2018 14:12:03 +0100 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w4TDC2JK18481230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 29 May 2018 13:12:02 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9A5BAAE051; Tue, 29 May 2018 14:01:09 +0100 (BST) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 88987AE04D; Tue, 29 May 2018 14:01:09 +0100 (BST) Received: from oc3748833570.ibm.com (unknown [9.152.213.77]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 29 May 2018 14:01:09 +0100 (BST) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id 3E402D804DA; Tue, 29 May 2018 15:12:02 +0200 (CEST) Subject: Re: [RFC PATCH] Read pseudo registers from frame instead of regcache To: simon.marchi@polymtl.ca (Simon Marchi) Date: Tue, 29 May 2018 14:53:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, simon.marchi@ericsson.com In-Reply-To: <145043fef77f5d64d115e5a83a5148b3@polymtl.ca> from "Simon Marchi" at May 28, 2018 06:18:25 PM MIME-Version: 1.0 X-TM-AS-GCONF: 00 x-cbid: 18052913-0008-0000-0000-000004FC31F1 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18052913-0009-0000-0000-00001E904F80 Message-Id: <20180529131202.3E402D804DA@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-29_05:,, 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-1805290150 X-SW-Source: 2018-05/txt/msg00756.txt.bz2 Simon Marchi wrote: > On 2018-05-28 15:13, Simon Marchi wrote: > > 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). > > I looked at ARMv7, and one case where this might happen is the VFP > registers. The dX registers (64-bits) are the raw ones and the sX > (32-bits) are the pseudo ones (where two sX registers make up one dX > register). The GNU assembler accepts using s0 with .cfi_offset (for > backwards compatibility, I guess?), so we end up with it in the unwind > info. However, this is an obsolete way of doing it according to the > "DWARF for the ARM Architecture" document [1]. They recommend to > describe the sX registers as bit pieces of the dX registers. That > recommendation would be in line with the "only raw registers in unwind > info" assumption. But it means that we can encounter this in the wild. Another consideration is where GDB itself massages the DWARF info to use pseudo register numbers; one way to check for that is to look for instances of gdbarch_dwarf2_reg_to_regnum where the returned value is a pseudo register number. At a quick glance, it seems that MEP does that (for pretty much all registers?), SPU does it for the special SP register, h8300 does it for a special CCR register, xtensa seems to do it for some registers (driven by a table) etc. (I didn't review all archictures. Also, not all of those registers are necessarily used for *unwinding*, some DWARF registers may only be used for DWARF debug info / locations. But in at least in the SPU case, I know that SP *is* used for unwinding.). Now for the internal uses, I guess those could all be fixed by GDB internal changes to those targets in one way or the other. But still, this would need to be done to prevent your patch from breaking existing platforms ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com