Re: Problems on PowerPC...

Re: Problems on PowerPC...

[Jeffrey A Law]

  In message <Pine.NEB.3.96.970821084635.26124B-100000@water.waterw.com>you write:
  > 	I was trying to compile egcs on my Linux-Pmac PowerPC 601 system,
  > and I noted that there seem to be problems with the generation of
  > crtbegin.o and crtend.o, or perhaps in the construction of __CTOR_END__
  > and __CTOR_LIST__ - I'm not sure yet.  I'm using the 970814 snapshot.
I've checked in Goeffrey Keating's t-ppccomm patch would should fix this
for the next snapshot.
jeff

Re: Problems on PowerPC...

[Michael Meissner]

David Edelsohn writes:
| >>>>> 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.

Actually that's not quite correct WRT to using init/fini sections.
Right now, the SVR4 compilers (linux, solaris, eabi) use pointers
dropped into .ctors and .dtors sections, and under eabi at least, the
__eabi function makes sure they are run.  I flirted with using
init/fini section, but when I was working on the Solaris PPC compiler,
I had to drop using them, due to a bug in the Solaris linker (that
could not do PC relative relocations cross sections).  It has been
sort of on my todo list to revisit this, but I forgot about it.

| David

Re: Problems on PowerPC...

[dtm]

On Thu, 21 Aug 1997, Jim Wilson wrote:

> 	make CC="gcc" CFLAGS="-fsigned-char" LANGUAGES=c genattr
> 
> 	make CC="stage1/xgcc -Bstage1/" CFLAGS="-fsigned-char" LANGUAGES=c genattr
> 
> Try adding "-v" to CFLAGS.  This will show the linker command lines, which
> may show up an obvious difference.

Gotcha. (the following is formatted a bit for niceness...) 

>>>>>>>>>>
make CC="stage1/xgcc -Bstage1/" CFLAGS="-fsigned-char -v" \
	LANGUAGES=c genattr

stage1/xgcc -Bstage1/  -DIN_GCC    -fsigned-char -v  -DHAVE_CONFIG_H   -o
genattr \
 genattr.o rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case
"stage1/xgcc -Bstage1/"@"" in "cc"@?*) echo  ;; esac ` ` case "" in ?*)
echo  ;; esac ` 

Reading specs from stage1/specs
gcc version egcs-2.90.00 970814 (gcc2-970802 experimental)

stage1/ld -m elf32ppc -o genattr /usr/lib/crt1.o /usr/lib/crti.o \
	stage1/crtbegin.o genattr.o rtl.o obstack.o stage1/libgcc.a -lc \
	stage1/libgcc.a stage1/crtend.o /usr/lib/crtn.o
<<<<<<<<<<
>>>>>>>>>>
make CC="gcc" CFLAGS="-fsigned-char -v" LANGUAGES=c genattr

gcc  -DIN_GCC    -fsigned-char -v  -DHAVE_CONFIG_H   -o genattr \
 genattr.o rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case
"gcc"@"" in "cc"@?*) echo  ;; esac ` ` case "" in ?*) echo  ;; esac ` 

Reading specs from
/usr/lib/gcc-lib/powerpc-unknown-linux/2.7.2.1-ppclinux/specs
gcc version 2.7.2.1-ppclinux

ld -dynamic-linker=/lib/ld.so.1 -o genattr /usr/lib/crt1.o \
	/usr/lib/crti.o /usr/lib/crtbegin.o \
	-L/usr/lib/gcc-lib/powerpc-unknown-linux/2.7.2.1-ppclinux \ 
	genattr.o rtl.o obstack.o \
	/usr/lib/gcc-lib/powerpc-unknown-linux/2.7.2.1-ppclinux/libgcc.a \
	-lc /usr/lib/gcc-lib/powerpc-unknown-linux/2.7.2.1-ppclinux/libgcc.a \
	/usr/lib/crtend.o /usr/lib/crtn.o
<<<<<<<<<<

It looks like there's a difference in the ld command that's being
issued...but it also looks like there might be issues of dynamic
linking involved here when I'm using my normal gcc.  Egcs is providing
an '-m elf32ppc' argument that GCC isn't.  GCC is providing an
extra '-dynamic-linker=/lib/ld.so.1' argument that Egcs isn't.  

I've tried adding a '-Wl,-m,elf32ppc' to the CFLAGS of the make
with standard GCC, but that didn't cause it to produce a broken

 
> It is possible that collect2.c is doing something different that is
> causing a problem.  You can use -Wl,-debug to debug collect2.

The output from adding a -Wl,-debug to CFLAGS doesn't seem to 
indicate much of a difference between the egcs and gcc. The
only significant difference I noted was that all of the paths
were pointing to different places, and some of the ones used
in the egcs compile didn't exist.  I wouldn't think that's the
cause of the problem, though.  Perhaps I'll step through some
of the collect2 process in gdb...It seems to be the guy responsible
for making __CTOR_LIST__ and such...perhaps it's doing it wrong...
 
> Also, check your `normal-gcc' sources.  David Edelsohn implied that the
> linux-pmac gcc was different from FSF gcc, and if this is true, then you
> might be able to figure out what was added to the linux-pmac gcc sources
> that needs to be added to the FSF (and EGCS) gcc sources to make them
> work on a linux-pmac system.

I just started working on that.  No news yet...

Thanks,
-David

> Jim
> 

Re: Problems on PowerPC...

[H.J. Lu]

> It looks like there's a difference in the ld command that's being
> issued...but it also looks like there might be issues of dynamic
> linking involved here when I'm using my normal gcc.  Egcs is providing
> an '-m elf32ppc' argument that GCC isn't.  GCC is providing an
> extra '-dynamic-linker=/lib/ld.so.1' argument that Egcs isn't.  
> 

ppc-linux in egcs assumes you are using glibc 2 on ppc.
Also it assumes binutils 2.8.1.0.15 for linux or the
gas snapshot is used.


H.J.

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: Problems on PowerPC...

[David Edelsohn]

>>>>> 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

Problems on PowerPC...

[David McWherter]

	I was trying to compile egcs on my Linux-Pmac PowerPC 601 system,
and I noted that there seem to be problems with the generation of
crtbegin.o and crtend.o, or perhaps in the construction of __CTOR_END__
and __CTOR_LIST__ - I'm not sure yet.  I'm using the 970814 snapshot.

	Anyways, my problem comes in building stage2 of the compiler.
When building genattr, the compiler links obstack.o with a couple of 
other object files, resulting in an executable.  The problem is that when
the executable is run, from __do_global_ctors_aux(), program control is
jumping into a constructor for the obstack.o module, it seems.  The
problem is that the only thing there is a sequence of illegal instructions
(all 0's, as obstack.c seems to contain no real code after preprocessor
fun on my system).

    I've analyzed the generation of the __CTOR_LIST__ and __CTOR_END__
symbols in the genattr program, and it seems that somewhere, the version
being compiled by egcs is putting an extra item in the constructor list
that my 'real' gcc isn't creating.  This item points to the above
described block of illegal instructions.  

    I was wondering if anybody on this list might be able to give me some
pointers on where to look to solve this problem.  I figure that the
problem lies in the creation of the __CTOR_LIST__, but I'm not 100%
positive.  Perhaps I should be looking in collect2's source?

Thanks,
-David McWherter
dtm@waterw.com