Re: [RFC v2] MIPS: R5900: Workaround exception NOP execution bug (FLX05)

["Maciej W. Rozycki" <macro@mips.com>]

Hi Fredrik,

> Both a (complete) remote copy of kcore, and one shared via v9fs, yield
> "Cannot access memory at address 0x80000000" with a cross-GDB, unfortunately:
> 
> > > One can get a little further by sharing /proc using v9fs to obtain:
> > > 
> > > 	# mipsel-linux-gdb -q -c /mnt/kcore
> > > 	[New process 1]
> > > 	Core was generated by `ramdisk_size=16384 crtmode=pal1 video=ps2fb:pal,640x480-32 rd_start=0x8063c000'.
> > > 	#0  0x00000000 in ?? ()
> > > 	(gdb) set architecture mips:5900
> > > 	The target architecture is assumed to be mips:5900
> > > 	(gdb) x /32i 0x80000000
> > > 	   0x80000000:	Cannot access memory at address 0x80000000
> 
> By examining the read operations for /proc/kcore, it seems GDB reaches this
> "cannot access" conclusion from the ELF headers.

 Hmm, whether it works or not seems to depend on GDB version.  It looks to 
me like we have a regression here.  Working GDB has:

(gdb) info files
Local core dump file:
        `/proc/kcore', file type elf32-tradlittlemips.
        0xffffffffc0000000 - 0xfffffffffff94000 is load1
        0xffffffff80000000 - 0xffffffff90000000 is load2
(gdb)

Broken GDB has:

(gdb) info files
Local core dump file:
        `/proc/kcore', file type elf32-tradlittlemips-freebsd.
        0xffffffffc0000000 - 0xfffffffffff94000 is load1
        0xffffffff80000000 - 0xffffffff90000000 is load2
(gdb)

Notice the different BFD target, `elf32-tradlittlemips-freebsd'.  You're 
supposed to be able to override it with `set gnutarget', but that doesn't 
seem to impress GDB, e.g.:

(gdb) show gnutarget
The current BFD target is "auto".
(gdb) set gnutarget elf32-tradlittlemips
(gdb) show gnutarget
The current BFD target is "elf32-tradlittlemips".
(gdb) info files
Local core dump file:
        `/home/mjr/src/kcore', file type elf32-tradlittlemips-freebsd.
        0xffffffffc0000000 - 0xfffffffffff94000 is load1
        0xffffffff80000000 - 0xffffffff90000000 is load2
(gdb)

I'll see if I can track down what is going on here.

> >  You need to use bus (physical) rather than virtual addresses with 
> > /dev/mem, so:
> > 
> > # xxd -s 0 -l 256 /dev/mem
> > 
> > or suchlike.
> 
> Ah, the value of the physical address was a misunderstanding on my part. The
> convoluted combination of mipsel-linux-objcopy and mipsel-linux-objdump gets
> the disassembly done without GDB, as shown below. :D
> 
> It looks very similar to yours, with additional NOPs and SYNCs required for
> the R5900:
> 
> 	# ssh ps2 head -c 128 /dev/mem >kcore &&
> 	    mipsel-linux-objcopy -I binary -O elf32-little kcore kcore.elf &&
> 	    mipsel-linux-objdump -D -m mips:5900 kcore.elf
> 	kcore.elf:     file format elf32-little
> 	Disassembly of section .data:
> 	00000000 <_binary_kcore_start>:
> 		...
> 	   8:	3c1b8061 	lui	k1,0x8061
> 	   c:	0000040f 	sync.p
> 	  10:	401a4000 	mfc0	k0,c0_badvaddr
> 	  14:	8f7b2c60 	lw	k1,11360(k1)
> 	  18:	001ad582 	srl	k0,k0,0x16
> 	  1c:	001ad080 	sll	k0,k0,0x2
> 	  20:	037ad821 	addu	k1,k1,k0
> 	  24:	0000040f 	sync.p
> 	  28:	401a2000 	mfc0	k0,c0_context
> 	  2c:	8f7b0000 	lw	k1,0(k1)
> 	  30:	001ad042 	srl	k0,k0,0x1
> 	  34:	335a0ff8 	andi	k0,k0,0xff8
> 	  38:	037ad821 	addu	k1,k1,k0
> 	  3c:	8f7a0000 	lw	k0,0(k1)
> 	  40:	8f7b0004 	lw	k1,4(k1)
> 	  44:	001ad142 	srl	k0,k0,0x5
> 	  48:	409a1000 	mtc0	k0,c0_entrylo0
> 	  4c:	0000040f 	sync.p
> 	  50:	001bd942 	srl	k1,k1,0x5
> 	  54:	409b1800 	mtc0	k1,c0_entrylo1
> 	  58:	0000040f 	sync.p
> 	  5c:	42000006 	tlbwr
> 	  60:	0000040f 	sync.p
> 	  64:	42000018 	eret
> 		...

 Good.  You probably want to add `--adjust-vma=0x80000000' to `objdump', 
so that addresses are right.  You can use `-b binary' with `objdump' too, 
to avoid the extra `objcopy' step.

  Maciej