Re: xlimits.h for embedded targets

Re: xlimits.h for embedded targets

[Christian Iseli]

> Then maybe newlib should be "fixing" gcc's limits.h rather than the other
> way around.

I'll second that.  Some targets will probably not use newlib...

Seems to me that maybe the cleanest way would be to generate a basic
limits.h from the target description file (tm.h).  That's GCC's idea
of the target's limits anyway.  At first glance, this should not be
too hard... (famous last words, I know ;-)

What do you think?

					Christian

Re: xlimits.h for embedded targets

[Joel Sherrill]

On Tue, 14 Oct 1997, Christian Iseli wrote:

> > Then maybe newlib should be "fixing" gcc's limits.h rather than the other
> > way around.
> 
> I'll second that.  Some targets will probably not use newlib...
> 
> Seems to me that maybe the cleanest way would be to generate a basic
> limits.h from the target description file (tm.h).  That's GCC's idea
> of the target's limits anyway.  At first glance, this should not be
> too hard... (famous last words, I know ;-)
> 
> What do you think?

I need to look into this further but it should not be too terribly bad to
have the newlib installed limits.h include the one gcc generates when it
does not see a limits.h.  At that point, it should just be a matter of
getting the include path search order right.  

--joel

Re: xlimits.h for embedded targets

[Joel Sherrill]

On Mon, 13 Oct 1997, Stephen Williams wrote:

> joel@OARcorp.com said:
> > The main problem for embedded targets is that there are headers files 
> > installed until after gcc is built because you need gcc to build the 
> > C library before you build the embedded OS itself.  Chicken and egg 
> > problem as much as anything else.
> 
> 
> Seems to me, from a strictly theoretical point of view, that there are
> parts of the limits.h that are compiler issues. This file is in fact
> introduced by the C standard. This part of limits.h should be entirely
> up to the compiler.

This is true.  gcc recognizes this division and if there is a system
limits.h will do an "#include_next" to get the one for the OS.  it wraps
the OS one with the compiler one in a sense.  The problem with RTEMS is
that there is no OS limits.h installed when gcc looks for it.  This is why
I refer to it as a chicken and egg problem.

> There are other standards, such as POSIX and XOPEN, that add things to
> the limits.h file, but they should be someone else's responsibility, not
> the compiler provider's.

Agreed.

> So, for a cross environment, GCC should provide a limits.h that has all
> the C specific parts. The OS may then extend the limits.h providing its
> own limits.h that only has POSIX/xopen/whatever specific stuff and using
> include_next to get the compiler specific stuff. I don't see how the compiler
> should care one wit what the POSIX parts of limits.h are.

Then maybe newlib should be "fixing" gcc's limits.h rather than the other
way around.  

> In uCR I have not trouble at all with limits.h. (Of course, I don't do the
> POSIX thing, either:-) Systems where gcc is the native compiler should have
> no trouble with it.

We had no trouble with limits.h until we got to POSIX support either. :)

> Could it be that the trouble you are having is with the C library you are
> using?

Could be.  I don't care how it is addressed.  I just don't see a clean
solution for a system in which the OS's limits.h is installed after
the compiler.  I don't remember any real general solutions being offered.

As an aside, I am not as concerned about this issue as it might seem based
on how many times I have griped about it on the egcs list.  Honestly rtems
gdb support is much more important to me. :)

--joel

Re: xlimits.h for embedded targets

[Joel Sherrill]

> This may be the problem. What in linits.h does gcc care about, other
> then those values it provides?

Nothing that I know of.

> This hack probably exists to allow gcc to be installed in places where the
> O/S limits.h header file is off limits, i.e. supplied by another compiler.
> We should be doing it THE OTHER WAY AROUND for cross targets: it is the
> O/S limits.h that should include_next the gcc limits.h. n'est pas? You as
> the RTEMS author have control over this. Make your limits.h include_next
> the compiler's limits.h, and make sure that gcc does *not* find it:-)
> 
> joel@OARcorp.com said:
> > Then maybe newlib should be "fixing" gcc's limits.h rather than the 
> > other way around.   
> 
> Yes! I think so. Makes sense to me, no?

I think this is a workable solution.  I will have to look at the
installation procedure as well as the search order to make sure this will
work but fundamentally this is the only way this can be made to work if
you install your limits.h after gcc has done its own.

--joel

Re: xlimits.h for embedded targets

[Stephen Williams]

> Seems to me, from a strictly theoretical point of view, that there are
> parts of the limits.h that are compiler issues. This file is in fact
> introduced by the C standard. This part of limits.h should be entirely
> up to the compiler.


