Re: Does anyone use xterm on NetBSD/m68k 7.0?

[mlelstv%serpens.de@localhost (Michael van Elst)]

okuyama%flex.phys.tohoku.ac.jp@localhost (Rin Okuyama) writes:

>On 2015/11/09 3:37, Michael van Elst wrote:
>> but the parent process didn't fail.

>Hmm, that's strange. Any ideas?

Looks like I missed an indirection for prepareq which is ok.

This here is from the parent process before entering fork():

prepareq
$a5+0x560c: 0x0e4dbf78
0xe4dbf78:      0x0e4e76e0 (first)
0xe4dbf7c:      0x0e4e76e0 (last)

0xe4e76e0:      0x00000000 (next)
0xe4e76e4:      0x0e4687b8 (fn)

parentq
$a5+0x5618: 0x0e4dbf70
0xe4dbf70:      0x0e6020a8 (first)
0xe4dbf74:      0x0e6020a8 (last)

0xe6020a8:      0x00000000 (next)
0xe6020ac:      0x0e468792 (fn)

childq
$a5+0x5b6c: 0x0e4dbf68
0xe4dbf68:      0x0e6020b0 (first)
0xe4dbf6c:      0x0e6020b0 (last)

0xe6020b0:      0x137c54e0 (next)
0xe6020b4:      0x42f1bfa0 (fn)

You see that the damaged data is different from the previous attempt
and every run will show different data.

Tracing reveals that the location is trashed by arc4random_uniform():

#0  0x0e49e906 in memcpy () from /usr/lib/libc.so.12
#1  0x0e468f2a in ?? () from /usr/lib/libc.so.12
#2  0x0e468fc6 in ?? () from /usr/lib/libc.so.12
#3  0x0e469222 in ?? () from /usr/lib/libc.so.12
#4  0x0e4695a6 in arc4random_uniform () from /usr/lib/libc.so.12
#5  0x0e42afca in __gettemp () from /usr/lib/libc.so.12
#6  0x0e3ee8c6 in mkdtemp () from /usr/lib/libc.so.12
#7  0x0002a24a in init_colored_cursor ()
#8  0x0003ec8a in main ()

arc4random_uniform
-> arc4random_prng_get (0xe469088)
   -> arc4random_prng_addrandom (0xe468f68)
      -> crypto_prng_buf (0xe468ea6)
         -> memcpy (0xe3e23c4)

This is arc4random.c:329

        (void)memcpy(prng->state, output, sizeof prng->state);
prng->state = 0x0e6020b0
output = 0x1dffe3a8
sizeof prng->state = 0x00000020

The wrong prng->state pointer however is already passed to
arc4random_prng_addrandom as a result of thr_getspecific().

   0xe469146:   movel %a2@(24),%sp@-
   0xe46914a:   bsrl 0xe3ded64 <__libc_thr_getspecific@plt>
   0xe469150:   addql #4,%sp
   0xe469152:   tstl %a0
   0xe469154:   bnew 0xe46920c

__libc_thr_getspecific however points to _Xthr_zero_stub_.

   0xe280788 <_Xthr_zero_stub_>:        linkw %fp,#0
   0xe28078c <_Xthr_zero_stub_+4>:      clrl %d0
   0xe28078e <_Xthr_zero_stub_+6>:      unlk %fp
   0xe280790 <_Xthr_zero_stub_+8>:      rts

This is a no-threading hack in libX11:

#pragma weak pthread_getspecific = _Xthr_zero_stub_
static int
_Xthr_zero_stub_()
{
    return(0);
}

Since that function is declared as returning an int, only register d0
is set, but a function returning a pointer must use register a0 for
the return value as defined by the m68k ABI.

The broken code can be found in xsrc/external/mit/libX11/src/UIThrStubs.c.
As we already provide no-thread compatibility functions in libc (with
a working pthread_getspecific implementation) it might also help to
get rid of this UIThrStubs nonsense.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."