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: problems compiling libg++

[H.J. Lu]

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

If you use Linux, you should get libg++ 2.8b6 glibc 6 patch and
libc 5.4.37. Both of them are available at

ftp://ftp.yggdrasil.com/private/hjl

You also should apply the g++ patch I posted to this list earlier.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)