Re: kern/57564 gdb netbsd.gdb and vfs_cache.o file

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

Very bizarre.  Here's the code in question that's failing:

   547          ncp = cache_lookup_entry(dvp, name, namelen, key);
   548          if (__predict_false(ncp == NULL)) {
   549                  rw_exit(&dvi->vi_nc_lock);
   550                  COUNT(ncs_miss);

    1084:       ebfffc3c        bl      17c <cache_lookup_entry>
/home/ramiro/cvs/src/sys/arch/evbarm/compile/MYKERNEL/../../../../kern/vfs_cache.c:548
    1088:       e2507000        subs    r7, r0, #0
    108c:       0a0000bf        beq     1390 <cache_lookup+0x3e4>
...
cache_lookup():
/home/ramiro/cvs/src/sys/arch/evbarm/compile/MYKERNEL/../../../../kern/vfs_cache.c:549
    1390:       e1a00009        mov     r0, r9
    1394:       ebfffffe        bl      0 <rw_exit>
                        1394: R_ARM_CALL        rw_exit
armreg_tpidrprw_read():
/home/ramiro/cvs/src/sys/arch/evbarm/compile/MYKERNEL/./arm/armreg.h:909
    1398:       ee1d7f90        mrc     15, 0, r7, cr13, cr0, {4}
    139c:       ee1d3f90        mrc     15, 0, r3, cr13, cr0, {4}
KPREEMPT_DISABLE():
/home/ramiro/cvs/src/sys/arch/evbarm/compile/MYKERNEL/../../../../sys/lwp.h:544
    13a0:       e1570003        cmp     r7, r3
    13a4:       1a0000e7        bne     1748 <cache_lookup+0x79c>

cache_lookup+0x79c is followed shortly by the call to kern_assert
whose return address cache_lookup+0x7c0 is what appeared on the stack,
confirming that this is the assertion that tripped.

curlwp is implemented by the mrc instruction.  What's really amazing
is that these consecutive mrc instructions appear to yield different
results, which I don't think is supposed to happen!  Yet somehow it's
only here that the result is corrupted, not in other places?