From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78674 invoked by alias); 15 Apr 2017 22:07:02 -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 76583 invoked by uid 89); 15 Apr 2017 22:07:01 -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=enters, ack 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; Sat, 15 Apr 2017 22:06:59 +0000 Received: from HHMAIL01.hh.imgtec.org (unknown [10.100.10.19]) by Forcepoint Email with ESMTPS id 2657EB6E5F35B; Sat, 15 Apr 2017 23:06:54 +0100 (IST) Received: from [10.20.78.105] (10.20.78.105) by HHMAIL01.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.294.0; Sat, 15 Apr 2017 23:06:57 +0100 Date: Sat, 15 Apr 2017 22:07: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: <4515312.rZ8DjEE4Ue@ralph.baldwin.cx> Message-ID: References: <20170412183727.22483-1-jhb@FreeBSD.org> <2093712.xnU824ggfa@ralph.baldwin.cx> <4515312.rZ8DjEE4Ue@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/msg00482.txt.bz2 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. > Note that Linux doesn't supply a valid fir from core dumps either (it just > hardcodes it as zero): > > linux-mips-tdep.c: > > void > mips_supply_fpregset (struct regcache *regcache, > const mips_elf_fpregset_t *fpregsetp) > { > ... > char zerobuf[MAX_REGISTER_SIZE]; > > memset (zerobuf, 0, MAX_REGISTER_SIZE); > ... > > /* FIXME: how can we supply FCRIR? The ABI doesn't tell us. */ > regcache_raw_supply (regcache, > mips_regnum (gdbarch)->fp_implementation_revision, > zerobuf); > } Ack. > > 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. 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? Maciej