[parisc-linux] segfaults with new binutils

[parisc-linux] segfaults with new binutils

[Randolph Chung]

I'm using binutils from
ftp://puffin.external.hp.com/pub/parisc/binaries/new-debs/debian/
with the corresponding libc6/libc6-dev in that directory, and using the
new gcc-2.97 packages.

Running any of the binaries in the binutils deb gives an immediate
segfault. This includes things like as, ld, etc... obviously this makes
it rather difficult to compile anything.. :-(

I've tried this with both 32-bit and 64-bit kernels built from
yesterday's cvs. Also, at taggart's advice, tried an older 32-bit kernel
built from Feb21 CVS (that was the date of the kernel he was using.) 
This is on a C3k.

strace gives: 
[...]
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\2\205"..., 1024) = 1
024
newfstat(3, {st_mode=S_IFREG|0755, st_size=1281732, ...}) = 0
close(3)                                = 0
munmap(0x4001d000, 7026)                = 0
getpid()                                = 9829
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

I rebuilt binutils using an earlier nfsroot (so, older binutils/glibc/gcc 
combo) and the resulting binutils binaries work ok with the new 
os/kernel/libc/gcc combo.

ideas, hints, fixes? :)
randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] segfaults with new binutils

[Randolph Chung]

> Running any of the binaries in the binutils deb gives an immediate
> segfault. This includes things like as, ld, etc... obviously this makes
> it rather difficult to compile anything.. :-(

ok, one more bit of info; removing the --enable-shared from the binutils
build line gives binaries that work, so i'm guessing there's some
problems with the shared libs (libopcodes and libbfd) ?

randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] segfaults with new binutils

[Alan Modra]

On Sat, 10 Mar 2001, Randolph Chung wrote:

> > Running any of the binaries in the binutils deb gives an immediate
> > segfault. This includes things like as, ld, etc... obviously this makes
> > it rather difficult to compile anything.. :-(
> 
> ok, one more bit of info; removing the --enable-shared from the binutils
> build line gives binaries that work, so i'm guessing there's some
> problems with the shared libs (libopcodes and libbfd) ?

Very likely.  I'm downloading at the moment to have a look at
it.  You can check yourself by disassembling the shared libs.

"objdump -j .init -dr libbfd.so" should give you something like the
following:

0000000000011a0c <_init-0x1c>:
   11a0c:	e8 20 00 00 	b,l 11a14 <_init-0x14>,r1
   11a10:	28 2a 50 00 	addil 54800,r1,%r1
   11a14:	e0 20 22 02 	be,n 100(sr4,r1)
   11a18:	2a 7f ff ff 	addil -800,r19,%r1
   11a1c:	48 35 06 88 	ldw 344(r1),r21
   11a20:	ea a0 c0 00 	bv r0(r21)
   11a24:	48 33 06 90 	ldw 348(r1),r19

0000000000011a28 <_init>:
   11a28:	6b c2 3f d9 	stw rp,-14(sp)
   11a2c:	6f c4 00 80 	stw,ma r4,40(sp)
   11a30:	6b d3 3f c1 	stw r19,-20(sp)
   11a34:	e8 5f 1f bd 	b,l 11a18 <_init-0x10>,rp
   11a38:	08 13 02 44 	copy r19,r4
   11a3c:	08 04 02 53 	copy r4,r19
   11a40:	e8 40 02 a0 	b,l 11b98 <frame_dummy>,rp
   11a44:	08 00 02 40 	nop
   11a48:	08 04 02 53 	copy r4,r19
   11a4c:	e8 5f 1f 75 	b,l 11a0c <_init-0x1c>,rp
   11a50:	08 00 02 40 	nop
   11a54:	08 04 02 53 	copy r4,r19
   11a58:	4b c2 3f 59 	ldw -54(sp),rp
   11a5c:	08 04 02 53 	copy r4,r19
   11a60:	e8 40 c0 00 	bv r0(rp)

0000000000011a64 <_end_init>:
   11a64:	4f c4 3f 81 	ldw,mb -40(sp),r4

If you see a mix of r4 and r3 being used to save/restore r19, then that's
the direct cause of your crashes.  The indirect cause is a bad crti.o and
crtn.o built from glibc sources checked out from pehc between 2001/01/16
and 2001/02/05.

You've already started down the path to recovery:
  build and install binutils with --disable-shared,
  build and install gcc with --enable-languages=c --disable-shared,
  build and install glibc

You can then build tools with --enable-shared if you like.

Alan Modra
-- 
Linuxcare

Re: [parisc-linux] segfaults with new binutils

[Alan Modra]

On Sun, 11 Mar 2001, Alan Modra wrote:

> On Sat, 10 Mar 2001, Randolph Chung wrote:
> > ok, one more bit of info; removing the --enable-shared from the binutils
> > build line gives binaries that work, so i'm guessing there's some
> > problems with the shared libs (libopcodes and libbfd) ?
> 
> Very likely.  I'm downloading at the moment to have a look at
> it.  You can check yourself by disassembling the shared libs.
> 
> "objdump -j .init -dr libbfd.so"

Yep, badly borken libbfd and libopcodes in binutils_2.10.91.0.2-3_hppa.deb

Incidentally, I'm not actively updating binutils CVS on pehc any longer.
If you want the latest code, get it from sourceware.cygnus.com CVS, either
the 2.11 branch, or trunk for bleeding edge code.  At the moment, there's
no particular reason to not use pehc for hppa-linux binutils, as it's not
too far behind, but that will no doubt change in the future...

Alan Modra
-- 
Linuxcare

Re: [parisc-linux] segfaults with new binutils

[Matthew Wilcox]

On Sun, Mar 11, 2001 at 02:31:26PM +1100, Alan Modra wrote:
> Incidentally, I'm not actively updating binutils CVS on pehc any longer.
> If you want the latest code, get it from sourceware.cygnus.com CVS, either
> the 2.11 branch, or trunk for bleeding edge code.  At the moment, there's
> no particular reason to not use pehc for hppa-linux binutils, as it's not
> too far behind, but that will no doubt change in the future...

Is there any point in keeping this CVS module then?  Shall we just delete it?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] segfaults with new binutils

