Re: Problems on PowerPC...

Re: Problems on PowerPC...

[dtm]

With an egcs-compiled genattr, I'm getting something that looks
like this in gdb:

============
(gdb) inspect ((unsigned long*)&__CTOR_LIST__)
$1 = (unsigned long *) 0x2473b0
(gdb) inspect ((unsigned long*)&__CTOR_END__)
$2 = (unsigned long *) 0x2473b8
(gdb) inspect ((unsigned long*)&__CTOR_LIST__)[0]
$3 = 0xffffffff
(gdb) inspect ((unsigned long*)&__CTOR_LIST__)[1]
$4 = 0x24746c
(gdb) inspect ((unsigned long*)&__CTOR_LIST__)[2]
$5 = 0x0
(gdb) inspect &obstack
$6 = (struct obstack *) 0x24746c
(gdb) inspect obstack
$7 = {chunk_size = 0x0, chunk = 0x0, object_base = 0x0, next_free = 0x0, 
  chunk_limit = 0x0, temp = 0x0, alignment_mask = 0x0, chunkfun = 0, 
  freefun = 0, extra_arg = 0x0, use_extra_arg = 0x0, maybe_empty_object =
0x0, 
  alloc_failed = 0x0}
(gdb) run
Starting program: /usr/src/redhat/BUILD/egcs-ss-970814/genattr_egcs 
Breakpoint 1 at 0x300741ac

Program received signal SIGILL, Illegal instruction.
0x24746c in obstack ()
(gdb) bt
#0  0x24746c in obstack ()
#1  0x205538 in __do_global_ctors_aux ()
#2  0x2055bc in _init ()
#3  0x200a24 in _start ()
(gdb) 

=============

being generated code-wise, but somehow, into __CTOR_LIST__, there's
being shoved a structure of some sort (from genattr.o), that's causing
things to go awry.

And again, looking at __CTOR_LIST__ and __CTOR_END__ in a normal-gcc
linked genattr:

=============
(gdb) inspect ((unsigned long*)&__CTOR_LIST__) 
$1 = (unsigned long *) 0x247218
(gdb) inspect ((unsigned long*)&__CTOR_END__)
$2 = (unsigned long *) 0x24721c
(gdb) inspect ((unsigned long*)&__CTOR_LIST__)[0]
$3 = 0xffffffff
(gdb) inspect ((unsigned long*)&__CTOR_LIST__)[1]
$4 = 0xffffffff
(gdb) run
Starting program: /usr/src/redhat/BUILD/egcs-ss-970814/genattr_gcc 
Breakpoint 1 at 0x300741ac
genattr: No input file name.

Program exited with code 041.
=============

Which looks rather normal to me.

Now, genattr works if I leave the object files genattr.o, rtl.o, and 
obstack.o that have been compiled with egcs, and I then issue a:

make CC="gcc" CFLAGS="-fsigned-char" LANGUAGES=c genattr

And it breaks again if I do the following:

rm genattr
make CC="stage1/xgcc -Bstage1/" CFLAGS="-fsigned-char" LANGUAGES=c genattr

So it seems to me that there's something wrong in the linker somewhere...
I just don't know where...

-David
dtm@waterw.com

On Thu, 21 Aug 1997, David Edelsohn wrote:

> >>>>> David McWherter writes:
> 
> David> I dunno if they're C++ constructors, but a function pointer from
> David> __CTOR_LIST__ is being picked off and run by __do_global_ctors_aux() when
> David> I compile with egcs.  When I compile genattr with my standard gcc, it
> David> doesn't do so.  The egcs-compiled genattr dies because the pointer it
> David> picks out from __CTOR_LIST__ is a pointer to a block of illegal
> David> instructions, and a SIGILL is generated.
>  
> David> I dunno.  My standard-gcc-built code seems to have empty __CTOR_LIST__'s,
> David> but the egcs stuff has something there.
> 
> 	All of the various Linux for PowerPC use SVR4 which has init and
> fini object file sections.  Something is ending up in the __CTOR_LIST__
> when using egcs that should not be present (genattr and obstack.o are pure
> C, not C++: no constructors exist).  I would assume that something in the
> rs6000/sysv4.h configuration distributed in the pax files on linuxppc.org
> has not made it back to the FSF sources on which egcs is based.
> 
> David
> 

Re: g77 building [was Re: bootstrapping problems with native compiler]

[Joel Sherrill]

On Thu, 21 Aug 1997, Jim Wilson wrote:

