From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31620 invoked by alias); 8 Feb 2013 01:06:58 -0000 Received: (qmail 31612 invoked by uid 22791); 8 Feb 2013 01:06:57 -0000 X-SWARE-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 08 Feb 2013 01:06:53 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1U3cQW-0007jU-RR from joseph_myers@mentor.com ; Thu, 07 Feb 2013 17:06:52 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Feb 2013 17:06:52 -0800 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Fri, 8 Feb 2013 01:06:50 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1U3cQT-0005Vl-HB; Fri, 08 Feb 2013 01:06:49 +0000 Date: Fri, 08 Feb 2013 01:06:00 -0000 From: "Joseph S. Myers" To: Roland McGrath CC: , Subject: Re: Add CFI information for MIPS assembly sources In-Reply-To: <20130208004718.C3AA12C098@topped-with-meat.com> Message-ID: References: <20130208000754.B61082C098@topped-with-meat.com> <20130208004718.C3AA12C098@topped-with-meat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00013.txt.bz2 On Thu, 7 Feb 2013, Roland McGrath wrote: > > Unfortunately sys/asm.h is an installed header implementing some > > externally-defined SGI API, but also used internally in glibc for various > > things. So the CFI in start/end of function macros there is using > > implementation-namespace __mips_cfi_* macros (existing practice for other > > architectures being to put CFI in the start/end of function macros), > > defined conditionally on _LIBC, and any variation on SETUP_GP64 would I > > suppose also need to be in the implementation namespace or conditioned on > > _LIBC. (For a non-architecture-specific header you might have an internal > > include/sys/asm.h for internal macros, but that's not an option here. Or > > put the variants in sysdep.h, but that's separating macros from > > closely-related other macros.) > > For other similar reasons I've been considering supporting > sysdeps/.../include/ directories. Those would be in the -I list for > building libc, but not in sysdirs and so not candidates for installation. > I can do the makefile hackery if you'd like to use that. I agree such directories would be useful for handling the sys/asm.h changes more cleanly. > Then if it were me I'd just leave out the SETUP_GP* cases in the first > patch and leave them for after the blocking issues were cleared out in > further incremental changes. I'd rather not have too much inaccurate / incomplete CFI (as opposed to code with no CFI at all), although since none of the affected places are valid for throwing exceptions through, the effects are much the same as for no CFI (inaccurate register values in backtraces e.g. with GDB, in the gp cases). (I think with this patch, CFI is present but incomplete / inaccurate only for __syscall_error and a few instructions in setcontext, but not for the lots of other functions that save and restore gp.) -- Joseph S. Myers joseph@codesourcery.com