joel@OARcorp.com said:
> This is true.  gcc recognizes this division and if there is a system 
> limits.h will do an "#include_next" to get the one for the OS.  it 
> wraps the OS one with the compiler one in a sense.  The problem with 
> RTEMS is that there is no OS limits.h installed when gcc looks for it.

This may be the problem. What in linits.h does gcc care about, other
then those values it provides?

This hack probably exists to allow gcc to be installed in places where the
O/S limits.h header file is off limits, i.e. supplied by another compiler.
We should be doing it THE OTHER WAY AROUND for cross targets: it is the
O/S limits.h that should include_next the gcc limits.h. n'est pas? You as
the RTEMS author have control over this. Make your limits.h include_next
the compiler's limits.h, and make sure that gcc does *not* find it:-)

joel@OARcorp.com said:
> Then maybe newlib should be "fixing" gcc's limits.h rather than the 
> other way around.   

Yes! I think so. Makes sense to me, no?

-- 
Steve Williams
steve@icarus.com
steve@picturel.com

"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

Re: xlimits.h for embedded targets

[Stephen Williams]

joel@OARcorp.com said:
> The main problem for embedded targets is that there are headers files 
> installed until after gcc is built because you need gcc to build the 
> C library before you build the embedded OS itself.  Chicken and egg 
> problem as much as anything else.


Seems to me, from a strictly theoretical point of view, that there are
parts of the limits.h that are compiler issues. This file is in fact
introduced by the C standard. This part of limits.h should be entirely
up to the compiler.

There are other standards, such as POSIX and XOPEN, that add things to
the limits.h file, but they should be someone else's responsibility, not
the compiler provider's.

So, for a cross environment, GCC should provide a limits.h that has all
the C specific parts. The OS may then extend the limits.h providing its
own limits.h that only has POSIX/xopen/whatever specific stuff and using
include_next to get the compiler specific stuff. I don't see how the compiler
should care one wit what the POSIX parts of limits.h are.

In uCR I have not trouble at all with limits.h. (Of course, I don't do the
POSIX thing, either:-) Systems where gcc is the native compiler should have
no trouble with it.

Could it be that the trouble you are having is with the C library you are
using?

-- 
Steve Williams
steve@icarus.com
steve@picturel.com

"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

Re: xlimits.h for embedded targets

[Joel Sherrill]

On Thu, 9 Oct 1997, Richard Henderson wrote:

> On Thu, Oct 09, 1997 at 07:49:27AM -0500, Joel Sherrill wrote:
> > The RTEMS limits.h file is technically dependent on the OS version.  In
> > practice, it doesn't change very often but it includes some limits from
> > the threads and real-time extensions
> 
> FWIW, in glibc we handle this by having several smaller private
> header files that are all included by the "main" limits.h.  And
> the same with quite a number of other headers as well.

The main problem for embedded targets is that there are headers files
installed until after gcc is built because you need gcc to build the C
library before you build the embedded OS itself.  Chicken and egg problem
as much as anything else.

The current "#include_next" in gcc works fine with RTEMS if you force it
to regenerate the limits.h after the C library is installed. :)

--joel

Re: xlimits.h for embedded targets

[Richard Henderson]

On Thu, Oct 09, 1997 at 07:49:27AM -0500, Joel Sherrill wrote:
> The RTEMS limits.h file is technically dependent on the OS version.  In
> practice, it doesn't change very often but it includes some limits from
> the threads and real-time extensions

FWIW, in glibc we handle this by having several smaller private
header files that are all included by the "main" limits.h.  And
the same with quite a number of other headers as well.

Just a thought...


r~

Re: xlimits.h for embedded targets

[Joel Sherrill]

On Wed, 8 Oct 1997, Jeffrey A Law wrote:

>   In message <Pine.BSF.3.96.970923085411.19118I-100000@vespucci.advicom.net>you  write:
> 
>   > On Tue, 23 Sep 1997, Christian Iseli wrote:
>   > > The impact is that the proposed change lets the target file t-target
>   > > overide the way limits.h is constructed.  For example, my target file
>   > > t-c816 defines it as
>   > > 
>   > > # Target specific header files
>   > > LIMITS_H = limits-c816.h
>   > > 
>   > > limits-c816.h: $(srcdir)/config/c816/limits-c816.h msc816.inc
>   > > 	cp $(srcdir)/config/c816/limits-c816.h limits-c816.h
> Well, I'd prefer to see this work more like FLOAT_H/CROSS_FLOAT_H, which
> should give you the same basic functionality.  Why invent two completely
> different mechanisms to solve the same basic problem.

The RTEMS limits.h file is technically dependent on the OS version.  In
practice, it doesn't change very often but it includes some limits from
the threads and real-time extensions