> 	FWIW, I used to build ObjC with a cross-compiler. It
> 	was not a big deal. But I always used host == build
> 	or host == target.
> 
> It has always been possible to build ObjC with a cross-compiler.
> However, the important point here is that the current scheme has a serious
> flaw that prevents one from building an entire system from scratch
> automatically with a single make command.
> 
> This is because there are circular dependencies.  We can't build the ObjC
> runtime until after the C library has been built.  We can't build the
> C library until after we build gcc.  And we can't build gcc because the ObjC
> runtime inside of it needs the C library first.  This can obviously be
> fixed by hand if you build gcc twice, once without the ObjC runtime, and
> then a second time within, but this is very awkward, and needs to be fixed.

And let's not forget my favorite problem. :) 

An complete rtems build from source goes binutils, gcc, C library, rtems.
gcc looks for an installed copy of limits.h which for rtems is part of the
C library installation which has not occurred yet.  So it generates one
which is not right.  Out build procedure involves removing limits.h and
*.a from the gcc build point, remaking them, and reinstalling.

It feels likely that separating gcc support libraries from the compiler
itself would address this as well.

--joel

g++ bug in recent gcc.

[H.J. Lu]

Hi,

The reported libg++ failure is caused by the patch enclosed
here. After backing out this patch, I successfully did

# make
# make check

on libg++ 2.8b6 glibc 6 under Linux/x86


H.J.
---
Thu Jul 31 17:14:04 1997  Jason Merrill  <jason@yorick.cygnus.com>

	* tree.c (build_cplus_new): Don't set TREE_ADDRESSABLE.

diff -rcp2N testgcc-970725/cp/tree.c testgcc-970803/cp/tree.c
*** testgcc-970725/cp/tree.c	Thu Jul 24 20:59:08 1997
--- testgcc-970803/cp/tree.c	Fri Aug  1 17:21:36 1997
*************** build_cplus_new (type, init)
*** 228,235 ****
  		TREE_OPERAND (init, 0), TREE_OPERAND (init, 1), slot);
    TREE_SIDE_EFFECTS (rval) = 1;
-   TREE_ADDRESSABLE (rval) = 1;
    rval = build (TARGET_EXPR, type, slot, rval, NULL_TREE, NULL_TREE);
    TREE_SIDE_EFFECTS (rval) = 1;
-   TREE_ADDRESSABLE (rval) = 1;
  
    return rval;
--- 228,233 ----

problems compiling libg++

[Vlad Petersen]

Howdy folks,

I've d-loaded dejagnu-970707.tar.gz, egcs-ss-970814.tar.gz
and libg++-2.8.0b6.tar.gz from Cygnus FTP site and trying to
compile them. The first two compiled okay but I am having lots
of trouble with libg++. First, it complained about things like:

__extensions__

found in /usr/src/libg++-2.8.0/libio/_G_config.h on line #19.
Since I don't understand what it means, I decided to
start from the very beginning and installed libg++ again. Now,
after having compiled every single source file, it is saying:

/bin/sh: c: command not found
make[1]: [bigstmp-complex] Error 127 (ignored)

Wonder where it came from? There's nothing like a single `c'
in Makefile. Anyway, the compilation aborted with:

