Re: [patches] A few questions on contributing to eglibc

[Steven Munroe <munroesj@xxxxxxxxxx>]

H.J. Lu wrote:
> Hi Ryan,
>
> On Mon, Aug 27, 2007 at 02:30:53PM -0500, Ryan Arnold wrote:
>   
>> Hi H.J.
>>
>> This reply isn't related to your questions (Jim should probably answer
>> those) but rather to submission of DFP/BID support.  I just wanted to let
>> you know that Peter Eberlein (my team member) is working with Jim Blandy
>> right now so we can get libdfp in shape to submit to EGLIBC as well.  Our
>> general framework is here:
>>
>> www.penguinppc.org/dev/glibc/dfp.html
>>
>> Version 0.7 is pretty much what we're going to submit to EGLIBC (plus a few
>> forthcoming patches).
>>
>> BID specific support will tuck into the existing framework nicely in
>> dfp/sysdeps/
>>
>>     
>
> Intel BID library will provide a complete set of optimized DFP
> functions as specified in DFP TR. I only enabled the part of Intel
> BID library in gcc to support DFP intrinsics. I don't think
> we need to put another copy of Intel BID library in eglibc for
> those DFP functions.
>
>   
This sounds like you only have the lowest (IEEE754R) layer. This layer
has to shared between gcc and eglibc but has to meet slightly different
requirements in each. For example the gcc runtime disables all IEEE
exceptions, while the eglibc rumtime need to implement the IEEE754R
exception and integrate them with the libc fenv.h functions.

> DFP functions in Intel BID library take/return unsigned integers
> instead of DFP types. A wrapper function is still needed in eglibc.
> I am thinking to build/install libbid_shared.a and libbid_nonshared.a 
> in gcc. The main usage of them is to build libm.so and libm.a in
> eglibc. Building libm.so can be done with --whole-archive -lbid_shared.
> It will be tricky to include libbid_nonshared.a in libm.a. Maybe
> we can use "ld -r -o bid.o --whole-archive -lbid_nonshared" to
> generate bid.o.
>
>   
There is is lots of function and infrastructure that can and should be
shared. Most of this TR can be implemented in a DPD/BID neutral way and
can be shared. But this requires a common source tree and naming
structure. What you propose is incompatible with the existing DPD
support and only complicate life for EGLIBC.