From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75653 invoked by alias); 17 Apr 2017 18:27:46 -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 75617 invoked by uid 89); 17 Apr 2017 18:27:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=stock, HTo:U*macro X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Apr 2017 18:27:44 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 79FB710A7DB; Mon, 17 Apr 2017 14:27:44 -0400 (EDT) From: John Baldwin To: "Maciej W. Rozycki" Cc: Luis Machado , gdb-patches@sourceware.org Subject: Re: [PATCH 4/4] Don't throw an error in 'info registers' for unavailable MIPS GP registers. Date: Mon, 17 Apr 2017 18:27:00 -0000 Message-ID: <17215390.QnBQOcfjcL@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: References: <20170412183727.22483-1-jhb@FreeBSD.org> <4515312.rZ8DjEE4Ue@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00498.txt.bz2 On Saturday, April 15, 2017 11:06:35 PM Maciej W. Rozycki wrote: > On Sat, 15 Apr 2017, John Baldwin wrote: > > > > If the register is not ever supplied, then you need a target description > > > that does not include it. The rest of code will then handle it correctly. > > > > No, mips-tdep.c requires fir to be included in the description: > > > > static struct gdbarch * > > mips_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) > > { > > ... > > /* Check any target description for validity. */ > > if (tdesc_has_registers (info.target_desc)) > > { > > ... > > valid_p > > &= tdesc_numbered_register (feature, tdesc_data, > > mips_regnum.fp_implementation_revision, > > "fir"); > > > > if (!valid_p) > > { > > tdesc_data_cleanup (tdesc_data); > > return NULL; > > } > > > > ... > > } > > ... > > } > > 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). > > > Why can't the remaining general registers be read or written -- is that a > > > bug in the kernel? > > > > > > That sort of defeats the point of debugging, where you'd expect to be > > > able to poke at any register that is at debuggee's disposal (so not > > > supplying FIR can be considered a bug too). A program's variable could > > > live in such an inaccessible register for example. > > > > This isn't about the user thread state. When a user thread enters the kernel > > due to an exception, system call, etc. then all registers are saved and are > > available to the debugger. This is about debugging kernel threads in the kernel > > itself. During a context switch, only a subset of registers are explicitly > > saved in the thread's control block on FreeBSD (generally callee-save registers). > > Caller-save registers can be found by unwinding the stack. > > Fair enough. Such details have to be given in the patch description > itself though. Ok. I can give this as an example in the commit log. > 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 -- John Baldwin