gcc problems

gcc problems

[Andrew Morton]

gcc-3.3.2/ia64 is falling over here with my current tree so I'm trying to
build gcc-3.4 from current gcc CVS.

But gcc is failing to compile:

../../gcc-3.4-cvs/gcc/config/ia64/unwind-ia64.c: In function `uw_frame_state_for':
../../gcc-3.4-cvs/gcc/config/ia64/unwind-ia64.c:1779: error: structure has no member named `sc_rbs_base'
../../gcc-3.4-cvs/gcc/config/ia64/unwind-ia64.c:1779: error: structure has no member named `sc_loadrs'
../../gcc-3.4-cvs/gcc/config/ia64/unwind-ia64.c: In function `uw_update_context':
../../gcc-3.4-cvs/gcc/config/ia64/unwind-ia64.c:2013: error: structure has no member named `sc_rbs_base'
../../gcc-3.4-cvs/gcc/config/ia64/unwind-ia64.c:2013: error: structure has no member named `sc_loadrs'

I configured gcc with

../gcc-3.4-cvs/configure --disable-checking --enable-languages=c --prefix=/usr/local/gcc-3.4-cvs

Is there some trick to this?  And what is the preferred gcc version for
ia64 kernels?

Thanks.

Re: gcc problems

[Ian Wienand]

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

On Fri, Feb 06, 2004 at 12:00:58AM -0800, Andrew Morton wrote:
> gcc-3.3.2/ia64 is falling over here with my current tree so I'm trying to
> build gcc-3.4 from current gcc CVS.

That probably shouldn't be happening... It's what we use all the time.
I assume gcc is segfaulting?
 
> Is there some trick to this?  And what is the preferred gcc version for
> ia64 kernels?

Well I don't know exactly about that CVS gcc problem, but something
that may be useful if you use Debian is that there is a little known
'gcc-snapshot' package that is usually quite up to date and saves you
having to build yourself.  See the README.Debian for a sample wrapper.

-i

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

Re: gcc problems

[Andrew Morton]

Ian Wienand <ianw@gelato.unsw.edu.au> wrote:
>
> On Fri, Feb 06, 2004 at 12:00:58AM -0800, Andrew Morton wrote:
> > gcc-3.3.2/ia64 is falling over here with my current tree so I'm trying to
> > build gcc-3.4 from current gcc CVS.
> 
> That probably shouldn't be happening... It's what we use all the time.
> I assume gcc is segfaulting?

I rebuilt and it went away.  It could have been a 2.6 kernel bug ;)

> > Is there some trick to this?  And what is the preferred gcc version for
> > ia64 kernels?
> 
> Well I don't know exactly about that CVS gcc problem, but something
> that may be useful if you use Debian is that there is a little known
> 'gcc-snapshot' package that is usually quite up to date and saves you
> having to build yourself.  See the README.Debian for a sample wrapper.
> 

I would prefer to build gcc direct from the gcc team, really, thanks.

Re: gcc problems

[Jim Wilson]

On Fri, 2004-02-06 at 00:00, Andrew Morton wrote:
> ../../gcc-3.4-cvs/gcc/config/ia64/unwind-ia64.c: In function `uw_frame_state_for':
> ../../gcc-3.4-cvs/gcc/config/ia64/unwind-ia64.c:1779: error: structure has no member named `sc_rbs_base'
> ../../gcc-3.4-cvs/gcc/config/ia64/unwind-ia64.c:1779: error: structure has no member named `sc_loadrs'

This is from the MD_FALLBACK_FRAME_STATE_FOR macro in
gcc/config/ia64/linux.h, which handles machine and OS dependent
unwinding from signal handers.  It uses signal.h and sys/context.h. 
These are things that could have perhaps changed with a new kernel or
glibc.  If the signal context structure has changed, then we need a new
version of this code, and will somehow have to choose the right one.

The easiest workaround is probably to install libunwind on your system
before trying to build gcc.  Then none of this ugly code is needed,
because libunwind gracefully handles it all for us.  Assuming libunwind
builds on the new kernels, but I would be surprised if it didn't.  If
libunwind is installed, then gcc uses it automatically, so you don't
have to configure gcc differently.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: gcc problems

[Andreas Schwab]

Jim Wilson <wilson@specifixinc.com> writes:

> On Fri, 2004-02-06 at 00:00, Andrew Morton wrote:
>> ../../gcc-3.4-cvs/gcc/config/ia64/unwind-ia64.c: In function `uw_frame_state_for':
>> ../../gcc-3.4-cvs/gcc/config/ia64/unwind-ia64.c:1779: error: structure has no member named `sc_rbs_base'
>> ../../gcc-3.4-cvs/gcc/config/ia64/unwind-ia64.c:1779: error: structure has no member named `sc_loadrs'
>
> This is from the MD_FALLBACK_FRAME_STATE_FOR macro in
> gcc/config/ia64/linux.h, which handles machine and OS dependent
> unwinding from signal handers.  It uses signal.h and sys/context.h. 
> These are things that could have perhaps changed with a new kernel or
> glibc.  If the signal context structure has changed, then we need a new
> version of this code, and will somehow have to choose the right one.

