Subject: ksh lossage on sparc64
To: None <tech-toolchain@NetBSD.ORG>
From: Martin Husemann <firstname.lastname@example.org>
Date: 11/19/2000 23:31:58
I analyzed the problem in PR port-sparc64/11506 a bit and came to the
conclusion that it's a bad volatile cast in the ksh source.
But then additional toolchain lossage strikes, and I couldn't reproduce it
with a small example. So here the real code:
RCS file: /cvsroot/basesrc/bin/ksh/jobs.c,v
retrieving revision 1.6
diff -r1.6 jobs.c
> volatile int * jstate = &j->state;
> char buf;
> sprintf(buf, "%p", jstate);
< while ((volatile int) j->state == PRUNNING
> while (*jstate == PRUNNING
< && (volatile int) j->state == PSTOPPED))
> && *jstate == PSTOPPED))
I would expect this to work. It crashes with a SIGSEGV, because "jstate" is
zero (according to gdb).
If I uncomment the meaningless sprintf block in above patch, it works.
Any ideas? I certainly don't want to commit that sprintf block ;-)
P.S.: Just pure speculation, but maybe the "sometimes ^C'ing make does not stop
sub-makes" maybe a similar (volatile cast related) effect in our make (but I
didn't look at the source yet).