[linuxsh-dev] Re: __fpscr_values

[Daniel J. <dr...@fa...>]

On Wed, May 07, 2003 at 09:13:42AM +0900, kaz Kojima wrote:
> Hi,
> 
> >I feel like every time I upgrade tools I spend a day chasing after
> >__fpscr_values...
> >
> >Kaz, it looks like the current state of the tools has it in (for
> >Linux) start.S in glibc, which puts it in crt1.o.  That means there's
> >no copy of it in libm; just references to it.  But libm is built with
> >-z defs, so the undefined reference is an error.
> >
> >Why did it move out of crti.o?
> 
> Because it should be an unique object in the execution. FPSCR
> has the bits to control the behavior for math exceptions and
> if there are multiple __fpscr_values objects, we can't control
> this behavior.
> 
> To avoid -z defs issue, you could use no-z-defs=yes in libc
> configparms. Yes, it removes all useful checks with -z defs,
> but...
> It might be better to add a new ld option to allow an exception
> for -z defs something like --allow-shlib-undefined-sym SYMBOL.
> 
> Anyway, sorry for forgetting to write this issue to these list.
> About __fpscr_values issue itself, Joern Rennecke and Alexandre
> Oliva said independently to me that one solution is to give a
> fixed address for __fpscr_values and support it by GCC.
> Perhaps stack top would be a candidate.

At the risk of missing something obvious... why not put it in libc.so
and libc.a (not libc_nonshared.a) directly if all you want is for it to
be unique in the executable?  There is always exactly one copy of libc
loaded, and everything should be dynamically linked to it except for
ld.so.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer