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
