From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130163 invoked by alias); 18 Apr 2017 21:33:56 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 130094 invoked by uid 89); 18 Apr 2017 21:33:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=angle, minds, thoughts, proposition X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Apr 2017 21:33:54 +0000 Received: from HHMAIL01.hh.imgtec.org (unknown [10.100.10.19]) by Forcepoint Email with ESMTPS id 286B6E7887B09; Tue, 18 Apr 2017 22:33:48 +0100 (IST) Received: from [10.20.78.129] (10.20.78.129) by HHMAIL01.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.294.0; Tue, 18 Apr 2017 22:33:51 +0100 Date: Tue, 18 Apr 2017 21:33:00 -0000 From: "Maciej W. Rozycki" To: John Baldwin CC: Luis Machado , Subject: Re: [PATCH 4/4] Don't throw an error in 'info registers' for unavailable MIPS GP registers. In-Reply-To: <17215390.QnBQOcfjcL@ralph.baldwin.cx> Message-ID: References: <20170412183727.22483-1-jhb@FreeBSD.org> <4515312.rZ8DjEE4Ue@ralph.baldwin.cx> <17215390.QnBQOcfjcL@ralph.baldwin.cx> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2017-04/txt/msg00532.txt.bz2 On Mon, 17 Apr 2017, John Baldwin wrote: > > That needs to be fixed then. Previously there was no need to handle FIR > > specially. Overall we need to handle configurations without FPU as well. > > That might be true, but that is a larger patch (and it doesn't help with my > kernel target case where only a subset of GPRs are valid). Minimising changes is not our goal though, unlike making them correct. And I think we need to tell apart a situation where a register (FIR) is invalid according to the OS ABI and where a subset of registers may not always be accessible. > > I'm somewhat put off by the truncated message in the 32-bit case though > > -- unless a better proposition comes up, then how about using `xxxxxxxx' > > and `xxxxxxxxxxxxxxxx' for the 32-bit and 64-bit case respectively as with > > some previous effort? What do other target backends do? > > I don't disagree with the 32-bit format and am certainly open to other > options. Other architectures don't generally use a table and use the full > "" string, e.g. on a FreeBSD 64-bit x86 kernel (which uses the > "stock" method to print registers rather than a gdbarch-specific one): > > (kgdb) info registers > rax > rbx 0xfffff800085cb500 -8795952728832 > rcx > rdx > rsi > rdi > rbp 0xfffffe04674819c0 0xfffffe04674819c0 > rsp 0xfffffe0467481968 0xfffffe0467481968 > r8 > r9 > r10 > r11 > r12 0xffffffff80d43b00 -2133574912 > r13 0xfffff801fb2f3000 -8787583881216 > r14 0x0 0 > r15 0xffffffff80d43b00 -2133574912 > rip 0xffffffff8058bb12 0xffffffff8058bb12 > eflags > cs 0x20 32 > ss 0x28 40 > ds > es > fs > gs Thanks for checking that. NB I find output above quite messy, especially the lack of column alignment, e.g. `r14' vs `r15'. It makes it hard to read for me. I've given your proposal some thought and I'm of mixed minds between two possibilites I have come up with for the condensed format, specifically `xxxxxxxx' vs `', which I think are both suitable without being messy: (gdb) info registers zero at v0 v1 a0 a1 a2 a3 R0 00000000 fffffff8 77fde8cc 00000000 77ff0000 77fec458 7ffffbd4 7ffffbdc t0 t1 t2 t3 t4 t5 t6 t7 R8 c34e4bff ea5f612e 81010100 2f2f2f2f 7ffffce1 ffffffff f0000000 7ffff4e8 s0 s1 s2 s3 s4 s5 s6 s7 R16 78007010 00401360 xxxxxxxx xxxxxxxx xxxxxxxx 004f0000 00000063 0000006c t8 t9 k0 k1 gp sp s8 ra R24 77fdf64c 00401360 7ffff67c 00000000 78007010 7ffffbd0 00000061 77fcc97c status lo hi badvaddr cause pc 0100a413 008cbcee 00000006 77f83e90 00800024 00401360 fcsr fir restart 00000000 00f30000 00000000 (gdb) vs: (gdb) info registers zero at v0 v1 a0 a1 a2 a3 R0 00000000 fffffff8 77fde8cc 00000000 77ff0000 77fec458 7ffffbd4 7ffffbdc t0 t1 t2 t3 t4 t5 t6 t7 R8 c34e4bff ea5f612e 81010100 2f2f2f2f 7ffffce1 ffffffff f0000000 7ffff4e8 s0 s1 s2 s3 s4 s5 s6 s7 R16 78007010 00401360 004f0000 00000063 0000006c t8 t9 k0 k1 gp sp s8 ra R24 77fdf64c 00401360 7ffff67c 00000000 78007010 7ffffbd0 00000061 77fcc97c status lo hi badvaddr cause pc 0100a413 008cbcee 00000006 77f83e90 00800024 00401360 fcsr fir restart 00000000 00f30000 00000000 (gdb) The use of angle brackets with the latter variant is consistent with other targets, so I might have just a slight preference for it, but I'll be happy to accept input from other people. Where space is at disposal full `' could be printed, e.g: (gdb) info registers s3 s4 s5 s3: s4: s5: 0x4f0000 (gdb) or: (gdb) info registers zero at v0 v1 R0 0000000000000000 fffffffffffffff0 ffffffffc0000000 a0 a1 a2 a3 R4 0000000000000001 000000fffffffbb8 000000fffffffbc8 a4 a5 a6 a7 R8 0000000000000000 8101010101010100 2f2f2f2f2f2f2f2f t0 t1 t2 t3 R12 0000000000000000 0000000000000001 ffffffff8122f5d8 s0 s1 s2 s3 R16 000000fff8006000 0000000120000970 000000fff8006000 0000000000500000 s4 s5 s6 s7 R20 0000000000521ec8 0000000000522608 0000000000000000 0000000000000000 t8 t9 k0 k1 R24 000000000000161a 0000000120000970 0000000000000000 0000000000000000 gp sp s8 ra R28 000000fff8006000 000000fffffffbb0 0000000000000000 status lo hi badvaddr 0000000000109cf3 000000000d35ec75 0000000000000000 cause pc 0000000000800024 0000000120000970 fcsr fir restart 00000000 00f30000 0000000000000000 (gdb) Comments? Thoughts? Maciej