From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22588 invoked by alias); 28 Jan 2013 21:17:42 -0000 Received: (qmail 22475 invoked by uid 22791); 28 Jan 2013 21:17:40 -0000 X-SWARE-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from dns1.mips.com (HELO dns1.mips.com) (12.201.5.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 Jan 2013 21:17:33 +0000 Received: from mailgate1.mips.com (mailgate1.mips.com [12.201.5.111]) by dns1.mips.com (8.13.8/8.13.8) with ESMTP id r0SLHSbj023846; Mon, 28 Jan 2013 13:17:28 -0800 X-M-MSG: Received: from exchdb01.mips.com (unknown [192.168.36.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate1.mips.com (Postfix) with ESMTP id 24062364654; Mon, 28 Jan 2013 13:17:21 -0800 (PST) Received: from [192.168.65.53] (192.168.65.53) by exchhub01.mips.com (192.168.36.84) with Microsoft SMTP Server id 14.2.247.3; Mon, 28 Jan 2013 13:17:19 -0800 Subject: Re: [PATCH 2/2] MIPS16: MIPS16 support proper From: Steve Ellcey To: "Maciej W. Rozycki" CC: Richard Henderson , "libc-alpha@sourceware.org" , "libc-ports@sourceware.org" , Chung-Lin Tang , In-Reply-To: References: <1359151771.11963.200.camel@ubuntu-sellcey> <1359394555.32571.12.camel@ubuntu-sellcey> <5106CA30.4070306@twiddle.net> Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Jan 2013 21:17:00 -0000 Message-ID: <1359407838.32571.23.camel@ubuntu-sellcey> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-EMS-Proccessed: 6LP3oGfGVdcdb8o1aBnt6w== X-EMS-STAMP: OkVKllysj1PPX8A0B2G2Cg== 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/msg00070.txt.bz2 On Mon, 2013-01-28 at 21:06 +0000, Maciej W. Rozycki wrote: > On Mon, 28 Jan 2013, Richard Henderson wrote: > > > 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 Would switching from .init to DT_INIT_ARRAY be an incompatible ABI change? I think I remember the GNU linker can handle mixing both types of sections in one executable but I am not sure if that is right. I added Richard Sandiford to this email in case he hasn't seen it on the libc mailing lists. Steve Ellcey sellcey@mips.com