From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16170 invoked by alias); 28 Jan 2013 21:06:39 -0000 Received: (qmail 16151 invoked by uid 22791); 28 Jan 2013 21:06:37 -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; Mon, 28 Jan 2013 21:06:31 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1TzvuQ-0003Gn-At from Maciej_Rozycki@mentor.com ; Mon, 28 Jan 2013 13:06:30 -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); Mon, 28 Jan 2013 13:06:30 -0800 Received: from [172.30.6.221] (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; Mon, 28 Jan 2013 21:06:28 +0000 Date: Mon, 28 Jan 2013 21:06:00 -0000 From: "Maciej W. Rozycki" To: Richard Henderson CC: Steve Ellcey , "libc-alpha@sourceware.org" , "libc-ports@sourceware.org" , Chung-Lin Tang Subject: Re: [PATCH 2/2] MIPS16: MIPS16 support proper In-Reply-To: <5106CA30.4070306@twiddle.net> Message-ID: References: <1359151771.11963.200.camel@ubuntu-sellcey> <1359394555.32571.12.camel@ubuntu-sellcey> <5106CA30.4070306@twiddle.net> 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-01/txt/msg00068.txt.bz2 On Mon, 28 Jan 2013, Richard Henderson wrote: > > OK, I see where this is happening now. crti (from glibc) is mips16 and > > crtbegin (from gcc) is mips32. crtbegin is mips32 because it uses > > CRT_CALL_STATIC_FUNCTION and that has '.nomips16' in it. I am not sure > > how to rewrite CRT_CALL_STATIC_FUNCTION in mips16 to avoid this and it > > looks like the codesourcery version of GCC is handling this by making > > all .init/.fini code mips32 instead of mips16. So, should I try to make > > crti use a mips32 .init or make crtbegin use a mips16 .init? I am not > > sure which is better. > > FWIW, I think you're better off considering the .init section to be > mips32 code always, as a part of the ABI. That way stuff that worked > before continues to work, and no one has to worry about how the > installed toolchain itself is configured. That may work as a temporary measure for MIPS16 code only, as any processor that supports MIPS16 execution must also support standard MIPS execution. However we have the very same problem with microMIPS code -- that glibc supports out of the box thanks to the high level of source compatibility the ISA provides and GCC support for which is currently under review. There we cannot agree upon using standard MIPS code in .init/.fini because we have conflicting objectives to choose from: 1. We want to support mixing standard MIPS and microMIPS code, so we cannot assume all binary modules in a static link will use the same encoding. 2. We want to support processors that only support either instruction encoding, so the encoding of .init/.fini code has to match the encoding of the remaining parts of the module concerned. And regardless of the scenario chosen we want to keep the same binary modules built for either ISA without the need to rebuild any parts of them. > And of course as you note elsewhere, this is an excellent time to > have new toolchains stop using .init, as DT_INIT_ARRAY has none of > these problems. Given the above I think we need it sooner rather than later. Who's got the power to make it happen? Maciej