From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29037 invoked by alias); 5 Aug 2004 14:31:13 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 29020 invoked from network); 5 Aug 2004 14:31:10 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 5 Aug 2004 14:31:10 -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 i75EV5e1014778 for ; Thu, 5 Aug 2004 10:31:05 -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 i75EUwa12377; Thu, 5 Aug 2004 10:30:58 -0400 To: Mark Kettenis Cc: drow@false.org, cagney@gnu.org, gdb@sources.redhat.com Subject: Re: interface to partial support for DW_OP_piece in dwarf2expr.[ch] References: <4111145F.7000504@gnu.org> <41112BAE dot 9080304 at gnu dot org> <41115B4F dot 1080700 at gnu dot org> <20040804230242 dot GA10332 at nevyn dot them dot org> <200408050952.i759qXFK010181@juw15.nfra.nl> From: Jim Blandy Date: Thu, 05 Aug 2004 14:31:00 -0000 In-Reply-To: <200408050952.i759qXFK010181@juw15.nfra.nl> 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/msg00070.txt.bz2 Mark Kettenis writes: > It seems worthwhile to me, because it will allow GDB to work > correctly, assignments and all, in the cases where the current value > structures can handle it, and it's very little work. At some point, > resources will materialize to do the larger project, but what's the > harm in getting the best behavior we can out of the current structures > until then? > > The harm is introducing hacks that are very hard to remove in the > feature. GDB is full of such hacks, and apart from Andrew nobody > seems to actively work on trying to remove these. We really don't > need any more of them. That is a good argument for not adding something. But this will be trivial to remove. You'll just delete it. Once 'struct value' can handle arbitrary piece lists, there will be no need to try to reduce Dwarf expression results to a simpler form. You'll instead have arch-independent code that takes any result of Dwarf location expression evaluation and produces an assignable value. Every case that the reduction arch method would handle will be supported by arch-independent code instead. So if the intermediate step of reducing piece lists we couldn't formerly handle to locations we could simply stops happening, there will be no visible change in behavior. We know the cases supported by the arch-independent code will be a superset of the cases supported by the arch-dependent reducer. The latter can only support cases that can be reduced to our current 'struct value', and the arch-independent implementation will extend that. Again, I don't see any need for GDB to be broken until the larger project is complete. GDB is broken for targets today that could use this reduction method.