Subject: debian's mips userland on mips64

From: Andrew Clausen <[email-masked]>
Date: Wed, 22 Jan 2003 18:30:06 +1100

Hi all,

I'm playing with Debian on an Origin 200 (aka ip27 - 64-bit mips).
The current setup in the mips64-linux world is 64bit kernel +
32bit userland.  So, a mips64-linux kernel can be mostly run a
mips32-linux userland out of the box.

Unfortunately, this doesn't apply to strace, as this play with
the 64bit kernel's stack (eg: struct pt_regs), which is different in
mips32 and mips64.

So, I guess the solution is to hack (it's ugly as hell already...)
strace to detect and understand the 64 bit stack from a 32 bit
userland?

Cheers,
Andrew

---

From: Christoph Hellwig <[email-masked]>
Date: Wed, 22 Jan 2003 12:45:40 -0500

> strace to detect and understand the 64 bit stack from a 32 bit

I don't think so.  You should rather implement a sys32_ptrace and
reference it in the 32bit syscall vector.  Look at the version in
arch/ia64/ia32/sys_ia32.c for an example.

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 22 Jan 2003 13:45:06 +0100

> arch/ia64/ia32/sys_ia32.c for an example.

There is a 32-bit ptrace compatibility syscall already and last I tried
it was working quite well for strace.

  Ralf

---

From: Christoph Hellwig <[email-masked]>
Date: Wed, 22 Jan 2003 15:09:19 -0500

> it was working quite well for strace.

Indeed.  Didn't even check whether mips64 has it already implemented..

---

From: Greg Lindahl <[email-masked]>
Date: Wed, 22 Jan 2003 13:47:36 -0800

> arch/ia64/ia32/sys_ia32.c for an example.

This works as long as you aren't doing n32 - at some point we'll have
a mature enough toolchain to do that, and we're going to need to hack
up sys32_ptrace to do the right thing with the bigger fp register file...

-- greg

---

From: Greg Banks <[email-masked]>
Date: Thu, 23 Jan 2003 14:05:44 +1100

> Indeed.  Didn't even check whether mips64 has it already implemented..

Actually 32bit strace on a 64bit kernel is working *most* of the time, so
there must be a 32bit ptrace syscall which is mostly working.  But...

1.  There is a problem with tracing rt_sigaction() where the signal set
    argument is being misinterpreted either in ptrace or strace.  The
    result is an application buffer overflow in strace which causes it
    to lose track of which processes it's tracing.  This may be entirely
    an strace issue but presumably it doesn't happen on 32bit kernels,
    so the fix (when Andrew figures it out) may require strace to know
    whether it's running on a 64bit kernel.

2.  At some point in the future there may well be 64bit executables which
    we will want to trace with the 32bit strace.  Possibly strace will
    need some sort of modification to dynamically detect whether the
    traced child is 64bit or 32bit.

I'd be very interested to know if anyone's tried running strace on
a mips64 kernel, in particular strace'ing the scp program.

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 23 Jan 2003 06:04:19 +0100

>     whether it's running on a 64bit kernel.

Strace source is pretty evil ...

> a mips64 kernel, in particular strace'ing the scp program.

[...]
ioctl(2, TCGETS, 0x7fff7858)            = -1 EINVAL (Invalid argument)
rt_sigaction(SIGPIPE, {0x10000000, [], 0x4055f4}, {SIG_DFL}, 16) = 0
pipe([0, 0])                            = 3
pipe([268437928, 721805232])            = 5
pipe([720500616, 2147449192])           = 7
close(3)                                = 0
[...]

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 28 Jan 2003 08:00:29 +0100

> up sys32_ptrace to do the right thing with the bigger fp register file...

Which I've done now.  Also works for native 64-bit code.

  Ralf