debian's mips userland on mips64

debian's mips userland on mips64

[Andrew Clausen]

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

Re: debian's mips userland on mips64

[Christoph Hellwig]

On Wed, Jan 22, 2003 at 06:30:06PM +1100, Andrew Clausen wrote:
> 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?

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.

Re: debian's mips userland on mips64

[Ralf Baechle]

On Wed, Jan 22, 2003 at 12:45:40PM -0500, Christoph Hellwig wrote:

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

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

  Ralf

Re: debian's mips userland on mips64

[Christoph Hellwig]

On Wed, Jan 22, 2003 at 01:45:06PM +0100, Ralf Baechle wrote:
> There is a 32-bit ptrace compatibility syscall already and last I tried
> it was working quite well for strace.

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

Re: debian's mips userland on mips64

[Greg Banks]

Christoph Hellwig wrote:
> 
> On Wed, Jan 22, 2003 at 01:45:06PM +0100, Ralf Baechle wrote:
> > There is a 32-bit ptrace compatibility syscall already and last I tried
> > it was working quite well for strace.
> 
> 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.

Re: debian's mips userland on mips64

[Ralf Baechle]

On Thu, Jan 23, 2003 at 02:05:44PM +1100, Greg Banks wrote:

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

Strace source is pretty evil ...

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

[...]
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

Re: debian's mips userland on mips64

[Greg Lindahl]

On Wed, Jan 22, 2003 at 12:45:40PM -0500, Christoph Hellwig wrote:

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

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

Re: debian's mips userland on mips64

[Ralf Baechle]

On Wed, Jan 22, 2003 at 01:47:36PM -0800, Greg Lindahl wrote:

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

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

  Ralf

Re: debian's mips userland on mips64

[Andrew Clausen]

On Mon, Feb 03, 2003 at 10:59:52AM -0600, Jason Ormes wrote:
> I happened to see that you were running on an origin 200. I'm currently
> trying to build a kernel for an origin 200 that I have laying around and
> am getting a bunch of errors in the ip27-init.c file.  Is there some
> magic combination of flags when I build this?

I've been using 2.4.x cvs.  What error do you get?  Please post
to the list!

I've been compiling with:

	alias mipsmake='make CROSS_COMPILE=mips64-linux ARCH=mips64'
	mipsmake clean
	mipsmake menuconfig	<-- select arch/mips64/defconfig-ip27
	mipsmake vmlinux.64

>   You mention that you are
> using the mips64-linux kernel but when I turn on ip27 support it wants
> to build a little endian version?  Any help you could give me would be
> gratefully appreciated.

Doesn't for me...

Cheers,
Andrew