From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4131 invoked by alias); 27 Apr 2017 15:50:15 -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 4108 invoked by uid 89); 27 Apr 2017 15:50:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=angle, Large, supposedly, row X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 27 Apr 2017 15:50:13 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BF61C80059; Thu, 27 Apr 2017 15:50:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BF61C80059 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com BF61C80059 Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 856D3890BA; Thu, 27 Apr 2017 15:50:11 +0000 (UTC) Subject: Re: [PATCH 4/4] Don't throw an error in 'info registers' for unavailable MIPS GP registers. To: "Maciej W. Rozycki" , John Baldwin References: <20170412183727.22483-1-jhb@FreeBSD.org> <4515312.rZ8DjEE4Ue@ralph.baldwin.cx> <17215390.QnBQOcfjcL@ralph.baldwin.cx> Cc: Luis Machado , gdb-patches@sourceware.org From: Pedro Alves Message-ID: <1ef9dbc1-4eca-789c-9eb6-23713f553de2@redhat.com> Date: Thu, 27 Apr 2017 15:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-04/txt/msg00742.txt.bz2 On 04/18/2017 10:33 PM, Maciej W. Rozycki 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.). 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? 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? (Or the column width could extended if there's an unavailable register, but I'm sort of trying to avoid suggesting a deeper change.) 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 I definitely agree that it'd be nice to make the generic code always print the columns neatly aligned. (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.) Thanks, Pedro Alves