From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32498 invoked by alias); 2 Apr 2002 14:56:38 -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 32490 invoked from network); 2 Apr 2002 14:56:36 -0000 Received: from unknown (HELO dberlin.org) (64.246.6.106) by sources.redhat.com with SMTP; 2 Apr 2002 14:56:36 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by dberlin.org (8.11.6/8.11.6) with ESMTP id g32EuYm04346; Tue, 2 Apr 2002 09:56:34 -0500 Date: Tue, 02 Apr 2002 06:56:00 -0000 From: Daniel Berlin To: Petr Sorfa cc: Jim Blandy , Subject: Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI In-Reply-To: <3CA9C6DC.12980657@caldera.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-04/txt/msg00020.txt.bz2 On Tue, 2 Apr 2002, Petr Sorfa wrote: > Hi Jim, > > I've implemented a dwarf3 location expression parser for GDB. My > solution is, well, different than yours. I've gone for a more simpler > (limited) solution based on the existing dwarf2read.c decode_locdesc > function. It basically processes the location expression data passed to > through a "dwarf block" which contains the raw DWARF data block and it's > size. I'm curious why you reimplemented this approach. If you look back to last year, you'll note I sent something that does exactly this, to gdb-patches. I never got around to attach dwarf blocks to types, because Andrew wanted it more independent of DWARF2. You probably could have saved a lot of time in writing his stuff, which is why i'm curious. --Dan