This is the mail archive of the libc-alpha@sources.redhat.com 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: ppc completely soft patches


Aldy Hernandez <aldyh@redhat.com> writes:

> > > For soft-float, gcc will emit calls to these in user space, and we want
> > > to use the library functions in libc, not the ones that come with
> > > libgcc.
> > 
> > Well, what's wrong with the functions in nof/libgcc.a? If gcc is used for 
> 
> libgcc is not only slower, but does not handle exceptions or rounding
> modes.

Why can't it be enhanced to do this?

> And even if it did handle, say rounding modes-- how would you set it?
> Glibc's <fenv.h> routines set that.

You'd define an interface that libgcc provides---perhaps a global
variable, perhaps some nice thread-safe functions---and that fenv.h uses.

> > linking they will always be used anyway, cause the link order is -lgcc -lc 
> > -lgcc? If the functions in libgcc.a are broken, libgcc should be fixed 
> > instead, or?
> 
> Yup, you are correct.  You'd have to add -lc to your command line to
> link libc first.  It's on my TODO list to hack gcc to link -lc first
> when switch foo-foo-bar is passed.

If you've decided that these routines should live in glibc, then the
proper way to deal with this is to not generate them in libgcc.
Having one copy in libgcc and another copy in libc with different
semantics is just asking for trouble.

-- 
- Geoffrey Keating <geoffk@geoffk.org>


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