From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19340 invoked by alias); 8 Feb 2013 00:42:04 -0000 Received: (qmail 19320 invoked by uid 22791); 8 Feb 2013 00:42:03 -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 00:41:57 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1U3c2O-0006Bd-2i from joseph_myers@mentor.com ; Thu, 07 Feb 2013 16:41:56 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Feb 2013 16:41:55 -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 00:41:54 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1U3c2L-0000Rv-1s; Fri, 08 Feb 2013 00:41:53 +0000 Date: Fri, 08 Feb 2013 00:42:00 -0000 From: "Joseph S. Myers" To: Roland McGrath CC: , Subject: Re: Add CFI information for MIPS assembly sources In-Reply-To: <20130208000754.B61082C098@topped-with-meat.com> Message-ID: References: <20130208000754.B61082C098@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/msg00011.txt.bz2 On Thu, 7 Feb 2013, Roland McGrath wrote: > > For SETUP_GP64 and RESTORE_GP64, the cfi_* directives are in the > > individual .S files rather than the macro definitions because the > > macros can be used to save the old gp value in either a register or a > > stack slot, and those need different CFI directives, so a single macro > > SETUP_GP64 can't handle both cases and generate CFI at the same time. > > It seems much cleaner to define two pairs of macros for the two cases, > so that the macros can contain the CFI details too. Separating the code > from the CFI like you've done will always be error-prone. Using separate > macros is less total text, as well as less duplication of magic numbers. 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.) (Putting CFI within those macros would also then bring in the need to deal with CFI for inline asm in the same patch - those macros are used, stringized, in inline asm in dl-machine.h and dl-trampoline.c, which would then need at least .cfi_startproc/.cfi_endproc for the functions defined in inline asm. So it would also make it harder to get in useful pieces of CFI incrementally without needing to add all the CFI for all of glibc at once.) -- Joseph S. Myers joseph@codesourcery.com