NOMMU bogus syscall return values

[Dmitry V. Levin]

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.

> 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.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20160303/3c5d676a/attachment.bin>