From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17503 invoked by alias); 8 Feb 2013 17:52:51 -0000 Received: (qmail 17495 invoked by uid 22791); 8 Feb 2013 17:52:49 -0000 X-SWARE-Spam-Status: No, hits=-4.5 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 17:52:44 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1U3s7v-0006TY-W2 from Maciej_Rozycki@mentor.com for libc-ports@sourceware.org; Fri, 08 Feb 2013 09:52:44 -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); Fri, 8 Feb 2013 09:52:43 -0800 Received: from [172.30.64.124] (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 17:52:41 +0000 Date: Fri, 08 Feb 2013 17:52:00 -0000 From: "Maciej W. Rozycki" To: "Joseph S. Myers" CC: Subject: Re: Add CFI information for MIPS assembly sources In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) 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/msg00017.txt.bz2 On Fri, 8 Feb 2013, Joseph S. Myers wrote: > > 1. If I were the maintainer, I'd expect the change to convert sources to > > use ENTRY/END/etc. properly to be done separately, preferably before > > making changes to add CFI pieces so as not to obfuscate the actual > > matter of this change. It would make people easier to review this > > change too. Of course it's you who are the MIPS maintainer, so it's > > just my opinion, you're free to do whatever you like there. > > I have committed this part separately. Thanks. > > 2. Given the implementation I fail to see the point of modifying > > at all. Yes, it saves a line here or there, but at the > > cost of non-standard semantics, some obfuscation, and then you need to > > Standard semantics in glibc are that cfi_startproc and cfi_endproc go in > the macros used to define the start and end of functions, rather than in > the .S files using those macros (except in special cases where it's > necessary to avoid CFI covering part of a function, e.g. for clone). > > Roland's addition of a sysdeps/.../include mechanism should allow most of > the internal macros to go in sysdeps/mips/include/sys/asm.h rather than > the installed header, although some changes will still be needed to the > installed header to add the use of __mips_cfi_* to the relevant macros. Hmm, this overall sounds like a good idea to me, however I still feel a bit uneasy about fiddling with these standard (as far as MIPS usage is concerned) macros in a publicly installed header. At the same time I realise the semantics of the C preprocessor language makes it difficult to overload macros without pasting the same body over and over again. However it should be possible to wrap the macros into other ones by using a different name. This way the public macros would remain intact (yes, I do have a concern as to the consistency of vs -- they share a common ancestor, they provide abstract definitions that have nothing to do specifically with userland or Linux kernel code and are both meant to serve the same purpose, so the fewer divergences the better), e.g. #define _LIBC_LEAF(symbol) \ LEAF (symbol) \ cfi_startproc (or perhaps call it _CFI_LEAF instead?). What do you think? Likewise the others, and... > > 3. On the other hand it may be worthwhile to avoid obfuscation like: > > > > # if _MIPS_SIM != _ABIO32 > > cfi_rel_offset (gp, GPOFF) > > # endif > > > > and define a macro like mips_cfi_rel_offset64 (a better name may be > > possible, perhaps just cfi_rel_offset64) that'll handle the ABI > > condition in the definition, pretty much like SETUP_GP64 does. > > Likewise with complementing cfi_restore. > > SETUP_GP64_REG and SETUP_GP64_STACK (and similar RESTORE_GP64_*) are what > I'm thinking of for include/sys/asm.h (the internal header) to combine the > calls to the existing macros with providing CFI information. ... that would solve the issue of these macros as well. Maciej