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

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

The following reply was made to PR port-evbarm/57564; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Ramiro Aceves <ea1abz%gmail.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
	netbsd-bugs%netbsd.org@localhost, Martin Husemann <martin%duskware.de@localhost>,
	port-arm-maintainer%NetBSD.org@localhost, port-evbarm-maintainer%netbsd.org@localhost
Subject: Re: kern/57564 gdb netbsd.gdb and vfs_cache.o file
Date: Wed, 9 Aug 2023 09:45:35 +0000

 Very bizarre.  Here's the code in question that's failing:
 
    547          ncp =3D cache_lookup_entry(dvp, name, namelen, key);
    548          if (__predict_false(ncp =3D=3D 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?