gcc include strangeness

gcc include strangeness

[Florian Lohoff]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]


Hi,
i just stumbled when i tried to compile a program (bootloader) with
gcc which uses varargs. I got the error that "sgidefs.h" was missing.
sgidefs.h is contained in the glibc which gets included by va-mips.h
from stdarg.h - I dont think this is correct as i should be able
to compile programs without glibc.

Shouldnt sgidefs.h or its content be included in the gcc ?

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: gcc include strangeness

[Ralf Baechle]

On Sat, Feb 09, 2002 at 04:01:55PM +0100, Florian Lohoff wrote:

> i just stumbled when i tried to compile a program (bootloader) with
> gcc which uses varargs. I got the error that "sgidefs.h" was missing.
> sgidefs.h is contained in the glibc which gets included by va-mips.h
> from stdarg.h - I dont think this is correct as i should be able
> to compile programs without glibc.
> 
> Shouldnt sgidefs.h or its content be included in the gcc ?

There should be a copy of sgidefs.h in /usr/include rsp. for crosscompilers
in <prefix>/<target>/include/sgidefs.h.  However the gcc varargs stuff
has been rewritten completely; the new implementation does no longer try
to include sgidefs.h.

 Ralf

Re: gcc include strangeness

[Maciej W. Rozycki]

On Sat, 9 Feb 2002, Florian Lohoff wrote:

> i just stumbled when i tried to compile a program (bootloader) with
> gcc which uses varargs. I got the error that "sgidefs.h" was missing.
> sgidefs.h is contained in the glibc which gets included by va-mips.h
> from stdarg.h - I dont think this is correct as i should be able
> to compile programs without glibc.

 Hmm, in 2.95.3 in va-mips.h I see: 

/* Get definitions for _MIPS_SIM_ABI64 etc.  */
#ifdef _MIPS_SIM
#include <sgidefs.h>
#endif

so you shouldn't need sgidefs.h normally.  Or did something get broken for
3.x?

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: gcc include strangeness

[Florian Lohoff]

[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]

On Mon, Feb 11, 2002 at 01:51:47PM +0100, Maciej W. Rozycki wrote:
> On Sat, 9 Feb 2002, Florian Lohoff wrote:
> 
> > i just stumbled when i tried to compile a program (bootloader) with
> > gcc which uses varargs. I got the error that "sgidefs.h" was missing.
> > sgidefs.h is contained in the glibc which gets included by va-mips.h
> > from stdarg.h - I dont think this is correct as i should be able
> > to compile programs without glibc.
> 
>  Hmm, in 2.95.3 in va-mips.h I see: 
> 
> /* Get definitions for _MIPS_SIM_ABI64 etc.  */
> #ifdef _MIPS_SIM
> #include <sgidefs.h>
> #endif
> 
> so you shouldn't need sgidefs.h normally.  Or did something get broken for
> 3.x?

revamp:/tmp/arcboot-0.2# make
cd arclib; make all
make[1]: Entering directory `/tmp/arcboot-0.2/arclib'
cc -O -Werror -Wall -mno-abicalls -G 0 -fno-pic    -c -o arc.o arc.c
cc -O -Werror -Wall -mno-abicalls -G 0 -fno-pic    -c -o stdio.o stdio.c
In file included from
/usr/lib/gcc-lib/mips-linux/2.95.4/include/stdarg.h:27,
                 from stdio.h:8,
                 from stdio.c:7:
/usr/lib/gcc-lib/mips-linux/2.95.4/include/va-mips.h:89: sgidefs.h: No
such file or directory
make[1]: *** [stdio.o] Error 1
make[1]: Leaving directory `/tmp/arcboot-0.2/arclib'
make: *** [all] Error 2

revamp:/tmp/arcboot-0.2# gcc -v
Reading specs from /usr/lib/gcc-lib/mips-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)

revamp:/tmp/arcboot-0.2# vi /usr/lib/gcc-lib/mips-linux/2.95.4/include/va-mips.h
[...]
     87 /* Get definitions for _MIPS_SIM_ABI64 etc.  */
     88 #ifdef _MIPS_SIM
     89 #include <sgidefs.h>
     90 #endif
[...]

I just saw it - I cant explain it ...

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: gcc include strangeness

[Maciej W. Rozycki]

On Mon, 11 Feb 2002, Florian Lohoff wrote:

> I just saw it - I cant explain it ...

 Hmm, it's "subtarget_cpp_spec" in gcc's specs that defines _MIPS_SIM.  It
