Re: kern/51514: ptrace(2) fails for 32-bit process on 64-bit kernel

[Nick Hudson <skrll%netbsd.org@localhost>]

The following reply was made to PR kern/51514; it has been noted by GNATS.

From: Nick Hudson <skrll%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
 rokuyama%rk.phys.keio.ac.jp@localhost
Cc: 
Subject: Re: kern/51514: ptrace(2) fails for 32-bit process on 64-bit kernel
Date: Thu, 29 Sep 2016 14:24:23 +0100

 On 09/29/16 14:20, Rin Okuyama wrote:
 > The following reply was made to PR kern/51514; it has been noted by GNATS.
 >
 > From: Rin Okuyama <rokuyama%rk.phys.keio.ac.jp@localhost>
 > To: matthew green <mrg%eterna.com.au@localhost>, gnats-bugs%NetBSD.org@localhost
 > Cc:
 > Subject: Re: kern/51514: ptrace(2) fails for 32-bit process on 64-bit kernel
 > Date: Thu, 29 Sep 2016 22:18:47 +0900
 >
 >   Thank you very much for your comment.
 >   
 >   On 2016/09/29 2:49, matthew green wrote:
 >   > FWIW, you shouldn't ever have to extract things into /emul/netbsd32
 >   > anymore.  if you find issues that require it, please file PRs about
 >   > them.  eg, binaries should work in any location.
 >   
 >   Yes, I understand. My example was, somewhat, misleading. The location
 >   of 32-bit version of GDB, etc., is irrelevant to the problem.
 >   
 >   > the problem with your patch is that invades the main kernel with
 >   > comaptibility code that currently mostly works as a module.  it
 >   > really would be best to do this in compat/netbsd32 sources.
 >   
 >   I agree with you. But it is difficult, at least for me, to separate
 >   compatibility code from kern/sys_process.c.
 >   
 >   For sys_ptrace(9), the situation is similar to the case of
 >   copy_procargs(9) in kern/kern_proc.c, which has also compatibility
 >   code in it:
 >   
 >      https://nxr.netbsd.org/source/xref/src/sys/kern/kern_proc.c#2086
 >   
 >   The procedure is almost common for native and 32-bit processes, but
 >   just small parts are different. How do we separate compat code from
 >   functions like this?
 >   
 >   For process_{,fp}regs(9), the situation is more complicated as they
 >   are used not only by ptrace(2), but also by procfs.
 >   
 >   I do not, of course, stick to my patch. My hope is just to implement
 >   COMPAT_NETBSD32 support to ptrace(2); without it, we cannot use GDB
 >   on mips64 at the moment. I would greatly appreciate it if you kindly
 >   give me any suggestions.
 
 I'm working on this. Hopefully the rabbit hole isn't too deep.
 
 Nick