From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Feb 2018 21:05:01 +0100 (CET) Received: from pio-pvt-msa3.bahnhof.se ([79.136.2.42]:41201 "EHLO pio-pvt-msa3.bahnhof.se" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23992923AbeBQUEvSq6wG (ORCPT ); Sat, 17 Feb 2018 21:04:51 +0100 Received: from localhost (localhost [127.0.0.1]) by pio-pvt-msa3.bahnhof.se (Postfix) with ESMTP id EC6B33F591; Sat, 17 Feb 2018 21:04:43 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bahnhof.se Received: from pio-pvt-msa3.bahnhof.se ([127.0.0.1]) by localhost (pio-pvt-msa3.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61WSqaUusy06; Sat, 17 Feb 2018 21:04:41 +0100 (CET) Received: from localhost.localdomain (h-155-4-135-114.NA.cust.bahnhof.se [155.4.135.114]) (Authenticated sender: mb547485) by pio-pvt-msa3.bahnhof.se (Postfix) with ESMTPA id E86DE3F4A4; Sat, 17 Feb 2018 21:04:34 +0100 (CET) Date: Sat, 17 Feb 2018 21:04:33 +0100 From: Fredrik Noring To: "Maciej W. Rozycki" Cc: =?utf-8?Q?J=C3=BCrgen?= Urban , linux-mips@linux-mips.org Subject: Re: [RFC v2] MIPS: R5900: Workaround exception NOP execution bug (FLX05) Message-ID: <20180217200432.GE2496@localhost.localdomain> References: <20180129202715.GA4817@localhost.localdomain> <20180211075608.GC2222@localhost.localdomain> <20180215191502.GA2736@localhost.localdomain> <20180217111644.GA2496@localhost.localdomain> <20180217133815.GB2496@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) 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: 62583 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: noring@nocrew.org 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 Maciej, > 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. Thank you for taking a closer look at GDB! However, I don't observe the "freebsd" BFD target with a cross-GDB version 8.1 (via v9fs in this case): # mipsel-linux-gdb --version | head -n1 GNU gdb (GDB) 8.1 # 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=0x8062c000'. #0 0x00000000 in ?? () (gdb) show gnutarget The current BFD target is "auto". (gdb) info files Local core dump file: `/mnt/kcore', file type elf32-tradlittlemips. 0xffffffffc0000000 - 0xfffffffffffcd000 is load1 0xffffffff80000000 - 0xffffffff80001000 is load2 0xffffffff80010000 - 0xffffffff82000000 is load3 (gdb) x /32i 0xffffffff80000000 0x80000000: Cannot access memory at address 0x80000000 (gdb) x /32i 0x80000000 0x80000000: Cannot access memory at address 0x80000000 (gdb) > 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. Perfect, thanks! By the way, what about presenting misaligned SQ instructions like # mipsel-linux-gdb -q busybox Reading symbols from busybox...(no debugging symbols found)...done. (gdb) set architecture mips:5900 The target architecture is assumed to be mips:5900 (gdb) x /i 0x4036b0 0x4036b0: sq v1,-6085(zero) as RDHWR, which is the interpretation with Linux? Fredrik