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

[Rin Okuyama <rokuyama%rk.phys.keio.ac.jp@localhost>]

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.
 
 Thanks,
 Rin