[coreboot] [PATCH] Math support for libpayload

[Stefan Reinauer]

On 2/7/10 5:29 PM, Patrick Georgi wrote:
> Then, there are design questions: this libm is made for userland, with a
> kernel expected to provide support if anything goes wrong. How does the
> math library cope with FPU exceptions? Does it at all?
>   
I have to second that
> There are also concerns of size (I didn't check, but the libm is easily
> as large as the rest of libpayload, incl. its drivers). I'm not worried
> too much about it, but maybe others are?
>   
It increases code size of libpayload roughly by a factor of five..
That's an incredible amount of code.

The code is unfortunately not quite clean and not really adapted to
libpayload either. In fact, it looks like the BSD sources have mostly
been just untarred in the libpayload directory.

A few checks show

- string.h provides functions like ffs() which is never defined
- string.h provides prototypes for many functions that are still listed
in libpayload.h, like memcpy, memcmp etc
- none of the new includes have doxygen comments
- the includes introduce many new and undocumented preprocessor flags,
like __BSD_VISIBLE and __XPG_VISIBLE that might
- ctype.h implements a whole bunch of functions in a .h file.
- those functions already exist in ctype.c
- lots of odd undocumented functionality like several setjmp implementations
- mc68881 assembler versions of math functions?!?
- man pages under libm/man?
- source files under libm/src
- rcsids?
- patch to readline() breaks existing code out there
- code introduces a couple of warnings with our reference toolchain,
which will cause some payloads to break because they use -Werror.

Roughly I think that this approach of adding code to libpayload is not
preferrable. It would be much nicer to see that those functions used by
tinyscheme are chosen carefully, be added to libpayload in minimal
implementations and commented in the same style we commented all the
rest of libpayload.

Stefan