From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31208 invoked by alias); 5 Aug 2004 15:43: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 31193 invoked from network); 5 Aug 2004 15:43:20 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 5 Aug 2004 15:43: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 i75FhKe1002179 for ; Thu, 5 Aug 2004 11:43:20 -0400 Received: from zenia.home.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 i75FhDa07581; Thu, 5 Aug 2004 11:43:14 -0400 To: Andrew Cagney Cc: Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Provide dummy SSE registers in i387_supply_fsave References: <200408042102.i74L2Mhw016597@copland.kettenis.dyndns.org> <41123CCB.5040908@gnu.org> From: Jim Blandy Date: Thu, 05 Aug 2004 15:43:00 -0000 In-Reply-To: <41123CCB.5040908@gnu.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-08/txt/msg00119.txt.bz2 Andrew Cagney writes: > > Jim's patch to assert that target_fetch_registers did its job broke > > OpenBSD/i386 and probably most other i386 native debuggers. The > > attached patch fixes this. > > I am wondering however.how this affects other platforms and remote > > targets. > > Hmm, > > Jim, which systems did the assert patch get tested on? IA-32 and PowerPC Linux. i386-linux-nat.c:supply_fpregset calls dummy_sse_values, which provides the contents of the %xmm registers, which is what Mark ran into. This is the concern I was getting at in the first paragraph of the patch post: the assert is clearly a "fair" check on target_fetch_registers ("I asked you for this register, and you said 'okay'; were you telling the truth?") and it's clearly a condition developers would want to know about (using the contents of a register marked as not valid). But at the same time, it's easy to believe that there are lots of register sets in various architectures that have grown beyond the ability of some targets to fetch. If it's the case that many arch/target combinations will trigger the assert, then an assert is too aggressive, and it should probably be a warning instead. But silently supplying dummy bits is pretty unsatisfactory. As a developer, I wanted to know that regcache.c was happily fetching invalid contents. And as a user, I'd like something more than a suspicious bit pattern to tell me that a given register is unavailable.