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.