The fields were named differently in old versions of glibc, but the whole
layout didn't change in any way.

-  unsigned long int sc_rsvd[16];/* reserved for future use */
+  unsigned long int sc_rbs_base;/* NULL or new base of sighandler's rbs */
+  unsigned long int sc_loadrs;	/* see description above */
+  unsigned long int sc_ar25;	/* cmp8xchg16 uses this */
+  unsigned long int sc_ar26;	/* rsvd for scratch use */
+  unsigned long int sc_rsvd[12];/* reserved for future use */

> The easiest workaround is probably to install libunwind on your system

The right fix is not to use a 2 years old glibc.

revision 1.7
date: 2001/10/01 00:04:10;  author: drepper;  state: Exp;  lines: +3 -1
(struct sigcontext): Add sc_loadrs and sc_rbs_bas to match current kernel.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc problems

[Andrew Morton]

Andreas Schwab <schwab@suse.de> wrote:
>
> The fields were named differently in old versions of glibc, but the whole
>  layout didn't change in any way.
> 
>  -  unsigned long int sc_rsvd[16];/* reserved for future use */
>  +  unsigned long int sc_rbs_base;/* NULL or new base of sighandler's rbs */
>  +  unsigned long int sc_loadrs;	/* see description above */
>  +  unsigned long int sc_ar25;	/* cmp8xchg16 uses this */
>  +  unsigned long int sc_ar26;	/* rsvd for scratch use */
>  +  unsigned long int sc_rsvd[12];/* reserved for future use */
> 
>  > The easiest workaround is probably to install libunwind on your system
> 
>  The right fix is not to use a 2 years old glibc.

That's not very old.  One shouldn't have to upgrade libc just to build gcc?

Re: gcc problems

[Dan Kegel]

Andrew Morton wrote:
> Andreas Schwab <schwab@suse.de> wrote:
> 
>>The fields were named differently in old versions of glibc, but the whole
>> layout didn't change in any way.
>>
>> -  unsigned long int sc_rsvd[16];/* reserved for future use */
>> +  unsigned long int sc_rbs_base;/* NULL or new base of sighandler's rbs */
>> +  unsigned long int sc_loadrs;	/* see description above */
>> +  unsigned long int sc_ar25;	/* cmp8xchg16 uses this */
>> +  unsigned long int sc_ar26;	/* rsvd for scratch use */
>> +  unsigned long int sc_rsvd[12];/* reserved for future use */
>>
>> > The easiest workaround is probably to install libunwind on your system
>>
>> The right fix is not to use a 2 years old glibc.
> 
> 
> That's not very old.  One shouldn't have to upgrade libc just to build gcc?

Did the two-year-old libc really support ia64 well?   I guess Itanium 1 was
out then, but those were early days...
- Dan

RE: gcc problems

[Wichmann, Mats D]

> >> -  unsigned long int sc_rsvd[16];/* reserved for future use */
> >> +  unsigned long int sc_rbs_base;/* NULL or new base of 
> sighandler's rbs */
> >> +  unsigned long int sc_loadrs;	/* see description above */
> >> +  unsigned long int sc_ar25;	/* cmp8xchg16 uses this */
> >> +  unsigned long int sc_ar26;	/* rsvd for scratch use */
> >> +  unsigned long int sc_rsvd[12];/* reserved for future use */
> >>
> >> > The easiest workaround is probably to install libunwind 
> on your system
> >>
> >> The right fix is not to use a 2 years old glibc.
> > 
> > 
> > That's not very old.  One shouldn't have to upgrade libc 
> just to build gcc?
> 
> Did the two-year-old libc really support ia64 well?   I guess 
> Itanium 1 was out then, but those were early days...

If it's a question of glibc 2.2.x vs. 2.3.x, there are
ia64 Linux distributions based on glibc 2.2 that work
pretty well - SUSE's SLES8, for example.  The glibc
used there is somewhere in between the two extremes
noted here (sc_rsvd is 14, and the sc_rbs_base and
sc_loadrs fields are defined).

It's kind of painful when we have to have these lockstep
dependencies but I guess things have to be moved forward
somehow.

RE: gcc problems

[Jim Wilson]

On Fri, 2004-02-06 at 09:34, Wichmann, Mats D wrote:
> If it's a question of glibc 2.2.x vs. 2.3.x, there are
> ia64 Linux distributions based on glibc 2.2 that work
> pretty well - SUSE's SLES8, for example.

gcc-3.x will have some problems when used on a glibc-2.2.x system, but
most of them are obscure, and probably none of them apply to building
kernels, because the kernel doesn't link in glibc.