>   > Joel Sherrill wrote:
>   > Building RTEMS has a similar problem.  For lack of a better thing to do, I
>   > put our limits.h in newlib (C library) which is not built until after the
>   > compiler is built.  This solution would have allowed me to put the rtems
>   > limits.h file in the gcc source tree and it would be available when
>   > required during the build.
> This alternative is pretty simple too -- gcc looks for a suitable limits.h
> in the target include area $(SYSTEM_HEADER_DIR)/limits.h and puts some
> wrappers around it if it exists.

This is why I remove the one generated on the first pass and let gcc
reinstall the one built with the wrapper.  

>   > This does not solve the more general problem that some of the
>   > runtimes require a C library.  But this is a larger problem.
> Yup.  We just have to keep chipping away.

And things are slowly getting better.

I think that if the generation limits.h, libgcc.a, and other target
dependent libraries were put in their own subdirectoriies with their own
Makefiles, then the top level make could just arrange to do things in the
right order.  It might require splitting the headers and bodies of a C
library into 2 pieces so the .h's would be available at the right time but
that is about it.  I think it is more of a reorganization than anything
else. 

This one will just take time to settle out.

--joel

Re: xlimits.h for embedded targets

[Jeffrey A Law]

  In message <Pine.BSF.3.96.970923085411.19118I-100000@vespucci.advicom.net>you  write:

  > On Tue, 23 Sep 1997, Christian Iseli wrote:
  > > The impact is that the proposed change lets the target file t-target
  > > overide the way limits.h is constructed.  For example, my target file
  > > t-c816 defines it as
  > > 
  > > # Target specific header files
  > > LIMITS_H = limits-c816.h
  > > 
  > > limits-c816.h: $(srcdir)/config/c816/limits-c816.h msc816.inc
  > > 	cp $(srcdir)/config/c816/limits-c816.h limits-c816.h
Well, I'd prefer to see this work more like FLOAT_H/CROSS_FLOAT_H, which
should give you the same basic functionality.  Why invent two completely
different mechanisms to solve the same basic problem.

  > Joel Sherrill wrote:
  > Building RTEMS has a similar problem.  For lack of a better thing to do, I
  > put our limits.h in newlib (C library) which is not built until after the
  > compiler is built.  This solution would have allowed me to put the rtems
  > limits.h file in the gcc source tree and it would be available when
  > required during the build.
This alternative is pretty simple too -- gcc looks for a suitable limits.h
in the target include area $(SYSTEM_HEADER_DIR)/limits.h and puts some
wrappers around it if it exists.

  > This does not solve the more general problem that some of the
  > runtimes require a C library.  But this is a larger problem.
Yup.  We just have to keep chipping away.

Jeff

Re: xlimits.h for embedded targets

[Joel Sherrill]

On Tue, 23 Sep 1997, Christian Iseli wrote:

> > Is this just a procedural change with no real impact on when the file is
> > built or the contents of the resulting file? 
> 
> The impact is that the proposed change lets the target file t-target overide the way
> limits.h is constructed.  For example, my target file t-c816 defines it as
> 
> # Target specific header files
> LIMITS_H = limits-c816.h
> 
> limits-c816.h: $(srcdir)/config/c816/limits-c816.h msc816.inc
> 	cp $(srcdir)/config/c816/limits-c816.h limits-c816.h
> 
> Thus the file will be "constructed" before it is needed by msc816.inc, which is a file
> containing some assembler macros, which is needed when the compiler driver assembles
> some cc1 output.

Building RTEMS has a similar problem.  For lack of a better thing to do, I
put our limits.h in newlib (C library) which is not built until after the
compiler is built.  This solution would have allowed me to put the rtems
limits.h file in the gcc source tree and it would be available when
required during the build.

This does not solve the more general problem that some of the
runtimes require a C library.  But this is a larger problem.

What do you guys think of the proposed solution?  Every system which
system which has a limits.h problem would end up with a limits.h in the
gcc source tree.  I would have to move the rtems specific limits.h file
from newlib to gcc/config/limits-rtems.h since the file is the same for
all rtems targets.

--joel
Joel Sherrill                    Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985

Re: xlimits.h for embedded targets

[Christian Iseli]

> Is this just a procedural change with no real impact on when the file is
> built or the contents of the resulting file? 

The impact is that the proposed change lets the target file t-target overide the way
limits.h is constructed.  For example, my target file t-c816 defines it as

# Target specific header files
LIMITS_H = limits-c816.h

limits-c816.h: $(srcdir)/config/c816/limits-c816.h msc816.inc
	cp $(srcdir)/config/c816/limits-c816.h limits-c816.h

Thus the file will be "constructed" before it is needed by msc816.inc, which is a file
containing some assembler macros, which is needed when the compiler driver assembles
some cc1 output.

					Christian

Re: xlimits.h for embedded targets

[Joel Sherrill]

