From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4581 invoked by alias); 15 Apr 2017 17:36:53 -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 4561 invoked by uid 89); 15 Apr 2017 17:36:52 -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=HTo:U*macro, enters 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; Sat, 15 Apr 2017 17:36:50 +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 9845110A7DB; Sat, 15 Apr 2017 13:36:50 -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: Sat, 15 Apr 2017 17:36:00 -0000 Message-ID: <4515312.rZ8DjEE4Ue@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> <2093712.xnU824ggfa@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/msg00477.txt.bz2 On Saturday, April 15, 2017 05:02:23 PM Maciej W. Rozycki wrote: > On Fri, 14 Apr 2017, John Baldwin wrote: > > > > What is the output you're getting in this case? > > > > On FreeBSD (which doesn't support fir) I now get this: > > 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; } ... } ... } Thus, any target description that doesn't include fir is rejected. I will change FreeBSD to export fir via ptrace() and core dumps at some point, but it doesn't currently. 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); } > > It was more dire on a target that doesn't supply all registers. For example, > > I have an out of tree target for FreeBSD kernels and stopped threads in > > FreeBSD's kernel only supply a subset of GPRs. Without the patch examining > > registers for a stopped thread looks like this: > > 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. -- John Baldwin