From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1958 invoked by alias); 8 Feb 2013 16:30:17 -0000 Received: (qmail 1930 invoked by uid 22791); 8 Feb 2013 16:30:15 -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 16:30:07 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1U3qpy-0007S9-W5 from joseph_myers@mentor.com for libc-ports@sourceware.org; Fri, 08 Feb 2013 08:30:07 -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); Fri, 8 Feb 2013 08:30:06 -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 16:30:04 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1U3qpv-0000v4-PQ; Fri, 08 Feb 2013 16:30:03 +0000 Date: Fri, 08 Feb 2013 16:30:00 -0000 From: "Joseph S. Myers" To: "Maciej W. Rozycki" CC: Subject: Re: Add CFI information for MIPS assembly sources In-Reply-To: Message-ID: References: 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/msg00016.txt.bz2 On Fri, 8 Feb 2013, Maciej W. Rozycki 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. > 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. > 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. -- Joseph S. Myers joseph@codesourcery.com