From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Feb 2018 16:08:07 +0100 (CET) Received: from 9pmail.ess.barracuda.com ([64.235.154.210]:58582 "EHLO 9pmail.ess.barracuda.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23992781AbeBQPH7v3tiC (ORCPT ); Sat, 17 Feb 2018 16:07:59 +0100 Received: from MIPSMAIL01.mipstec.com (mailrelay.mips.com [12.201.5.28]) by mx1412.ess.rzc.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Sat, 17 Feb 2018 15:07:52 +0000 Received: from [10.20.78.31] (10.20.78.31) by mips01.mipstec.com (10.20.43.31) with Microsoft SMTP Server id 14.3.361.1; Sat, 17 Feb 2018 07:03:17 -0800 Date: Sat, 17 Feb 2018 15:03:07 +0000 From: "Maciej W. Rozycki" To: Fredrik Noring CC: =?UTF-8?Q?J=C3=BCrgen_Urban?= , Subject: Re: [RFC v2] MIPS: R5900: Workaround exception NOP execution bug (FLX05) In-Reply-To: <20180217133815.GB2496@localhost.localdomain> Message-ID: References: <20171111160422.GA2332@localhost.localdomain> <20180129202715.GA4817@localhost.localdomain> <20180211075608.GC2222@localhost.localdomain> <20180215191502.GA2736@localhost.localdomain> <20180217111644.GA2496@localhost.localdomain> <20180217133815.GB2496@localhost.localdomain> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-BESS-ID: 1518880072-452060-19050-63649-3 X-BESS-VER: 2018.2.1-r1802152107 X-BESS-Apparent-Source-IP: 12.201.5.28 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.190127 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS59374 scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 62579 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@mips.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips 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