From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25726 invoked by alias); 5 Aug 2004 09:54:01 -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 25654 invoked from network); 5 Aug 2004 09:53:59 -0000 Received: from unknown (HELO server7.nfra.nl) (192.87.1.57) by sourceware.org with SMTP; 5 Aug 2004 09:53:59 -0000 Received: from juw15.nfra.nl [10.87.8.15] by server7.nfra.nl; Thu, 05 Aug 2004 11:53:38 +0200 Received: from juw15.nfra.nl (localhost [127.0.0.1]) by juw15.nfra.nl (8.12.2+Sun/8.11.1) with ESMTP id i759qdCu010184; Thu, 5 Aug 2004 11:52:39 +0200 (CEST) Received: (from kettenis@localhost) by juw15.nfra.nl (8.12.2+Sun/8.12.2/Submit) id i759qXFK010181; Thu, 5 Aug 2004 11:52:33 +0200 (CEST) Date: Thu, 05 Aug 2004 09:54:00 -0000 Message-Id: <200408050952.i759qXFK010181@juw15.nfra.nl> From: Mark Kettenis To: jimb@redhat.com CC: drow@false.org, cagney@gnu.org, gdb@sources.redhat.com In-reply-to: (message from Jim Blandy on 04 Aug 2004 18:14:41 -0500) 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> X-SW-Source: 2004-08/txt/msg00062.txt.bz2 From: Jim Blandy Date: 04 Aug 2004 18:14:41 -0500 > > The next step is to have something that will recognize when a series > > of pieces is actually a reference to a single register --- presumably > > one that GDB has a number for, but one that Dwarf only has numbers for > > pieces of. That needs to be an arch method that recognizes the cases > > that can be simplified, and passes on the cases it can't handle. This > > will address all the current uses of DW_OP_piece, I believe. So we'll have to *temporary* add an arch method to several targets, and then remove it again when we fix things properly? I don't think that's a good idea. 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. Mark