From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50421 invoked by alias); 27 Apr 2017 19:38:11 -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 50388 invoked by uid 89); 27 Apr 2017 19:38:10 -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=essential, H*Ad:D*freebsd.org, overwhelms, row 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; Thu, 27 Apr 2017 19:38:08 +0000 Received: from HHMAIL01.hh.imgtec.org (unknown [10.100.10.19]) by Forcepoint Email with ESMTPS id 9D0A237A2993C; Thu, 27 Apr 2017 20:38:03 +0100 (IST) Received: from [10.20.78.155] (10.20.78.155) by HHMAIL01.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.294.0; Thu, 27 Apr 2017 20:38:05 +0100 Date: Thu, 27 Apr 2017 19:38:00 -0000 From: "Maciej W. Rozycki" To: Pedro Alves CC: John Baldwin , Luis Machado , Subject: Re: [PATCH 4/4] Don't throw an error in 'info registers' for unavailable MIPS GP registers. In-Reply-To: <1ef9dbc1-4eca-789c-9eb6-23713f553de2@redhat.com> Message-ID: References: <20170412183727.22483-1-jhb@FreeBSD.org> <4515312.rZ8DjEE4Ue@ralph.baldwin.cx> <17215390.QnBQOcfjcL@ralph.baldwin.cx> <1ef9dbc1-4eca-789c-9eb6-23713f553de2@redhat.com> 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/msg00751.txt.bz2 On Thu, 27 Apr 2017, Pedro Alves wrote: > > 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. > > FWIW, I'd find using anything but when that's what > GDB means to be making the port be gratuitously different. > "" always means the same thing in gdb -- gdb knows > the value materially exists, but it can't get at it for some > reason (e.g., ptrace does not expose it, a core dump is trimmed, value > not collect in a trace frame, etc.). If you think keeping the word the same across ports is essential, then `' would be my second choice, at some aesthetical cost. > Also, I'm not absolutely sure I'm following the code correctly, but ISTM > that the current mips table printing code can already print strings larger > than unavailable, like "" in mips_print_fp_register? For obvious reasons FP registers are formatted differently: (gdb) info all-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 0051e008 00516188 005161c8 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 f0: 0x7ff80000 flt: nan dbl: nan f1: 0x7ff80000 flt: nan f2: 0x7ff80000 flt: nan dbl: nan f3: 0x7ff80000 flt: nan f4: 0x7ff80000 flt: nan dbl: nan f5: 0x7ff80000 flt: nan f6: 0x7ff80000 flt: nan dbl: nan f7: 0x7ff80000 flt: nan f8: 0x7ff80000 flt: nan dbl: nan f9: 0x7ff80000 flt: nan f10: 0x7ff80000 flt: nan dbl: nan f11: 0x7ff80000 flt: nan f12: 0x7ff80000 flt: nan dbl: nan f13: 0x7ff80000 flt: nan f14: 0x7ff80000 flt: nan dbl: nan f15: 0x7ff80000 flt: nan f16: 0x7ff80000 flt: nan dbl: nan f17: 0x7ff80000 flt: nan f18: 0x7ff80000 flt: nan dbl: nan f19: 0x7ff80000 flt: nan f20: 0x7ff80000 flt: nan dbl: nan f21: 0x7ff80000 flt: nan f22: 0x7ff80000 flt: nan dbl: nan f23: 0x7ff80000 flt: nan f24: 0x7ff80000 flt: nan dbl: nan f25: 0x7ff80000 flt: nan f26: 0x7ff80000 flt: nan dbl: nan f27: 0x7ff80000 flt: nan f28: 0x7ff80000 flt: nan dbl: nan f29: 0x7ff80000 flt: nan f30: 0x7ff80000 flt: nan dbl: nan f31: 0x7ff80000 flt: nan fcsr fir restart 00000000 00f30000 00000000 (gdb) so there's enough space for unusual interpretations. > I also noticed that there's code in print_gp_register_row that handles > printing large registers separately: > > if (mips_float_register_p (gdbarch, regnum)) > break; /* End the row: reached FP register. */ > /* Large registers are handled separately. */ > if (register_size (gdbarch, regnum) > mips_abi_regsize (gdbarch)) > { > ... > /* Print this register on a row by itself. */ > > supposedly to avoid column misalignment. Maybe registers could > be printed on a row by themselves too? Hmm, I've investigated the origin of this piece and it has turned out to be quite recent in MIPS port's history, introduced as a hack with commit 0cc93a06b3ed ("Avoid MIPS port breakage on large registers"), , to handle the artificial $restart register, which is always printed last (and as such doesn't break output formatting in a considerable way). See the justification downthread and TBH I wouldn't let this change in if I were asked to approve it today. Instead I would request to implement it like I did for $fcsr and $fir with commit 78b86327b530 ("mips-tdep: Make FCRs always 32-bit") -- though there's something fishy going on there anyway as we (still) do not have proper support in place for a debug scenario where the ptrace(2) caller has been built for an ABI different from the debuggee's ABI -- and the problem is on the kernel side. Though by choosing the ptrace(2) syscall number matching the debuggee's ABI (there's one for each) I think it would be avoided; but then there's no libc support for doing that. So this is not a path I want to follow; I'd rather drop this piece of code and handle the case of $restart correctly. > Note that while the mips table format is more compact, the generic > format has the advantage that is prints symbol information, like: > > >> rip 0xffffffff8058bb12 0xffffffff8058bb12 With 32 GPRs + HI/LO + PC (which are the minimum subset of architectural registers available to user mode software) that does not fit in a standard 80x24 terminal and IMHO overwhelms the reader with a flood of information -- which I believe is also the reason why FPRs are not shown by default. > (Maybe the ideal would be if the generic code learned about MIPS compact > format and users could pick the format they want with a format switch > like "info register /c" or some such. But again, that'd be a larger > change which I'd not like to require.) That sounds to me like an idea worth considering, assuming that the current target-specific defaults are retained. Maciej