[Randolph Chung]

In reference to a message from Matthew Wilcox, dated Mar 11:
> On Sun, Mar 11, 2001 at 02:31:26PM +1100, Alan Modra wrote:
> > Incidentally, I'm not actively updating binutils CVS on pehc any longer.
> > If you want the latest code, get it from sourceware.cygnus.com CVS, either
> > the 2.11 branch, or trunk for bleeding edge code.  At the moment, there's
> > no particular reason to not use pehc for hppa-linux binutils, as it's not
> > too far behind, but that will no doubt change in the future...
> 
> Is there any point in keeping this CVS module then?  Shall we just delete it?

i'm not sure what taggart did to build the deb on pehc, but i've been
building from Debian's source package. If we are at a point where we can
rely on the Debian maintainer to get the sources from upstream that we
need I think we'll be much better off.

randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] segfaults with new binutils

[Alan Modra]

On Sun, 11 Mar 2001, Matthew Wilcox wrote:

>[re pehc binutils] 
> Is there any point in keeping this CVS module then?  Shall we just delete it?

Purge after 2.11 is released (and proves OK).

Alan
-- 
Linuxcare

Re: [parisc-linux] segfaults with new binutils

[Randolph Chung]

> You've already started down the path to recovery:
>   build and install binutils with --disable-shared,
>   build and install gcc with --enable-languages=c --disable-shared,
>   build and install glibc

trying to do this last step, but am getting some pretty odd results.

when trying to build linuxthreads, the glibc compile dies when trying to
assemble linuxthreads/crti.S

in particular, it doesn't like the first and last instructions in the
following fragment:

        addil LT'.LC0,%r19
	stw %r2,-20(%r30)
        ldo 64(%r30),%r30
        ldw RT'.LC0(%r1),%r1

i thought LT and RT were #define's of some sort, but i don't see them
defined any place. 

it's also complaining about .init and .fini. From what I gather the
compile takes pt-initfini.c, translates it to a .S file, then does some
sed magic to remove some sections. This leaves a .S that has a .PROC and
.ENTRY for .init/.fini without a corresponding .EXIT and .PROCEND

i tried this both with gcc 2.96 and 2.97... wonder what's going on...

randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] segfaults with new binutils

[Alan Modra]

On Sun, 11 Mar 2001, Randolph Chung wrote:

> > You've already started down the path to recovery:
> >   build and install binutils with --disable-shared,
> >   build and install gcc with --enable-languages=c --disable-shared,
> >   build and install glibc
> 
> trying to do this last step, but am getting some pretty odd results.
> 
> when trying to build linuxthreads, the glibc compile dies when trying to
> assemble linuxthreads/crti.S
> 
> it's also complaining about .init and .fini. From what I gather the
> compile takes pt-initfini.c, translates it to a .S file, then does some
> sed magic to remove some sections. This leaves a .S that has a .PROC and
> .ENTRY for .init/.fini without a corresponding .EXIT and .PROCEND

Huh?  My builds don't try to build crti.o for linuxthreads.  crti.o is
built in csu/ from sysdeps/hppa/elf/initfini.c.  Perhaps you have a
configuration problem.  What options did you pass to configure?  Hmm, more
importantly, what source are you compiling?  I don't have a pt-initfini.c
in my source tree!

