From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28207 invoked by alias); 10 Apr 2003 22:32:17 -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 28195 invoked from network); 10 Apr 2003 22:32:16 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 10 Apr 2003 22:32:16 -0000 Received: from [192.168.1.34] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.1b2) with ESMTP-TLS id 3420765; Thu, 10 Apr 2003 18:32:16 -0400 Date: Thu, 10 Apr 2003 22:32:00 -0000 Subject: Re: dwarf2read.c doesn't produce LOC_COMPUTED_ARG Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Daniel Jacobowitz , gdb@sources.redhat.com To: Jim Blandy From: Daniel Berlin In-Reply-To: Message-Id: <47CE37C7-6BA4-11D7-953E-000393575BCC@dberlin.org> Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00102.txt.bz2 On Thursday, April 10, 2003, at 06:16 PM, Jim Blandy wrote: > Daniel Jacobowitz writes: > >> On Wed, Apr 09, 2003 at 11:27:27PM -0500, Jim Blandy wrote: >>> >>> I just realized that dwarf2read.c will produce LOC_COMPUTED symbols, >>> but not LOC_COMPUTED_ARG symbols. The case for >>> DW_TAG_formal_parameter in new_symbol doesn't call >>> var_decode_location; it does what it's always done. >>> >>> Is there any reason for this, or was it just an oversight? >> >> It was just a lack of time, really. We've just recently got a PR >> about >> this too. After I check in the location lists patch I'll try to do >> LOC_COMPUTED_ARG. > > Okay. > > I'm glad to hear there wasn't some horrible reason it was going to be > impossible. Nope In fact, it's not that it's never been tried, either. I actually had code around to make LOC_COMPUTED_ARG in dwarf2 just to test the interface, it was simply omitted from the patches that went to gdb-patches (and to DanJ) to make them smaller. That said, I never regression tested that part of the patch, it was more of a "doesn't seem anything is egregiously wrong here" type thing to make sure i caught all the blatantly obvious cases. So don't be surprised if it breaks something subtle, but don't be worried it can't be done. :) > > I just had a rude awakening regarding why frame-base.[ch] > will be with us for at least as long as STABS and mdebug are...