This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: Updated patch for dealing with __infinity and small data areas
- To: Chris Faylor <cgf at cygnus dot com>
- Subject: Re: Updated patch for dealing with __infinity and small data areas
- From: Michael Meissner <meissner at cygnus dot com>
- Date: Sat, 29 Jul 2000 16:13:57 -0400
- Cc: Michael Meissner <meissner at redhat dot com>, newlib at sources dot redhat dot com
- References: <200007281630.MAA10338@tiktok.cygnus.com> <20000729012803.A16631@cygnus.com>
On Sat, Jul 29, 2000 at 01:28:04AM -0400, Chris Faylor wrote:
> I don't understand the reason for using __INFINITY_DECL__. It seems
> gratuitous unless somebody is declaring this in a Makefile somewhere.
>
> Since the __declspec(dllimport) stuff is already sprinkled throughout
> the header files, special casing it in this one place seems like it
> will just generate future confusion.
>
> DJ has proposed a generic method for dealing with the windows export
> criteria. I think it will probably supersede this change, assuming
> that it is accepted.
In the port I'm working on, it would be convenient if I could control where
__infinity goes (the problem is ideally I would like __infinity to go in the
small data area, but the library is compiled with -G 0 to reduce the number of
multilibs). At present, I settled for putting __infinity in normal data area,
and used [] to override the compiler's choice of addressing mode. I figured
other ports might run into the same problem with __infinity and _impure_ptr,
the two variables exported by newlib (_impure_ptr already had a method of
adding machine dependent attributes).
--
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: meissner@redhat.com phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482