seems <sgidefs.h> should be a part of gcc indeed.  It would let avoiding
including the weird asm-mips/gcc/sgidefs.h header for the kernel as well. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: gcc include strangeness

[Johannes Stezenbach]

On Mon, Feb 11, 2002 at 02:53:02PM +0100, Florian Lohoff wrote:
> On Mon, Feb 11, 2002 at 01:51:47PM +0100, Maciej W. Rozycki wrote:
> > On Sat, 9 Feb 2002, Florian Lohoff wrote:
> > 
> > > i just stumbled when i tried to compile a program (bootloader) with
> > > gcc which uses varargs. I got the error that "sgidefs.h" was missing.
> > > sgidefs.h is contained in the glibc which gets included by va-mips.h
> > > from stdarg.h - I dont think this is correct as i should be able
> > > to compile programs without glibc.

The glibc-2.2.5/FAQ says:
  1.20.   Which tools should I use for MIPS?

  {AJ} You should use the current development version of gcc 3.0 or newer from
  CVS.  gcc 2.95.x does not work correctly on mips-linux.

I'm not shure if this only applies to glibc, but the
gcc-2.95.x I tried to build could not even compile a kernel
because of:
  #ifndef __linux__
  #error Use a Linux compiler or give up.
  #endif
in linux/include/asm-mips/sgidefs.h. The gcc-3.0.3 I now use
has a totally different set of predefines than gcc-2.95.x, and
it seems to work.


> >  Hmm, in 2.95.3 in va-mips.h I see: 
> > 
> > /* Get definitions for _MIPS_SIM_ABI64 etc.  */
> > #ifdef _MIPS_SIM
> > #include <sgidefs.h>
> > #endif
> > 
> > so you shouldn't need sgidefs.h normally.  Or did something get broken for
> > 3.x?

sgidefs.h comes from the kernel includes.

gcc-3.x does not use va-mips.h or sgidefs,h, but simply
has the following in stdarg.h:
  #define va_start(v,l)   __builtin_stdarg_start((v),l)
  #define va_end          __builtin_va_end
  #define va_arg          __builtin_va_arg
etc.


Regards,
Johannes

Re: gcc include strangeness

[Maciej W. Rozycki]

On Mon, 11 Feb 2002, Johannes Stezenbach wrote:

> The glibc-2.2.5/FAQ says:
>   1.20.   Which tools should I use for MIPS?
> 
>   {AJ} You should use the current development version of gcc 3.0 or newer from
>   CVS.  gcc 2.95.x does not work correctly on mips-linux.

 Is gcc 3.x already stable enough to be used by people not directly
involved in gcc development?  More specifically for MIPS/Linux and
i386/Linux, for both the kernel and the userland?  I'm told it is not.

> I'm not shure if this only applies to glibc, but the
> gcc-2.95.x I tried to build could not even compile a kernel
> because of:
>   #ifndef __linux__
>   #error Use a Linux compiler or give up.
>   #endif
> in linux/include/asm-mips/sgidefs.h. The gcc-3.0.3 I now use
> has a totally different set of predefines than gcc-2.95.x, and
> it seems to work.

 Gcc 2.95.x as distributed certainly doesn't work.  With a set of patches
it appears rock solid.  For MIPS/Linux I'm using it for over two years for
both the kernel and the userland.  The last time I found bug and needed to
apply a fix to gcc 2.95.3 for MIPS/Linux was in April 2001. 

 With gcc 2.95.3 if I spot a weird behaviour, I'm pretty confident it's a
bug in the kernel or in user code, and not the compiler generating bad
code.

> gcc-3.x does not use va-mips.h or sgidefs,h, but simply
> has the following in stdarg.h:
>   #define va_start(v,l)   __builtin_stdarg_start((v),l)
>   #define va_end          __builtin_va_end
>   #define va_arg          __builtin_va_arg
> etc.

 Thanks for the info.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: gcc include strangeness

[Florian Lohoff]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

On Mon, Feb 11, 2002 at 03:27:08PM +0100, Johannes Stezenbach wrote:
> 
> The glibc-2.2.5/FAQ says:
>   1.20.   Which tools should I use for MIPS?
> 
>   {AJ} You should use the current development version of gcc 3.0 or newer from
>   CVS.  gcc 2.95.x does not work correctly on mips-linux.
> 

Its not about gcc development but rather keeping a distribution in
sync. All Debian archs try to use the same compiler which is currently
2.95.4 which we are happy with right now - Except some minor issues
breaking 2-3 Packages ...

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: gcc include strangeness