$ cd /usr/src/parisc/glibc
$ cvs update -d -ko
? sysdeps/hppa/hppa64
$ find . -name '*initfini*'
./sysdeps/generic/initfini.c
./sysdeps/hppa/elf/initfini.c
./sysdeps/ia64/elf/initfini.c
./sysdeps/s390/initfini.c
./sysdeps/sh/elf/initfini.c

> i thought LT and RT were #define's of some sort, but i don't see them
> defined any place. 

LT' and RT' are field selectors.  They give you the LR' and RR' values
respectively of the offset from %r19 to the .got slot for the symbol.  The
presense of these selectors also tells the asembler/linker to set up .got
entries for the symbol.

Alan
-- 
Linuxcare

Re: [parisc-linux] segfaults with new binutils

[Jes Sorensen]

>>>>> "Alan" == Alan Modra <alan@linuxcare.com.au> writes:

Alan> Huh?  My builds don't try to build crti.o for linuxthreads.
Alan> crti.o is built in csu/ from sysdeps/hppa/elf/initfini.c.
Alan> Perhaps you have a configuration problem.  What options did you
Alan> pass to configure?  Hmm, more importantly, what source are you
Alan> compiling?  I don't have a pt-initfini.c in my source tree!

pt-initfini.c was added to glibc-2.2.2 recently, you need it to build
a working LinuxThreads library now. Unless someone has synced the
parisc tree recently it shouldn't be an issue, as long as noone tries
to compile the Cygnus tree for parisc.

Jes

Re: [parisc-linux] segfaults with new binutils

[Alan Modra]

On 12 Mar 2001, Jes Sorensen wrote:

> pt-initfini.c was added to glibc-2.2.2 recently, you need it to build
> a working LinuxThreads library now. Unless someone has synced the
> parisc tree recently it shouldn't be an issue, as long as noone tries
> to compile the Cygnus tree for parisc.

Yeah, I figured Randolph was probably not compiling pehc glibc.  When we
do the next merge, we'll need to add an hppa-linux specific version of
pt-initfini.c

Alan
-- 
Linuxcare

Re: [parisc-linux] segfaults with new binutils

[Randolph Chung]

> Yeah, I figured Randolph was probably not compiling pehc glibc.  When we
> do the next merge, we'll need to add an hppa-linux specific version of
> pt-initfini.c

you are right, of course. i was building from Debian's glibc 2.2.2
package. taggart said he's going to rebuild 2.2.1 from pehc cvs, so i'll
wait for him to do that.

randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] segfaults with new binutils

[Alan Modra]

On Wed, 14 Mar 2001, Alan Modra wrote:

> ld crashes for me too.  Yikes!  I'll look into it.

It's a compiler bug. :-(

I'm getting a crash at 0x40045a08.  ldd binutils/ld/.libs/ld-new shows me
that libbfd loads at 4001e000, so that's an offset of 27a08.
Dissasembling gives me this code in hppa_add_stub:

   279d4:       0d 82 10 35     ldb,ma  1(sr0,r12),r21
   279d8:       0d 82 10 34     ldb,ma  1(sr0,r12),r20
   279dc:       0d 75 12 22     stb,ma  r21,1(sr0,r11)
   279e0:       af 9d 5f dd     addib,>= -2,ret0,279d4 <hppa_add_stub+0x32c>
   279e4:       0d 74 12 22     stb,ma  r20,1(sr0,r11)
   279e8:       0d 80 10 15     ldb  0(sr0,r12),r21
   279ec:       0d 75 12 00     stb  r21,0(sr0,r11)
   279f0:       63 da 3e e9     stb r26,-8c(sp)
   279f4:       63 c0 3e eb     stb r0,-8b(sp)
   279f8:       63 d6 3e e1     stb r22,-90(sp)
   279fc:       63 d7 3e e3     stb r23,-8f(sp)
   27a00:       63 d8 3e e5     stb r24,-8e(sp)
   27a04:       63 d9 3e e7     stb r25,-8d(sp)
   27a08:       4a b5 08 f0     ldw 478(r21),r21

Note the use of r21 as a temp to shuffle bytes around, then it's use as an
index reg.  What's missing is a ldil to set up the high part of the
address.

Alan
-- 
Linuxcare

Re: [parisc-linux] segfaults with new binutils

[Alan Modra]

On Wed, 14 Mar 2001, Alan Modra wrote:

> It's a compiler bug. :-(

And we're indebted to John for already fixing it.

Thu Mar  8 23:29:37 2001  John Wehle  (john@feith.com)

	* rtlanal.c (rtx_varies_p): Check operand 0 of a
	LO_SUM unless for_alias is set.

The above probably makes some of my hacks redundant.  For the time being,
I've left them in, and just added John's fix to puffin.external.hp.com
CVS.

Alan
-- 
Linuxcare