This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Improve TLS link test for cross-compiling
- From: Andrew Pinski <pinskia at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, java-patches at gcc dot gnu dot org
- Date: Thu, 2 Jul 2009 12:47:01 -0700
- Subject: Re: Improve TLS link test for cross-compiling
- References: <Pine.LNX.4.64.0907021941020.23975@digraph.polyomino.org.uk>
On Thu, Jul 2, 2009 at 12:44 PM, Joseph S. Myers<joseph@codesourcery.com> wrote:
> When cross-compiling, GCC_CHECK_TLS uses a link-time test for TLS
> support. ÂHowever, code built for an executable, or linked into an
> executable, can link OK when libc in fact lacks TLS support, even if
> code linked into a shared library would not, because of the different
> TLS access models and linker optimizations used in the different
> cases.
>
> This patch adds an additional link-time test for linking with -shared
> -Wl,--no-undefined in this case: if linking a non-TLS file with those
> options succeeds (so, in particular, they are appropriate options for the
> target in question), but linking TLS code with them fails, then TLS is not
> supported. ÂTested with no regressions with cross to i686-pc-linux-gnu
> using a sysroot with pre-TLS libc. ÂOK to commit?
What about the case when TLS enum is used and -shared does not exist
for the target (I am thinking of darwin or windows)?
Does it check for that case too?
Thanks,
Andrew Pinski