ptrace single-stepping change breaks Wine

[Mike Hearn]

Context: this is not about ptrace stuff, but rather Thomas Sailors
original problem which seems to be flex-mmap related.

On Fri, 2004-12-31 at 16:51 +0100, Thomas Sailer wrote:
> On Freitag 31 Dezember 2004 14.31, Mike Hearn wrote:
> 
> > What about this patch?
> 
> This works now. Happy new year...

I'm afraid Alexandre has decided not to apply this patch (the ABI
personality syscall). His reasoning is as follows:

- There are a million kernel patches out there which use the ABI 
  personality system to break stuff, which means that realistically
  we have no idea what it does

- Therefore, using it would be a big support problem as it may
  even switch off stuff (new features etc) we want, so this system
  doesn't really scale

- It'd be a lot better to provide a "disable this mmap
  feature/behaviour" flag for each thing that changes it, or *even*
  better to make it opt-in as having to change the sources to make
  old apps work again kind of defeats the point of backwards
  compatibility (ie, old apps should continue to work as-is)

- Another possibility would be to create a new mmap API that lets
  us ask for exactly what we want, instead of second-guessing the
  kernel. I don't know exactly what sort of an API Alexandre has in
  mind here, perhaps he could describe it.

- So rather than apply the patch, we have to figure out why 
  flex-mmap is breaking this program and add yet more magic VM code
  to stop it from happening :(

Could you upload a +relay,+tid,+seh,+msgbox trace somewhere please? Of
course if you could investigate it yourself that'd be the best thing.

I wasn't sure whether to CC some kernel people or not, but it seems from
previous threads that the ABI personality syscall system is meant for
people like us who are trying to keep "legacy" binaries working.
Unfortunately this sort of unbreak-me-please flag isn't really what we
need/want from the kernel.

Also a precise description of what flex-mmap does would be good. Google
wasn't too informative, best I could get was that it means mmap
allocates from the "top" of the address space down. But where is the top
exactly?

thanks -mike