From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90788 invoked by alias); 28 Apr 2017 13:51:45 -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 90779 invoked by uid 89); 28 Apr 2017 13:51:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=row, informed, absolutely X-HELO: mail-wm0-f44.google.com Received: from mail-wm0-f44.google.com (HELO mail-wm0-f44.google.com) (74.125.82.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Apr 2017 13:51:43 +0000 Received: by mail-wm0-f44.google.com with SMTP id u65so42892008wmu.1 for ; Fri, 28 Apr 2017 06:51:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=fr3vYsav0PUBYR2xORBFaelbSO15NfhMjFpuOxLSVEY=; b=nPekHrbfq8J3Uk46hiYdnOllzxHb2tNMyLB7sqTQpnnf4Uij5g/F1TvtK11HVinE+P T4MRvcgxD6MaLe0+lz1QPtvWKEIdxKtk1YNEe/2CMnp86OTDvT3B8V7rsYZkw8bFG09e aIPYlNZrbWGAcQkLDW3bpSLUV+pPmOGJnFBP8YfS7xwG1N6qMFm6UbmatWzq6N2MUt+m Jx9Z1QoMHK3i2PCblPhK52Knp5ds22NmRSdjp7bTKV8cdTzFCHHMTl5sJHc6DP1vaAtY 5FhyIYNBBQH7TbUhgK0xqsCjZ1IR6rNBOI3pfR24Gc35AilljlKEqsKupxHv8HbSAWuD 8xFA== X-Gm-Message-State: AN3rC/73WThmSW4ZMwue1XF+ysFnricnnxvgkqO8Dm8uhhuBeJDhvXHQ 1P4eD2ojw80jMoRMOr/ajw== X-Received: by 10.28.158.216 with SMTP id h207mr5746030wme.0.1493387503662; Fri, 28 Apr 2017 06:51:43 -0700 (PDT) Received: from [192.168.0.102] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id z14sm2535870wmz.2.2017.04.28.06.51.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 06:51:42 -0700 (PDT) Subject: Re: [PATCH 4/4] Don't throw an error in 'info registers' for unavailable MIPS GP registers. To: "Maciej W. Rozycki" References: <20170412183727.22483-1-jhb@FreeBSD.org> <4515312.rZ8DjEE4Ue@ralph.baldwin.cx> <17215390.QnBQOcfjcL@ralph.baldwin.cx> <1ef9dbc1-4eca-789c-9eb6-23713f553de2@redhat.com> Cc: John Baldwin , Luis Machado , gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Fri, 28 Apr 2017 13:51: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/msg00772.txt.bz2 On 04/27/2017 08:37 PM, Maciej W. Rozycki wrote: > 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. I'm not sure that trying to come up with short variants of these special values manually is the best option. Another output you could see here is "". GDB prints that if GDB figures out the register is not saved in a frame (or if the DWARF indicates that, via DW_CFA_undefined). E.g., with the gdb.mi/mi-reg-undefined.exp testcase binary: (gdb) b stop_frame Breakpoint 1 at 0x40059a: file mi-reg-undefined.c, line 21. (gdb) r Breakpoint 1, stop_frame () at mi-reg-undefined.c:21 (gdb) up #1 0x00000000004005aa in first_frame () at mi-reg-undefined.c:26 26 in mi-reg-undefined.c (gdb) info registers rax ... We don't have any arch-independent test for this unfortunately. Maybe a two-pass approach where the first pass prints each register to a buffer to find the largest width, and then use that for column width would be more future proof. It's also work better if these magic values are ever translated (i18n). But TBC, I won't object whatever output you decide is best for MIPS, and I certainly don't want to impose extra work on John -- getting rid of that error call is the most important here. I'm just trying to expose a concern so you can have a more informed decision. > >> 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: OK. It wasn't actually obvious to me that each FP register was getting its own column. >> 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 I like how 10 years ago is considered recent. :-) Thanks, Pedro Alves