From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15093 invoked by alias); 22 Sep 2014 19:21:00 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 15080 invoked by uid 89); 22 Sep 2014 19:21:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 22 Sep 2014 19:20:59 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8MJKnxb018822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 22 Sep 2014 15:20:49 -0400 Received: from host2.jankratochvil.net (ovpn-116-67.ams2.redhat.com [10.36.116.67]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8MJKjxX027254 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Mon, 22 Sep 2014 15:20:47 -0400 Date: Mon, 22 Sep 2014 19:21:00 -0000 From: Jan Kratochvil To: Eli Zaretskii Cc: yao@codesourcery.com, gdb@sourceware.org Subject: Re: Complex DWARF expressions Message-ID: <20140922192044.GA25256@host2.jankratochvil.net> References: <83sijkydk4.fsf@gnu.org> <87a95sxkjr.fsf@codesourcery.com> <20140922061654.GA15537@host2.jankratochvil.net> <83a95ry0rp.fsf@gnu.org> <20140922184412.GA23523@host2.jankratochvil.net> <838ulbxyo9.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <838ulbxyo9.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00074.txt.bz2 On Mon, 22 Sep 2014 21:06:30 +0200, Eli Zaretskii wrote: > Are you saying that whenever GDB can successfully interpret this > information and extract a value, it simply shows that value? Yes. > If so, I think we should add to the DWARF gobbledygook a note to the effect > that GDB wasn't able to glean the value from that info, and maybe even say > why (like what info was missing to interpret that). + > We should say explicitly that GDB is unable to decypher the data, > otherwise what we show the user looks like a teaser. I find the current behavior the right one myself. There is "info addr" exactly for the cases of debugging GDB/GCC and/or disassembling inferior code trying to extract as much information from the crashed state as possible. Sure feel free to propose any UI changes for GDB. Maybe "set debug entry-values" could be placed under more user friendly "info ..." command but then its output would have to be improved from the current set of scattered debug messages to something more formatted. > If the computation is expensive, we could have an option to enable it. > There are situations in debugging when you'd kill to know the value of > some key variable, I'm sure you know this. There is no reduction of reported info just to save some GDB computations. GDB reports all it can. In general lacking debug info is usually GCC's defect and not GDB's. > And btw, how did you get the information you showed, like this: > > > <8><1663ca>: Abbrev Number: 24 (DW_TAG_GNU_call_site) > > <1663cb> DW_AT_low_pc : 0x814d44f > > <1663cf> DW_AT_abstract_origin: <0x15e7bc> > > <9><1663d8>: Abbrev Number: 3 (DW_TAG_GNU_call_site_parameter) > > <1663d9> DW_AT_location : 1 byte block: 52 (DW_OP_reg2 (edx)) > > <1663db> DW_AT_GNU_call_site_value: 1 byte block: 30 (DW_OP_lit0) > > Can GDB show it (and if so, by which command), or is this from objdump > or some such? I use "readelf -wi" myself, this is equivalent to "objdump -Wi" for non-ELF DWARF files. There is also "eu-readelf -winfo" with slightly different output formatting. Jan