It is reasonable that gcc should be buildable though.  I believe the
following patch solves this problem.  I just ifdefed out the code for
old glibc versions.  I see no point in trying to make this work, because
unwinding will fail (for user apps) for other reasons if you are using
glibc-2.2.4.

I don't have access to a glibc-2.2.4 system for testing.  I can't use
such old systems for gcc 3.x development.  It works OK for glibc 2.3,
where it has no effect.  If someone tells me that this does work, then I
can check it into the FSF gcc sources.

2004-02-06  James E Wilson  <wilson@specifixinc.com>

	* config/ia64/linux.h (MD_FALLBACK_FRAME_STATE_FOR): Only define for
	glibc 2.3 or better.

Index: linux.h
=================================RCS file: /cvs/gcc/gcc/gcc/config/ia64/linux.h,v
retrieving revision 1.27
diff -p -r1.27 linux.h
*** linux.h	19 Dec 2003 14:00:51 -0000	1.27
--- linux.h	7 Feb 2004 01:50:46 -0000
*************** do {						\
*** 58,63 ****
--- 58,68 ----
  /* Do code reading to identify a signal frame, and set the frame
     state data appropriately.  See unwind-dw2.c for the structs.  */
  
+ /* This works only for glibc-2.3 and later, because sigcontext is different
+    in glibc-2.2.4.  */
+ 
+ #if __GLIBC__ > 2 || (__GLIBC__ = 2 && __GLIBC_MINOR__ >= 3)
+ 
  #ifdef IN_LIBGCC2
  #include <signal.h>
  #include <sys/ucontext.h>
*************** do {						\
*** 207,209 ****
--- 212,215 ----
      }
  
  #endif /* IN_LIBGCC2 */
+ #endif /* glibc-2.3 or better */
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: gcc problems

[Andrew Morton]

Jim Wilson <wilson@specifixinc.com> wrote:
>
> On Fri, 2004-02-06 at 09:34, Wichmann, Mats D wrote:
>  > If it's a question of glibc 2.2.x vs. 2.3.x, there are
>  > ia64 Linux distributions based on glibc 2.2 that work
>  > pretty well - SUSE's SLES8, for example.
> 
>  gcc-3.x will have some problems when used on a glibc-2.2.x system, but
>  most of them are obscure, and probably none of them apply to building
>  kernels, because the kernel doesn't link in glibc.
> 
>  It is reasonable that gcc should be buildable though.  I believe the
>  following patch solves this problem.  I just ifdefed out the code for
>  old glibc versions.  I see no point in trying to make this work, because
>  unwinding will fail (for user apps) for other reasons if you are using
>  glibc-2.2.4.
> 
>  I don't have access to a glibc-2.2.4 system for testing.  I can't use
>  such old systems for gcc 3.x development.  It works OK for glibc 2.3,
>  where it has no effect.  If someone tells me that this does work, then I
>  can check it into the FSF gcc sources.
> 
>  2004-02-06  James E Wilson  <wilson@specifixinc.com>
> 
>  	* config/ia64/linux.h (MD_FALLBACK_FRAME_STATE_FOR): Only define for
>  	glibc 2.3 or better.

This gave me a successful build of

	gcc (GCC) 3.5.0 20040206 (experimental)

on

	linux-tiger:/usr/src/gcc-cvs-obj> cat /etc/issue
	Red Hat Linux Advanced Server release 2.1AS (Derry)

	linux-tiger:/usr/src/gcc-cvs-obj> rpm -q glibc
	glibc-2.2.4-32.3

Thanks.	  Ship it.

Re: gcc problems

[David Mosberger]

>>>>> On Fri, 6 Feb 2004 08:30:50 -0800, Andrew Morton <akpm@osdl.org> said:

  Andrew> Andreas Schwab <schwab@suse.de> wrote:
  >>  The fields were named differently in old versions of glibc, but
  >> the whole layout didn't change in any way.

  >> - unsigned long int sc_rsvd[16];/* reserved for future use */ +
  >> unsigned long int sc_rbs_base;/* NULL or new base of sighandler's
  >> rbs */ + unsigned long int sc_loadrs; /* see description above */
  >> + unsigned long int sc_ar25; /* cmp8xchg16 uses this */ +
  >> unsigned long int sc_ar26; /* rsvd for scratch use */ + unsigned
  >> long int sc_rsvd[12];/* reserved for future use */

  >> > The easiest workaround is probably to install libunwind on your
  >> system

  >> The right fix is not to use a 2 years old glibc.

  Andrew> That's not very old.  One shouldn't have to upgrade libc
  Andrew> just to build gcc?

True in general, but in this particular case, many bugs have been
fixed in glibc in the meantime, especially with respect to unwinding.
So 2 years is old when trying to build a compiler which has reasonable
support for unwinding.

	--david