From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23801 invoked by alias); 10 Apr 2003 13:30:43 -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 23787 invoked from network); 10 Apr 2003 13:30:42 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 10 Apr 2003 13:30:42 -0000 Received: from [192.168.1.34] (account dberlin HELO dberlin.org) by dberlin.org (CommuniGate Pro SMTP 4.1b2) with ESMTP-TLS id 3410079; Thu, 10 Apr 2003 09:30:41 -0400 Date: Thu, 10 Apr 2003 13:30: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: <9ED97922-6B58-11D7-A7F1-000393575BCC@dberlin.org> Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00096.txt.bz2 On Thursday, April 10, 2003, at 12:27 AM, 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. > Correct. > Is there any reason for this, or was it just an oversight? > The reason was that it was something that would be done *after* the initial patch was in (in order to keep the initial patch smaller). You know, like, say, now. :) --Dan