[Johannes Stezenbach]

On Mon, Feb 11, 2002 at 04:10:34PM +0100, Maciej W. Rozycki wrote:
> 
>  Is gcc 3.x already stable enough to be used by people not directly
> involved in gcc development?  More specifically for MIPS/Linux and
> i386/Linux, for both the kernel and the userland?  I'm told it is not.

I'm reading about gcc 3.x code generation bugs every now and then,
but so far I did not hit any of them.
I would prefer gcc 2.95.x though, if I only could get it
to work on MIPS.

>  Gcc 2.95.x as distributed certainly doesn't work.  With a set of patches
> it appears rock solid.  For MIPS/Linux I'm using it for over two years for
> both the kernel and the userland.  The last time I found bug and needed to
> apply a fix to gcc 2.95.3 for MIPS/Linux was in April 2001. 

I would certainly be interested in getting my hands on those
patches. Do you mind if I ask why they did not go into
gcc-2_95-branch CVS?


Regards,
Johannes

Re: gcc include strangeness

[Johannes Stezenbach]

On Mon, Feb 11, 2002 at 04:37:32PM +0100, Florian Lohoff wrote:
> On Mon, Feb 11, 2002 at 03:27:08PM +0100, Johannes Stezenbach wrote:
> > 
> > The glibc-2.2.5/FAQ says:
> >   1.20.   Which tools should I use for MIPS?
> > 
> >   {AJ} You should use the current development version of gcc 3.0 or newer from
> >   CVS.  gcc 2.95.x does not work correctly on mips-linux.
> > 
> 
> Its not about gcc development but rather keeping a distribution in
> sync. All Debian archs try to use the same compiler which is currently
> 2.95.4 which we are happy with right now - Except some minor issues
> breaking 2-3 Packages ...

So does this mean that Debian's gcc 2.95.4 works on MIPS?
Does it include patches which are not in CVS (gcc-2_95-branch)?


Regards,
Johannes

Re: gcc include strangeness

[Maciej W. Rozycki]

On Mon, 11 Feb 2002, Johannes Stezenbach wrote:

> I would certainly be interested in getting my hands on those
> patches. Do you mind if I ask why they did not go into
> gcc-2_95-branch CVS?

 RPM packages are available at my site --
"ftp://ftp.ds2.pg.gda.pl/pub/macro/".  They used to be recommended tools
for glibc 2.2 for MIPS/Linux before gcc 3.0 was released. 

 As to why they did not go into the CVS?  Well, I wasn't aware gcc 2.95.x
was maintained until after 2.95.3 was released (but patches that were
relevant either went in to 2.96 or were rejected).  And now we have 3.x.

 If 2.95.x is still maintained and you feel the patches would be useful
for inclusion, feel free to commit them.  The change log in the spec file
contains descriptions of the purpose of every patch. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: gcc include strangeness

[Guido Guenther]

On Mon, Feb 11, 2002 at 05:53:25PM +0100, Johannes Stezenbach wrote:
> On Mon, Feb 11, 2002 at 04:37:32PM +0100, Florian Lohoff wrote:
> > On Mon, Feb 11, 2002 at 03:27:08PM +0100, Johannes Stezenbach wrote:
> > > 
> > > The glibc-2.2.5/FAQ says:
> > >   1.20.   Which tools should I use for MIPS?
> > > 
> > >   {AJ} You should use the current development version of gcc 3.0 or newer from
> > >   CVS.  gcc 2.95.x does not work correctly on mips-linux.
> > > 
> > 
> > Its not about gcc development but rather keeping a distribution in
> > sync. All Debian archs try to use the same compiler which is currently
> > 2.95.4 which we are happy with right now - Except some minor issues
> > breaking 2-3 Packages ...
> 
> So does this mean that Debian's gcc 2.95.4 works on MIPS?
The whole distribution is compiled with 2.95.4.

> Does it include patches which are not in CVS (gcc-2_95-branch)?
Yes. See the debian/patches directory after unpacking the
source-package.
 -- Guido

Re: gcc include strangeness

[Ralf Baechle]

On Mon, Feb 11, 2002 at 01:51:47PM +0100, Maciej W. Rozycki wrote:

> > i just stumbled when i tried to compile a program (bootloader) with
> > gcc which uses varargs. I got the error that "sgidefs.h" was missing.
> > sgidefs.h is contained in the glibc which gets included by va-mips.h
> > from stdarg.h - I dont think this is correct as i should be able
> > to compile programs without glibc.
> 
>  Hmm, in 2.95.3 in va-mips.h I see: 
> 
> /* Get definitions for _MIPS_SIM_ABI64 etc.  */
> #ifdef _MIPS_SIM
> #include <sgidefs.h>
> #endif
> 
> so you shouldn't need sgidefs.h normally.  Or did something get broken for
> 3.x?

Gcc is supposed to define _MIPS_SIM.

  Ralf

Re: gcc include strangeness

[Ralf Baechle]

On Mon, Feb 11, 2002 at 04:10:34PM +0100, Maciej W. Rozycki wrote:

>  Is gcc 3.x already stable enough to be used by people not directly
> involved in gcc development?  More specifically for MIPS/Linux and
> i386/Linux, for both the kernel and the userland?  I'm told it is not.

>From the reports I'm gathering that we should ignore 3.0 and directly
go for 3.1.

  Ralf

Re: gcc include strangeness

[Ralf Baechle]

On Mon, Feb 11, 2002 at 04:10:34PM +0100, Maciej W. Rozycki wrote:

>  Is gcc 3.x already stable enough to be used by people not directly
> involved in gcc development?  More specifically for MIPS/Linux and
> i386/Linux, for both the kernel and the userland?  I'm told it is not.

From the reports I'm gathering that we should ignore 3.0 and directly
go for 3.1.

  Ralf

Re: gcc include strangeness

[Ralf Baechle]

On Mon, Feb 11, 2002 at 05:28:44PM +0100, Johannes Stezenbach wrote:

> >  Is gcc 3.x already stable enough to be used by people not directly
> > involved in gcc development?  More specifically for MIPS/Linux and
> > i386/Linux, for both the kernel and the userland?  I'm told it is not.
> 
> I'm reading about gcc 3.x code generation bugs every now and then,
> but so far I did not hit any of them.

I've fixed several kernel bugs that got triggered by building with 3.0.
We've got an a piece of inline assembler where a constraint gets ignored
by 3.0 resulting in bad code.  Add slow compilation and slow code.  3.0?
No way.  Yet.

  Ralf

Re: gcc include strangeness

[Maciej W. Rozycki]

On Sun, 10 Feb 2002, Ralf Baechle wrote:

> > Shouldnt sgidefs.h or its content be included in the gcc ?
> 
> There should be a copy of sgidefs.h in /usr/include rsp. for crosscompilers
> in <prefix>/<target>/include/sgidefs.h.  However the gcc varargs stuff

 That file is part of libc, not gcc.  OTOH, gcc when configured for
"mipsel-linux" is allowed to assume glibc is available.  So there is no
need to migrate the file after all.

> has been rewritten completely; the new implementation does no longer try
> to include sgidefs.h.

 That's fine but for 2.95.x the issue exists.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: gcc include strangeness

[Dominic Sweetman]

I've been keeping quiet through all this, but perhaps I should speak
up.

Algorithmics maintains a GNU toolchain for embedded systems and
supplies it bundled with support and a basic run-time system as our
product SDE-MIPS.

>From version 5.0 (just gone into beta) we are configuring and testing
the compiler/assembler/object tools for Linux use.  We always publish
the GNU sources used to build SDE-MIPS on our web-site, but we are
currently leaning towards going further and putting binary RPMs of the
Linux toolchain out for free download - so those of you who want can
just use it.

