* debian's mips userland on mips64
@ 2003-01-22 7:30 Andrew Clausen
2003-01-22 17:45 ` Christoph Hellwig
[not found] ` <002001c2cba5$ab641320$4437e183@fermi.win.fnal.gov>
0 siblings, 2 replies; 9+ messages in thread
From: Andrew Clausen @ 2003-01-22 7:30 UTC (permalink / raw)
To: linux-mips; +Cc: gnb
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: debian's mips userland on mips64
2003-01-22 17:45 ` Christoph Hellwig
@ 2003-01-22 12:45 ` Ralf Baechle
2003-01-22 20:09 ` Christoph Hellwig
2003-01-22 21:47 ` Greg Lindahl
1 sibling, 1 reply; 9+ messages in thread
From: Ralf Baechle @ 2003-01-22 12:45 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Andrew Clausen, linux-mips, gnb
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: debian's mips userland on mips64
2003-01-22 7:30 debian's mips userland on mips64 Andrew Clausen
@ 2003-01-22 17:45 ` Christoph Hellwig
2003-01-22 12:45 ` Ralf Baechle
2003-01-22 21:47 ` Greg Lindahl
[not found] ` <002001c2cba5$ab641320$4437e183@fermi.win.fnal.gov>
1 sibling, 2 replies; 9+ messages in thread
From: Christoph Hellwig @ 2003-01-22 17:45 UTC (permalink / raw)
To: Andrew Clausen; +Cc: linux-mips, gnb
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: debian's mips userland on mips64
2003-01-22 12:45 ` Ralf Baechle
@ 2003-01-22 20:09 ` Christoph Hellwig
2003-01-23 3:05 ` Greg Banks
0 siblings, 1 reply; 9+ messages in thread
From: Christoph Hellwig @ 2003-01-22 20:09 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Christoph Hellwig, Andrew Clausen, linux-mips, gnb
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..
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: debian's mips userland on mips64
2003-01-22 17:45 ` Christoph Hellwig
2003-01-22 12:45 ` Ralf Baechle
@ 2003-01-22 21:47 ` Greg Lindahl
2003-01-28 7:00 ` Ralf Baechle
1 sibling, 1 reply; 9+ messages in thread
From: Greg Lindahl @ 2003-01-22 21:47 UTC (permalink / raw)
To: linux-mips
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: debian's mips userland on mips64
2003-01-22 20:09 ` Christoph Hellwig
@ 2003-01-23 3:05 ` Greg Banks
2003-01-23 5:04 ` Ralf Baechle
0 siblings, 1 reply; 9+ messages in thread
From: Greg Banks @ 2003-01-23 3:05 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Ralf Baechle, Andrew Clausen, linux-mips
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: debian's mips userland on mips64
2003-01-23 3:05 ` Greg Banks
@ 2003-01-23 5:04 ` Ralf Baechle
0 siblings, 0 replies; 9+ messages in thread
From: Ralf Baechle @ 2003-01-23 5:04 UTC (permalink / raw)
To: Greg Banks; +Cc: Christoph Hellwig, Andrew Clausen, linux-mips
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: debian's mips userland on mips64
2003-01-22 21:47 ` Greg Lindahl
@ 2003-01-28 7:00 ` Ralf Baechle
0 siblings, 0 replies; 9+ messages in thread
From: Ralf Baechle @ 2003-01-28 7:00 UTC (permalink / raw)
To: linux-mips
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: debian's mips userland on mips64
[not found] ` <002001c2cba5$ab641320$4437e183@fermi.win.fnal.gov>
@ 2003-02-03 22:56 ` Andrew Clausen
0 siblings, 0 replies; 9+ messages in thread
From: Andrew Clausen @ 2003-02-03 22:56 UTC (permalink / raw)
To: Jason Ormes; +Cc: linux-mips
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-02-03 22:56 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-22 7:30 debian's mips userland on mips64 Andrew Clausen
2003-01-22 17:45 ` Christoph Hellwig
2003-01-22 12:45 ` Ralf Baechle
2003-01-22 20:09 ` Christoph Hellwig
2003-01-23 3:05 ` Greg Banks
2003-01-23 5:04 ` Ralf Baechle
2003-01-22 21:47 ` Greg Lindahl
2003-01-28 7:00 ` Ralf Baechle
[not found] ` <002001c2cba5$ab641320$4437e183@fermi.win.fnal.gov>
2003-02-03 22:56 ` Andrew Clausen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.