Re: pkg/54192: lang/rust build error

[Kamil Rytarowski <n54%gmx.com@localhost>]

The following reply was made to PR toolchain/54192; it has been noted by GNATS.

From: Kamil Rytarowski <n54%gmx.com@localhost>
To: "gnats-bugs%NetBSD.org@localhost" <gnats-bugs%NetBSD.org@localhost>
Cc: 
Subject: Re: pkg/54192: lang/rust build error
Date: Wed, 16 Oct 2019 16:05:50 +0200

 On 16.10.2019 15:56, Kamil Rytarowski wrote:
 > On 16.10.2019 15:50, Martin Husemann wrote:
 >> Since it was not obvious to me, let me try to explain what happens:
 >>
 >> =C2=A0 - a multithreaded program calls fork()
 >> =C2=A0 - the forked child process only has a single lwp initially, wich=
  has
 >> lid 1
 >>
 >> So in the parent thread _lwp_self() (aka lid) was !=3D 1, and now in th=
 e
 >> child
 >> it has changed. Apparently something in ld.elf_so goes wrong later when
 >> using _lwp_self() =3D=3D 1 with a memory state inherited that was setup=
  for
 >> _lwp_self() !=3D 1.
 >>
 >> Joergs patch makes the single lwp inherit the lid from the forking pare=
 nt
 >> thread (instead of always being 1).
 >>
 >> Martin
 >>
 >
 > This is right behavior of the kernel.
 >
 > The same will happen on FreeBSD (lwpid is always unique globally), on
 > Linux (getpid is always unique) etc.
 >
 > If there is some assumption in NetBSD on copied lid, it's a bug in
 > ld.elf_so.
 
 Proof from FreeBSD:
 
 $ cat test.c
 #include <pthread.h>
 #include <string.h>
 #include <stdio.h>
 #include <unistd.h>
 
 #include <sys/thr.h>
 
 static long
 _lwp_self(void)
 {
 	long Tid;
 	thr_self(&Tid);
 	return Tid;
 }
 
 void *thread_main(void *arg) {
    printf("child %ld\n", _lwp_self());
    if (fork() =3D=3D 0) {
       char buf[20];
       snprintf(buf, sizeof(buf), "child %ld\n", _lwp_self());
       write(1, buf, strlen(buf));
       _exit(0);
    }
    return 0;
 }
 
 int main(void) {
    printf("%ld\n", _lwp_self());
    pthread_t thread;
    pthread_create(&thread, NULL, thread_main, NULL);
    pthread_join(thread, NULL);
 }
 
 $ ./a.out
 100123
 child 100126
 child 100119
 
 I am strongly against changing the correct NetBSD kernel behavior here.