On Thu, 19 Mar 1998, Jason Thorpe wrote:

> On Thu, 19 Mar 1998 09:04:28 +0000 (GMT) 
>  Alex Hayward <xelah@ferret.lmh.ox.ac.uk> wrote:
>  > You should also be aware that if you build a new ld.so it won't work and
>  > the the new vfork (the ___vfork14 systerm call) is *badly* broken on arm32
>  > systems. This means that anything which uses it (or, say, system()) causes
>  > the machine to lock up completely. You can fix that by changing the vfork
>  > line in unistd.h (change the rename from ___vfork14 to ___vfork13).
> 
> That is a bad way to "fix" the problem!  If it's _really_ broken, you should
> comment out the entire __RENAME() thing altogether!

Actually that seems to be what I've done... <ahem>. That'll teach me to
actually *read* my changes before I tell people about them :-)

> In any case, how is the new vfork(2) "*badly* broken"?  I never received
> any bug reports about it on the arm32... I'm skeptical, esp. considering
> that the requisite pmap changes were extremely minor, and indeed, the
> function necessary (pmap_activate()) already existed, and was in use my
> the machine-dependent fork code.

The machine just stops. (I mean badly in terms of results, not in terms of
source code, since I haven't looked at the source code and probably
wouldn't get far if I did...). The first I noticed was after installing a
new libc in which system called the new vfork. Thereafter man caused the
system to hang.

>  > Maybe I should start send-pr-ing these things...
> 
> You should always send-pr bugs.

But I'm always afraid I've done something silly in the build process...
Especially since this is the first time I've built any significant part of
-current (except for the kernel). I suppose I was looking for confirmation
first. OK, I'll check for anything obviously stupid and check its still
there in the latest sup and send-pr it...

-- 
alex@hayward.u-net.com; xelah@ferret.lmh.ox.ac.uk