Subject: segfault

From: Jim Paris <[email-masked]>
Date: Tue, 4 Sep 2001 23:54:10 -0400

I'm trying to get Linux working on my handheld PC (the Sharp Tripad,
very similar to the Vadem Clio), but I'm having userland problems.  

Some binaries compile and run fine, while others give a segfault right
away.  Compiling with slightly different versions of compilers, glibc,
etc, seems to affect which binaries work and which don't, although I
can't find a combination that seems to work with everything.
Fortunately, one binary that does appear to work fine is 'sash', which
lets me test this stuff.

I uncommented some debugging stuff in the kernel, and the actual error
is:

do_page_fault( )#2: sending SIGSEGV to test-prog for illegal write
access to 00000fd4 (epc == 004027b8, ra == 00402730)

The strange part about this (and the reason why I suspect someone may
be able to help me) is that the address 00000fd4 is always the same,
implying that the binaries are all failing in the same way.  Has
anyone seen this or does anyone have any ideas why this may be
happening?

My original setup was a pre-3.0 CVS GCC and glibc-2.2.3 with the
Linux-VR kernel (based on the MIPS tree as of 2.4.0-test9), but I've
since brought the Linux-VR tree up to 2.4.5 and moved to gcc-3.0.1 and
glibc-2.2.4 with binutils-2.11.90.0.31, and none of this really seems
to help the problem much.

-jim

---

From: Florian Lohoff <[email-masked]>
Date: Wed, 5 Sep 2001 19:15:50 +0200

> anyone seen this or does anyone have any ideas why this may be

Do you have a fix for the sysmips(MIPS_ATOMIC_SET) in there ? Or do
you have the glibc compiled as -mips2 for usage of ll/sc ?

This bug might be a register corruption due to wrong return path
in the sysmips case.

Flo
-- 
Florian Lohoff                  [email-masked]             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 5 Sep 2001 20:05:44 +0200 (MET DST)

> This bug might be a register corruption due to wrong return path

 Since there appears to be no conclusion of the sysmips-on-MIPS-I problem
in sight, I've just put all the related patches I use in a single place
for easy retrieval.  All of them were sent to this mailing list once but
digging through archives is tiresome.  Get them from
'ftp://ftp.ds2.pg.gda.pl/pub/macro/sysmips/'. 

 There is a sys_sysmips() fix in the "sysmips-1" patch and two additional
patches implementing a sys__test_and_set() syscall and its usage in glibc. 
Feel free to use them until an official solution is available. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Jim Paris <[email-masked]>
Date: Wed, 5 Sep 2001 17:51:32 -0400

> you have the glibc compiled as -mips2 for usage of ll/sc ?

Yes, I'm pretty sure that fix is in there.  I'm confused by the whole
mips1/mips2/mips3 thing -- should I be compiling everything with the
same -mipsN, and if so, which one?  I have a VR41xx processor.  The
binaries I'm attempting to run are reported by file(1) as being MIPS 1,
while the kernel image is reported as being MIPS 3 (even though most
of the kernel Makefiles specify -mips2..?)

If I use -mips2 when compiling my userspace binaries, the output files
are the same size but different, but file(1) still reports them as
MIPS 1 and they still crash in the same way.

-jim

---

From: Jim Paris <[email-masked]>
Date: Thu, 13 Sep 2001 14:59:47 -0400

> away.

Aha!  I think I've finally found the problem, thanks to a lightbulb
that blinked on after reading Kjeld's mail about optimization
problems.  I compile everything with -O3 (it's in my environment) and
that apparently resulted in broken binaries.  I rebuilt binutils, gcc,
glibc, and all of my test binaries with -O1.. and everything appears
to work perfectly.

(after wrestling with this for weeks on end, I feel pretty stupid that
it turned out to be something so simple, but I'm also quite elated
that it works)

Next step: conquer the world!  (or, at least, set up user-space stuff)

-jim