From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3686 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Current status: important changes since 0.9.11 Date: Fri, 19 Jul 2013 14:53:01 -0400 Message-ID: <20130719185301.GJ12469@brightrain.aerifal.cx> References: <20130719161234.GA8335@brightrain.aerifal.cx> <20130719203923.1a411332@ralda.gmx.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1374259995 27808 80.91.229.3 (19 Jul 2013 18:53:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Jul 2013 18:53:15 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3690-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jul 19 20:53:17 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1V0Fnn-00063T-J3 for gllmg-musl@plane.gmane.org; Fri, 19 Jul 2013 20:53:15 +0200 Original-Received: (qmail 19719 invoked by uid 550); 19 Jul 2013 18:53:14 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 19704 invoked from network); 19 Jul 2013 18:53:14 -0000 Content-Disposition: inline In-Reply-To: <20130719203923.1a411332@ralda.gmx.de> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3686 Archived-At: On Fri, Jul 19, 2013 at 08:39:23PM +0200, Harald Becker wrote: > Hi Rich ! > > > Oh, and the new crt1.c idea could probably go in too, even > > though it won't be used much yet except possibly adding PIE > > support on mips, powerpc, and microblaze. > > I looked at your new crt1.c and I like it. Why not using it for > main stream purpose if it works for all purposes? Are there any My feeling was just that: 1. We already have "optimized asm" for a few archs, and I didn't see a strong argument for removing it. 2. There's a chance to mess up odd arch-specific requirements, alignment, etc. in the new asm fragment unless it undergoes some careful review. However I do also agree with you, and think simplicity/consistency possibly override reason #1 above, and #2 could easily be handled if some time is put into review and testing of the new code. Anyone else have opinions on the matter? Rich