From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3905 invoked by alias); 7 Dec 2007 18:39:30 -0000 Received: (qmail 3877 invoked by uid 22791); 7 Dec 2007 18:39:29 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Dec 2007 18:38:08 +0000 Received: (qmail 13894 invoked from network); 7 Dec 2007 18:38:06 -0000 Received: from unknown (HELO ?192.168.0.2?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 7 Dec 2007 18:38:06 -0000 Message-ID: <47599307.30409@codesourcery.com> Date: Fri, 07 Dec 2007 18:39:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Rask Ingemann Lambertsen CC: GCC Patches , rsandifo@nildram.co.uk, fortran@gcc.gnu.org, java-patches@gcc.gnu.org Subject: Re: Link tests after GCC_NO_EXECUTABLES References: <87d4tqu4nv.fsf@firetop.home> <20071201115252.GS17368@sygehus.dk> <20071201120251.GT17368@sygehus.dk> <20071201223447.GU17368@sygehus.dk> <47531F54.6010802@codesourcery.com> <20071205172224.GM17368@sygehus.dk> <47574456.1070108@codesourcery.com> <20071206175819.GO17368@sygehus.dk> <4758A3BD.5050102@codesourcery.com> <20071207153101.GR17368@sygehus.dk> In-Reply-To: <20071207153101.GR17368@sygehus.dk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-12/txt/msg00360.txt.bz2 Rask Ingemann Lambertsen wrote: > On Thu, Dec 06, 2007 at 05:37:01PM -0800, Mark Mitchell wrote: >> Rask Ingemann Lambertsen wrote: >> >>> gcc_cv_have_tls=${gcc_cv_have_tls=yes} >> How do we get TLS with Newlib on the average bare-metal target? > > I thought I saw a patch for that going in a while ago, but configuring > libjava on arm-unknown-elf returns no, so I'll change the cache file > accordingly. I have to admit that I'm getting concerned. The issue Richard has raised about Cygwin, and the various corner-cases here are making me think that we're at risk of introducing instability. I was trying to go along with your patch because it seemed like a compromise between (a) the top-level patch to make things link (even though they may not correspond to how the toolchain will be used) and (b) going backwards (undoing the ability to build various run-time libraries that the top-level patch added). I was thinking that a basic cache file would be safe, in the sense that at least it might accidentally disable a capability or two, but not use capabilities that aren't there. But, I'm afraid that we're going to have a hard time getting it set conservative enough, and that if we do we're going to miss important capabilities. I'm afraid that we're making a relatively large change relatively late in the game. I think I'd prefer to be more conservative: return to the state we had with previous releases. The patch that Richard tested fixes libstdc++ and allows us to revert the various top-level changes. Then, for 4.4, we can tackle the broad question of how we ought to be build the run-time libraries for bare-metal. Maybe configure-time arguments that let the toolchain link in a representative way for the target environment? Or a cache file that contains answers to the questions the run-time library configury is going to ask? Or hand-coded logic like presently used by libstdc++? Since you have strong opinions about this, perhaps you could lead this debate. Would you be willing to go along with that plan? -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713