From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2715 invoked by alias); 7 Aug 2004 16:13:21 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2700 invoked from network); 7 Aug 2004 16:13:20 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 7 Aug 2004 16:13:20 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i77GDEe3009040 for ; Sat, 7 Aug 2004 12:13:20 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i77GDCa27296; Sat, 7 Aug 2004 12:13:12 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 67ABC2B9D; Sat, 7 Aug 2004 12:13:06 -0400 (EDT) Message-ID: <4114FF92.7000300@gnu.org> Date: Sat, 07 Aug 2004 16:13:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040801 MIME-Version: 1.0 To: Ian Lance Taylor , Jim Blandy Cc: "Nathan J. Williams" , gdb-patches@sources.redhat.com Subject: Re: RFA: assert that target_fetch_registers did its job References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00200.txt.bz2 > Jim Blandy writes: > > >>> Perhaps another option would be something like the below: it informs >>> users that things are not as they seem, and encourages developers to >>> fix up their targets. Comments? I'll disable this while we sort things out. I've just hit another system (PPC/NetBSD) that panics. While requiring that the inferior always `supply' a register appears reasonable (and I agree with the theory) it turns out we don't have the mechanisms for indicating all the possible supplied register states (see below) and the implementors of the supply code didn't realise that was part of the contract :-( I think we can also just as effectively (and not as fatally :-) use the testsuite and something based on ``maint print cooked-registers'' (it will need to print state info) to detect mis-behaving inferior code. > Aren't users going to wind up getting this error message approximately > one gazillion times when doing debugging on a target which doesn't > provide all the registers? > > I don't know if this is the right approach in general, but if it is I > think it at least needs a static flag or something to only issue the > error once per execution. Here's a brain dump of the current situtation: A register, be it in the regcache or a frame, can have 4 states (I've listed the regcache states where applicable, the frame uses a flag `optimised out'): - invalid (0) Initial state, yet to probe for the register. - valid (1) The inferior was able to supply a full register value. - unsupported The register is not available on this system (due to limitations of the ptrace interface say). Yes, there currently isn't a state for this :-( - unknown (-1) For what ever reason, the the register isn't known at this point in time. (For CFI because it wasn't saved). When it comes to using these values, GDB ducks the issue. If an attempt to fetch a frame's register results in a memory problem, an error is thrown, if it results in an unknown/unsupported register, zero is silently returned. I think: - the register cache should just mark up the status of its registers and trust that the client will notice the problems - the frame code should detect unknown / unsupported register accesses and throw an error - the code displaying variables, using register values, should catch / incorporate such exceptions in their output vis: (gdb) print foo $1 = struct { string = , integer = , ...} however we've a ways to go before this happens. We've not even killed of deprecated_registers[]. Andrew