This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [SH][PATCH] __fpscr_values broken


Daniel Jacobowitz <drow@false.org> wrote:
> 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?

Yep.  fpscr has the status and control bits for floating
exceptions and rounding modes and the programs set them
with the function like fesetexceptflag and fesetround via
_FPU_SETCW.  These should effect globally in one executable
image in theory.  In practice, it isn't problem if all part
of the executable image which is related with the floating
exceptions and rounding modes will see one __fpscr_value.

> 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.

Agreed, though I think that current scheme and the Andrew's
patch will work for almost all cases by the above reason.
It may be possible to construct a pathological counter example,
though SH isn't for that complex and exact floating applications
in the first place :-)
I'm afraid only the compatibility problems for this patch.
It wouldn't be wrong to add this patch as the local patch
for a specific distribution because such case is free from
the compatibility problems, but looks a bit problematic
as the generic one.  I don't object this patch strongly,
but why no-z-defs=yes in configparms isn't enough?

Regards,
	kaz


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]