On Tue, 23 Sep 1997, Christian Iseli wrote:

> Hi folks,
> (or I didn't understand it correctly... ;-)
> 
> So I would like to suggest that the limits.h stuff be specified in a similar way that
> the float.h stuff is specified.  This can be done easily through the following patch
> to Makefile.in:

Is this just a procedural change with no real impact on when the file is
built or the contents of the resulting file? 

--joel (who periodically gripes about when limits.h and libgcc are built.:)

Joel Sherrill                    Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985

xlimits.h for embedded targets

[Christian Iseli]

Hi folks,

It seems to me that the way to generate the xlimits.h file is not quite general enough
(or I didn't understand it correctly... ;-)

So I would like to suggest that the limits.h stuff be specified in a similar way that
the float.h stuff is specified.  This can be done easily through the following patch
to Makefile.in:

  Tue Sep 23 13:39:44 1997  Christian Iseli  <Christian.Iseli@lslsun.epfl.ch>

	* Makefile.in: define LIMITS_H similarly to FLOAT_H.


*** Makefile.in.orig	Fri Sep 12 15:53:00 1997
--- Makefile.in	Fri Sep 12 16:02:58 1997
*************** all.cross: native gcc-cross specs stmp-h
*** 717,723 ****
  # This is what to compile if making gcc with a cross-compiler.
  all.build: native xgcc $(EXTRA_PARTS) lang.all.build
  # This is what must be made before installing GCC and converting libraries.
! start.encap: native xgcc specs $(LIBGCC1) xlimits.h lang.start.encap
  # These can't be made until after GCC can run.
  rest.encap: stmp-headers $(LIBGCC) $(STMP_FIXPROTO) $(EXTRA_PARTS) lang.rest.encap
  # This is what is made with the host's compiler
--- 721,727 ----
  # This is what to compile if making gcc with a cross-compiler.
  all.build: native xgcc $(EXTRA_PARTS) lang.all.build
  # This is what must be made before installing GCC and converting libraries.
! start.encap: native xgcc specs $(LIBGCC1) $(LIMITS_H) lang.start.encap
  # These can't be made until after GCC can run.
  rest.encap: stmp-headers $(LIBGCC) $(STMP_FIXPROTO) $(EXTRA_PARTS) lang.rest.encap
  # This is what is made with the host's compiler
*************** gcov: gcov.o $(LIBDEPS)
*** 1854,1860 ****
  
  # Build the include directory except for float.h (which depends upon
  # enquire).
! stmp-int-hdrs: stmp-fixinc $(USER_H) xlimits.h
  # Copy in the headers provided with gcc.
  # The sed command gets just the last file name component;
  # this is necessary because VPATH could add a dirname.
--- 1858,1864 ----
  
  # Build the include directory except for float.h (which depends upon
  # enquire).
! stmp-int-hdrs: stmp-fixinc $(USER_H) $(LIMITS_H)
  # Copy in the headers provided with gcc.
  # The sed command gets just the last file name component;
  # this is necessary because VPATH could add a dirname.
*************** stmp-int-hdrs: stmp-fixinc $(USER_H) xli
*** 1868,1874 ****
  	  fi; \
  	done
  	rm -f include/limits.h
! 	cp xlimits.h include/limits.h
  	chmod a+r include/limits.h
  # Install the README
  	rm -f include/README
--- 1872,1878 ----
  	  fi; \
  	done
  	rm -f include/limits.h
! 	cp $(LIMITS_H) include/limits.h
  	chmod a+r include/limits.h
  # Install the README
  	rm -f include/README
*************** mostlyclean: bytecode.mostlyclean lang.m
*** 2019,2025 ****
  	-rm -f $(HOST_PREFIX_1)alloca.c $(HOST_PREFIX_1)malloc.c
  	-rm -f $(HOST_PREFIX_1)obstack.c 
  # Delete the temp files made in the course of building libgcc.a.
! 	-rm -f tmplibgcc* tmpcopy xlimits.h libgcc1-test
  	for name in $(LIB1FUNCS); do rm -f $${name}.c; done
  # Delete other temporary files.
  	-rm -f tmp-float.h tmp-gcc.xtar.gz
--- 2023,2029 ----
  	-rm -f $(HOST_PREFIX_1)alloca.c $(HOST_PREFIX_1)malloc.c
  	-rm -f $(HOST_PREFIX_1)obstack.c 
  # Delete the temp files made in the course of building libgcc.a.
! 	-rm -f tmplibgcc* tmpcopy $(LIMITS_H) libgcc1-test
  	for name in $(LIB1FUNCS); do rm -f $${name}.c; done
  # Delete other temporary files.
  	-rm -f tmp-float.h tmp-gcc.xtar.gz