From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18450 invoked by alias); 20 Apr 2010 19:03:19 -0000 Received: (qmail 18371 invoked by uid 22791); 20 Apr 2010 19:03:18 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Apr 2010 19:03:11 +0000 Received: (qmail 25353 invoked from network); 20 Apr 2010 19:03:09 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 20 Apr 2010 19:03:09 -0000 Message-ID: <4BCDFA67.2030404@codesourcery.com> Date: Tue, 20 Apr 2010 19:03:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: tromey@redhat.com CC: Stan Shebs , "gdb-patches@sourceware.org" Subject: Re: [PATCH] Dwarf location expressions, tracing and printing References: <4BC7B823.6040406@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00627.txt.bz2 Tom Tromey wrote: >>>>>> "Stan" == Stan Shebs writes: >>>>>> > > Stan> Perhaps the most interesting part is that I finally got tired of > Stan> working blind and filled out description location functions, so > Stan> now both "info scope" and "info address" have quite a lot of say > Stan> about variables. Try things like "info scope > Stan> handle_inferior_event" to get some truly awesome verbiage. :-) > > Thanks, I think this is great. > > I think Jan had a similar patch that would enable disassembling the > DWARF expression. I'm not sure what happened to that; it seems like > something that would at least be useful when working on gdb or other > parts of the toolchain. > What I did is not quite the same thing, in that it restricts itself to interpreting location expressions, and tries to do it in a user-intelligible way, no opcodes shown. But yeah, we could use more display power; with dwarf things being so data-driven, GDB backtrace alone isn't that useful. Stan