From: Mark Mitchell <mark@codesourcery.com>
To: Rask Ingemann Lambertsen <rask@sygehus.dk>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
rsandifo@nildram.co.uk, fortran@gcc.gnu.org,
java-patches@gcc.gnu.org
Subject: Re: Link tests after GCC_NO_EXECUTABLES
Date: Fri, 07 Dec 2007 18:39:00 -0000 [thread overview]
Message-ID: <47599307.30409@codesourcery.com> (raw)
In-Reply-To: <20071207153101.GR17368@sygehus.dk>
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
next prev parent reply other threads:[~2007-12-07 18:39 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <46EFBCC1.6070200@gmail.com>
[not found] ` <46EFC383.7020503@t-online.de>
[not found] ` <46EFC9E9.7090201@gmail.com>
[not found] ` <46EFCEF9.3060304@t-online.de>
[not found] ` <46EFCF7A.2080704@gmail.com>
[not found] ` <46EFD236.6080907@t-online.de>
[not found] ` <46EFDA4D.3070006@gmail.com>
2007-11-27 15:35 ` Bernd Schmidt
2007-11-27 22:17 ` Mark Mitchell
2007-11-27 22:40 ` Bernd Schmidt
2007-11-27 22:43 ` Mark Mitchell
2007-11-27 22:58 ` Bernd Schmidt
2007-11-27 23:17 ` Mark Mitchell
2007-11-28 0:23 ` Bernd Schmidt
2007-11-28 0:33 ` Mark Mitchell
2007-11-28 1:03 ` Bernd Schmidt
2007-11-28 1:24 ` Mark Mitchell
2007-11-28 6:34 ` Bernd Schmidt
2007-11-28 10:37 ` Mark Mitchell
2007-11-28 15:47 ` Bernd Schmidt
2007-11-28 8:16 ` Joseph S. Myers
2007-11-28 10:01 ` Mark Mitchell
2007-11-28 11:37 ` Joseph S. Myers
2007-11-28 11:40 ` Mark Mitchell
2007-11-28 15:37 ` Bernd Schmidt
2007-11-28 13:07 ` Richard Sandiford
2007-11-28 16:06 ` Rask Ingemann Lambertsen
2007-11-28 16:59 ` Daniel Jacobowitz
2007-11-28 18:55 ` Mark Mitchell
2007-11-28 22:41 ` Richard Sandiford
2007-11-28 23:03 ` Rask Ingemann Lambertsen
2007-11-29 6:21 ` Mark Mitchell
2007-11-30 21:07 ` Rask Ingemann Lambertsen
2007-11-30 21:08 ` Mark Mitchell
[not found] ` <20071130211005.GQ17368@sygehus.dk>
2007-12-01 9:48 ` Richard Sandiford
2007-12-01 11:53 ` Rask Ingemann Lambertsen
2007-12-01 12:03 ` Rask Ingemann Lambertsen
2007-12-01 13:37 ` Andreas Schwab
2007-12-01 22:35 ` Rask Ingemann Lambertsen
2007-12-02 21:11 ` Mark Mitchell
2007-12-05 17:22 ` Rask Ingemann Lambertsen
2007-12-06 0:38 ` Mark Mitchell
2007-12-06 17:58 ` Rask Ingemann Lambertsen
2007-12-07 1:37 ` Mark Mitchell
2007-12-07 15:31 ` Rask Ingemann Lambertsen
2007-12-07 18:39 ` Mark Mitchell [this message]
2007-12-07 21:48 ` Rask Ingemann Lambertsen
2007-12-07 21:57 ` Mark Mitchell
2007-12-13 22:25 ` [PATCH v2] " Rask Ingemann Lambertsen
2007-12-30 13:46 ` Ping " Rask Ingemann Lambertsen
2007-12-30 17:41 ` Paolo Bonzini
2007-12-07 11:27 ` Richard Sandiford
2007-12-07 15:18 ` Rask Ingemann Lambertsen
2007-12-08 11:25 ` Richard Sandiford
2007-12-04 14:46 ` Rask Ingemann Lambertsen
2007-12-05 0:10 ` Hans-Peter Nilsson
2007-12-05 0:19 ` Rask Ingemann Lambertsen
2007-12-05 0:46 ` Hans-Peter Nilsson
2007-11-30 3:56 ` Richard Sandiford
2007-11-30 5:32 ` Mark Mitchell
2007-11-30 8:07 ` Benjamin Kosnik
2007-11-30 9:58 ` Rask Ingemann Lambertsen
2007-11-30 11:41 ` Mark Mitchell
2007-11-30 23:25 ` Rask Ingemann Lambertsen
2007-11-30 13:16 ` Richard Sandiford
2007-11-30 20:32 ` Rask Ingemann Lambertsen
2007-11-30 21:10 ` Mark Mitchell
2007-11-30 21:15 ` DJ Delorie
2007-12-01 9:55 ` Richard Sandiford
2007-12-02 21:01 ` Mark Mitchell
2007-12-03 15:55 ` Richard Sandiford
2007-12-03 14:40 ` btest-gcc.sh patch ping and " Hans-Peter Nilsson
2007-12-03 16:07 ` Richard Sandiford
2007-12-03 22:43 ` Hans-Peter Nilsson
2007-12-03 16:59 ` Geoff Keating
2007-12-03 22:39 ` Hans-Peter Nilsson
2007-12-04 6:52 ` Geoff Keating
2007-12-04 22:26 ` btest-gcc.sh patch ping Hans-Peter Nilsson
2009-03-28 14:10 ` btest-gcc.sh patch ping and Re: Link tests after GCC_NO_EXECUTABLES Richard Guenther
2009-03-28 20:37 ` Geoff Keating
2007-11-30 20:49 ` Rask Ingemann Lambertsen
2008-05-15 21:40 ` Bernd Schmidt
2008-05-15 23:02 ` Richard Sandiford
2008-05-15 23:10 ` Bernd Schmidt
2008-05-16 0:18 ` Mark Mitchell
2008-05-16 2:21 ` Joseph S. Myers
2008-06-18 21:05 ` Ralf Wildenhues
2008-06-19 3:57 ` Mark Mitchell
2008-07-07 20:14 ` Ralf Wildenhues
2007-11-28 8:54 ` Joseph S. Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47599307.30409@codesourcery.com \
--to=mark@codesourcery.com \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=java-patches@gcc.gnu.org \
--cc=rask@sygehus.dk \
--cc=rsandifo@nildram.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).