long double (was "strtold?")
Tue Mar 31 09:32:00 GMT 2009
Ken Werner wrote:
> On Monday 30 March 2009 11:44:37 Ken Werner wrote:
>>> If the platform normally prepends an underscore to a C function, you are
>>> not going to call
>>> the correct C math functions and the linker is going to fail. Feel free
>>> to correct me if I have misinterpreted
>> I see your point. How does the prepend mechanism work on those platforms? I
>> guess calling the correct function could be achived by conditionally
>> prepend the underscore using macro substitution.
> The GCC defines __USER_LABEL_PREFIX that could be handy.
>>> Thus, I would like to see this implemented as it is done for
>>> DOUBLE_IS32BITS. The functions
>>> are declared and implemented as calls to the double versions with casts.
>> Implementing these stubs would work but it would increase the code size
>> too. The GCCs aliasing mechanism might be an alternative. In that case the
>> mapping needs to be done in the translation unit of the referred symbol.
>> The mechanism described in GCCs info page 5.36 "Controlling Names Used in
>> Assembler Code" allows the users code to link against the double
>> counterparts. This could help architectures where the long double is going
>> to change in the future. However, I'm not sure if this approach is
>> compliant with the C99 standard.
> We found an actual problem using the __asm__ approach. The GCC build fails
> for libgfortran. The configure script checks whether the use of the log10l
> function fails to link and sets a corresponding flag called HAVE_LOG10L. The
> c99_functions.c of libgfortran includes <math.h> which maps log10l to log10 if
> my patch is applied. libgfortrans log10l function itself calls the log10 and
> you're stuck in an infinite loop. Such things may happen to other code too. So,
> using the __asm__ mapping method seems not to be the best idea if you can't
> touch the compiler and/or the source code.
> Mapping the long double functions using GCCs __attribute__ (alias) mechanism
> also has its flaws. Beside from the fact that the aliasing need to be done in
> the same translation unit and is only available on GCC (and compatible) it
> assumes the calling convention for long double arguments is the same as for
> double args. Most likely this is true but it's not guaranteed.
> All in all it looks like implementing small wrapper functions that just call
> their counterparts seems to be the way to go - as you suggested. : )
Ok, great. It should not be a code-size issue as you earlier
mentioned. Any application that calls
a C library function has to expect something gets linked in. A small
stub that calls another function
is hardly surprising.
> For the SPU target I'd like to use GCC aliasing to save code size and don't
> pay the penalty of an extra function call. I'll post a patch as soon as I find
> some time.
If you do an SPU-only solution, a preferred way would be to add a
machine/math.h extension to math.h and then have a
libc/spu/machine/math.h file. In libc/include/machine have a math.h
that defaults to empty for everyone else.
-- Jeff J.
More information about the Newlib