The upside of this is that we have the resource and skill (and it
looks like we'll be able to get enough support/development funding) to
maintain a Linux/MIPS compiler.  It would be a good thing for the
Linux/MIPS community if compiler bugs and shortcomings got fixed on a
fairly stable base, instead of relying on pick-your-version folklore.
We should also be able to get funding to do things like fixing support
for SGI n32/n64 code-generation conventions.

Our compiler already has support for pretty much every wrinkle
of any MIPS instruction set anywhere, and command-line-selectable
machine descriptions for many different MIPS pipelines.

The downside: our development process is not currently very
Linux-shaped.  We "release late, release rarely".  In providing a
stable compiler for embedded use we have found it easier to avoid the
bleeding edge of GCC.  We've found it necessary to make bold changes
in "machine-independent" code - GCC is a wonderful multi-target
compiler, but it's x86 (PPC a distant second) which is routinely
tested.  The leading edge is a fertile breeding ground of bugs for
minor architectures.

And more: our v5.0 compiler's ancestor was a 2.96 release from Cygnus'
internal development tree, provided to MIPS Technologies in the fall
of 2000.  We picked it up because it had work MIPS had already funded,
and some valuable multiple-issue machine description features which
didn't make it into 3.0.  But it has taken a long time to make sure
the new compiler is as well-tuned and reliable as the EGCS 1.1-based
compiler it replaced, and the 2.96-derived compiler is only now
shipping as part of a beta release.

So now we have numerous patches, many of them not in officially "MIPS
machine-dependent" code, against an 18-months old and slightly strange
version of GCC.  Nobody is currently doing the substantial work to
turn our changes into patches for GCC 3.x.

What I think we ought to do is to:

o Release the existing compiler for use among Linux/MIPS enthusiasts
  (we're hoping that some commercial developers will take support
  contracts, of course);

o Hope that many of you will use it and feed back bug reports, and
  that some of you will grab the sources and help track & fix them;

o Aim to make earlier and more frequent releases for adventurous Linux
  users (we will keep a slow-moving 'stable' release for those whose
  priority is elsewhere);

o Aim over the next couple of years - and with all the help we can get
  - to converge closer to the evolving GCC 3.x mainstream.

I guess the question for this list is: is anyone interested?

--
Dominic Sweetman
Algorithmics Ltd
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205
http://www.algor.co.uk

Re: gcc include strangeness

[Dominic Sweetman]

I've been keeping quiet through all this, but perhaps I should speak
up.

Algorithmics maintains a GNU toolchain for embedded systems and
supplies it bundled with support and a basic run-time system as our
product SDE-MIPS.

From version 5.0 (just gone into beta) we are configuring and testing
the compiler/assembler/object tools for Linux use.  We always publish
the GNU sources used to build SDE-MIPS on our web-site, but we are
currently leaning towards going further and putting binary RPMs of the
Linux toolchain out for free download - so those of you who want can
just use it.

The upside of this is that we have the resource and skill (and it
looks like we'll be able to get enough support/development funding) to
maintain a Linux/MIPS compiler.  It would be a good thing for the
Linux/MIPS community if compiler bugs and shortcomings got fixed on a
fairly stable base, instead of relying on pick-your-version folklore.
We should also be able to get funding to do things like fixing support
for SGI n32/n64 code-generation conventions.

Our compiler already has support for pretty much every wrinkle
of any MIPS instruction set anywhere, and command-line-selectable
machine descriptions for many different MIPS pipelines.

The downside: our development process is not currently very
Linux-shaped.  We "release late, release rarely".  In providing a
stable compiler for embedded use we have found it easier to avoid the
bleeding edge of GCC.  We've found it necessary to make bold changes
in "machine-independent" code - GCC is a wonderful multi-target
compiler, but it's x86 (PPC a distant second) which is routinely
tested.  The leading edge is a fertile breeding ground of bugs for
minor architectures.

And more: our v5.0 compiler's ancestor was a 2.96 release from Cygnus'
internal development tree, provided to MIPS Technologies in the fall
of 2000.  We picked it up because it had work MIPS had already funded,
and some valuable multiple-issue machine description features which
didn't make it into 3.0.  But it has taken a long time to make sure
the new compiler is as well-tuned and reliable as the EGCS 1.1-based
compiler it replaced, and the 2.96-derived compiler is only now
shipping as part of a beta release.

So now we have numerous patches, many of them not in officially "MIPS
machine-dependent" code, against an 18-months old and slightly strange
version of GCC.  Nobody is currently doing the substantial work to
turn our changes into patches for GCC 3.x.

What I think we ought to do is to:

o Release the existing compiler for use among Linux/MIPS enthusiasts
  (we're hoping that some commercial developers will take support
  contracts, of course);

o Hope that many of you will use it and feed back bug reports, and
  that some of you will grab the sources and help track & fix them;

o Aim to make earlier and more frequent releases for adventurous Linux
  users (we will keep a slow-moving 'stable' release for those whose
  priority is elsewhere);

o Aim over the next couple of years - and with all the help we can get
  - to converge closer to the evolving GCC 3.x mainstream.

I guess the question for this list is: is anyone interested?

--
Dominic Sweetman
Algorithmics Ltd
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205
http://www.algor.co.uk

Re: gcc include strangeness

[Brian Murphy]

> I guess the question for this list is: is anyone interested?
> 
Yes.

/Brian

Re: gcc include strangeness

[Timothy Daly]

> I guess the question for this list is: is anyone interested?

Hai!



(yes)

-Tim



__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com