NOMMU bogus syscall return values

[Rich Felker]

On Thu, Mar 03, 2016 at 05:16:18AM +0300, Dmitry V. Levin wrote:
> On Wed, Mar 02, 2016 at 08:28:30PM -0500, Rich Felker wrote:
> > On Thu, Mar 03, 2016 at 04:01:21AM +0300, Dmitry V. Levin wrote:
> > > On Mon, Feb 29, 2016 at 05:59:44PM -0500, Mike Frysinger wrote:
> > > > On 29 Feb 2016 15:56, Rich Felker wrote:
> > > [...]
> > > > > The attached (very hackish at the moment) patch makes it work for me
> > > > > by eliminating the need to define NOMMU_SYSTEM to 1 and using clone()
> > > > > with CLONE_VM and a new stack for the child, instead of vfork. I see
> > > > > some potential issues that need to be addressed before this could be
> > > > > made into a proper solution, though:
> > > > > 
> > > > > 1. I'm not sure if all NOMMU systems strace supports have clone. If
> > > > >    so, I think vfork could be dropped completely and this used
> > > > >    instead.
> > > > 
> > > > uClibc has long required clone, so seems safe to assume it exists
> > > 
> > > strace assumes that PTRACE_SETOPTIONS works, which essentially means that
> > > linux kernel >= 2.6 is required.  On some architectures, newer kernel is
> > > required (e.g. >= 2.6.15 on mips for PTRACE_GETREGS support).  I don't
> > > know for sure whether all supported NOMMU systems have CLONE_VM, but
> > > I agree with Mike it seems safe to assume they do.
> > 
> > I was merely unaware whether strace supported any non-Linux systems.
> > Linux has had clone/CLONE_VM since basically forever (2.0, maybe
> > earlier) so if strace is Linux-only this is a non-issue. Should I try
> > to prepare a patch converting all the forks to clone so that NOMMU is
> > not a special case?
> 
> Yes, the less NOMMU workarounds the better.

Sounds good. :) Although I wouldn't call it fewer NOMMU workarounds,
just fewer (no) special cases. This technique is still a NOMMU
workaround, but one that happens to work without any reduced
functionality on normal systems with MMU as well.

> > What should be done about daemonized tracer mode?
> 
> If we could switch stack before clone and then switch stack back in the
> child process, it would be a relatively simple change.
> Otherwise I don't see any simple options.

I think it's possible to switch stack in the parent via sigaltstack
and raise, after which the cloned child can longjmp back to the stack
that was the parent's. Alternatively the child could just re-enter
main() on a new stack with a global var set to indicate that it's the
tracer child.

Rich