ar rc tlibstdc++.a `cat stdlist`
ar: *.o: No such file or directory
make[1]: *** [libstdc++.a] Error 1
make[1]: Leaving directory `/usr/src/libg++-2.8.0/libstdc++'
make: *** [all-target-libstdc++] Error 2

Any advice would be much appreciated.

I'm using Linux Red Hat 4.2 with gcc-2.7.2-1 and libc-5.3.12.

-- 
My real email address is:       <vladimip at uniserve dot com>
#include <disclaimer.h>  |     *Good pings come in small packets*
       Vancouver         |     Windows: for IQs smaller than 95
   British Columbia      | SIGSIG -- signature too long (core dumped)

Re: g77 building [was Re: bootstrapping problems with native compiler]

[Doug Evans]

   Date: Fri, 22 Aug 1997 10:28:49 -0700
   From: Jim Wilson <wilson@cygnus.com>

	   FWIW, not having read Jim's paper

   Actually, the crossgcc FAQ was written by Doug Evans.  I forgot to mention
   where to find it.  It can be found at
	   ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ

Additions/comments/etc. to it are welcome, btw.

Re: g77 building [was Re: bootstrapping problems with native compiler]

[Jim Wilson]

	FWIW, not having read Jim's paper

Actually, the crossgcc FAQ was written by Doug Evans.  I forgot to mention
where to find it.  It can be found at
	ftp://ftp.cygnus.com/pub/embedded/crossgcc/FAQ

Jim

Re: g77 building [was Re: bootstrapping problems with native compiler]

[Craig Burley]

>I will certainly discuss it with the Fortran folks before taking any action.

FWIW, not having read Jim's paper, everything being discussed here
in terms of how things *should* work seems highly reasonable to me.
In particular, it seems to be heading away from kludgeville even
at the risk of upsetting some long-cherished assumptions about
how free software must be distributed, which I think we've already
paid for many times over with little benefit.

        tq vm, (burley)

Re: g77 building [was Re: bootstrapping problems with native compiler]

[Jim Wilson]

	FWIW, I used to build ObjC with a cross-compiler. It
	was not a big deal. But I always used host == build
	or host == target.

It has always been possible to build ObjC with a cross-compiler.
However, the important point here is that the current scheme has a serious
flaw that prevents one from building an entire system from scratch
automatically with a single make command.

This is because there are circular dependencies.  We can't build the ObjC
runtime until after the C library has been built.  We can't build the
C library until after we build gcc.  And we can't build gcc because the ObjC
runtime inside of it needs the C library first.  This can obviously be
fixed by hand if you build gcc twice, once without the ObjC runtime, and
then a second time within, but this is very awkward, and needs to be fixed.

Jim

Re: g77 building [was Re: bootstrapping problems with native compiler]

[H.J. Lu]

> It is the same for ObjC.  ObjC has never worked right for cross builds.
> The cross-gcc patches fix this problem by disabling all of the Objective C
> support.
> 

FWIW, I used to build ObjC with a cross-compiler. It
was not a big deal. But I always used host == build
or host == target.


H.J.

Re: g77 building [was Re: bootstrapping problems with native compiler]

[Jim Wilson]

	The G77 configuration does assume that it
	has a working C compiler/library built for the host and target before
	it starts and I'm not sure how else it can work. 

There is nothing wrong with the f77-runtime configuration files.  The only
problem is one of location.  In order for cross builds to work, we must build
things in the following order: compiler, C library, F77 library.  The fact
that the f77-runtime is physically contained inside the compiler directory
means it gets built at the same time as the compiler.  Since it gets built
too soon (before the C library), it does not get built correctly.  This can be
fixed by moving it out of the compiler directory, so that we can build it
after the C library.

It helps if you understand how cross toolchain builds work.  Reading the
cross-gcc FAQ is highly recommended if you want to understand this better.

	I'd have thought it would be the same for ObjC too.

It is the same for ObjC.  ObjC has never worked right for cross builds.
The cross-gcc patches fix this problem by disabling all of the Objective C
support.

	I'm afraid I don't understand the current build system and I don't
	know whether it's broken the g77 configuration/build (which has
	changed somewhat recently anyhow).  I guess if it's problematic at
	present, people have to take f77 out of LANGUAGES.

There is no new problem here, it is just that the change in packaging has
made the problem much more visible than it used to be.  As long as Fortran
was a separate package, it was possible to build gcc, then the C library,
and then a Fortran patched gcc.  Now that the Fortran support is inside gcc,
the old build scheme doesn't apply anymore, and we have a problem because
the fortran runtime is being built before the C library.

	If the configuration is going to be changed, it would probably be a
	good idea to discuss plans with fortran@gnu.ai.mit.edu, especially as
	there are other things that we may want to do in the future, such as
	using Fortran source directly in the runtime.

I will certainly discuss it with the Fortran folks before taking any action.

Jim

g77 building [was Re: bootstrapping problems with native compiler]

[Dave Love]

>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:

 Jim> 	The released G77 is known basically to survive criss-cross builds.
 Jim> 	(The sprintf test makes a pessimistic assumption if necessary.)

 Jim> But it does so by making guesses if CC is a cross compiler that
 Jim> can't link.  This would not be necessary if the f77-runtime was
 Jim> a separate directory from the compiler directory.

I'm sure I understand this properly and haven't had time to revisit
it.  I won't be able to until at least the back end of next week.  I
probably need to scrutinize cross-gcc etc. again, which I haven't
looked at for some time.  The G77 configuration does assume that it
has a working C compiler/library built for the host and target before
it starts and I'm not sure how else it can work.  (I'd have thought it
would be the same for ObjC too.)  However, g77 may well not be doing
the Right Thing because it's been out on a limb with no useful model.
I trust we can sort out any problems that there are later on.

I'm afraid I don't understand the current build system and I don't
know whether it's broken the g77 configuration/build (which has
changed somewhat recently anyhow).  I guess if it's problematic at
present, people have to take f77 out of LANGUAGES.

If the configuration is going to be changed, it would probably be a
good idea to discuss plans with fortran@gnu.ai.mit.edu, especially as
there are other things that we may want to do in the future, such as
using Fortran source directly in the runtime.