This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [SH][PATCH] __fpscr_values broken
- From: Daniel Jacobowitz <drow at false dot org>
- To: Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>
- Cc: vapier at gentoo dot org, libc-alpha at sourceware dot org, ams at codesourcery dot com
- Date: Sat, 31 Jan 2009 11:21:14 -0500
- Subject: Re: [SH][PATCH] __fpscr_values broken
- References: <4981BEED.6050904@codesourcery.com> <200901301658.45895.vapier@gentoo.org> <20090131.112354.90419140.kkojima@rr.iij4u.or.jp>
On Sat, Jan 31, 2009 at 11:23:54AM +0900, Kaz Kojima wrote:
> No, it was broken before glibc-2.3.2 era. Before that era,
> every shared libraries may have their own local __fpscr_values
> given by libgcc. It's wrong because __fpscr_values should be
> the unique object in the executable image. We put __fpscr_values
> in the crt object to avoid the issue. Unfortunately it causes
> the link time error with z-defs option when building libc/libm.
> Pragmatically, putting it in libc.so is not problem because
> almost all programs would link with libc. Though we decided
> not to do so and it'd be too late to change it.
I tried to work out why it had to be unique in the executable.
There's __set_fpscr, but it is only called by crt1.asm used for newlib
targets. Is it only to support fpu_control.h:_FPU_SETCW?
If it does have to be unique, I don't think Andrew's patch will
work :-( But I don't understand how it works today, in that
case. ld.so exports __fpscr_values@@GLIBC_PRIVATE, which libc
will presumably see at runtime. Another copy is in start.S and ends
up in each application.
--
Daniel Jacobowitz
CodeSourcery