Re: [PATCH 1/2] alpha: Remove "strange" OSF/1 fork semantics

2014-07-31 Thread Michael Cree
On Wed, Jul 30, 2014 at 11:42:31AM -1000, Richard Henderson wrote: > The assignment to regs->r20 kills the original tls_val input > to the clone syscall, which means that clone can no longer be > restarted with the original inputs. > > We could, perhaps, retain this result for true fork, but OSF/1

Re: [PATCH 1/2] alpha: Remove "strange" OSF/1 fork semantics

2014-07-30 Thread Måns Rullgård
Richard Henderson writes: > On 07/30/2014 12:04 PM, Måns Rullgård wrote: >> Richard Henderson writes: >> >>> The assignment to regs->r20 kills the original tls_val input >>> to the clone syscall, which means that clone can no longer be >>> restarted with the original inputs. >>> >>> We could, p

Re: [PATCH 1/2] alpha: Remove "strange" OSF/1 fork semantics

2014-07-30 Thread Richard Henderson
On 07/30/2014 12:04 PM, Måns Rullgård wrote: > Richard Henderson writes: > >> The assignment to regs->r20 kills the original tls_val input >> to the clone syscall, which means that clone can no longer be >> restarted with the original inputs. >> >> We could, perhaps, retain this result for true f

Re: [PATCH 1/2] alpha: Remove "strange" OSF/1 fork semantics

2014-07-30 Thread Måns Rullgård
Richard Henderson writes: > The assignment to regs->r20 kills the original tls_val input > to the clone syscall, which means that clone can no longer be > restarted with the original inputs. > > We could, perhaps, retain this result for true fork, but OSF/1 > compatibility is no longer important.

[PATCH 1/2] alpha: Remove "strange" OSF/1 fork semantics

2014-07-30 Thread Richard Henderson
The assignment to regs->r20 kills the original tls_val input to the clone syscall, which means that clone can no longer be restarted with the original inputs. We could, perhaps, retain this result for true fork, but OSF/1 compatibility is no longer important. Note that glibc has never used the r2