From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6385 invoked by alias); 22 Sep 2014 19:06:43 -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 6375 invoked by uid 89); 22 Sep 2014 19:06:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout29.012.net.il Received: from mtaout29.012.net.il (HELO mtaout29.012.net.il) (80.179.55.185) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 22 Sep 2014 19:06:41 +0000 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NCB00H00H154K00@mtaout29.012.net.il> for gdb@sourceware.org; Mon, 22 Sep 2014 22:06:11 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NCB00BLAH2A9950@mtaout29.012.net.il>; Mon, 22 Sep 2014 22:06:10 +0300 (IDT) Date: Mon, 22 Sep 2014 19:06:00 -0000 From: Eli Zaretskii Subject: Re: Complex DWARF expressions In-reply-to: <20140922184412.GA23523@host2.jankratochvil.net> To: Jan Kratochvil Cc: yao@codesourcery.com, gdb@sourceware.org Reply-to: Eli Zaretskii Message-id: <838ulbxyo9.fsf@gnu.org> References: <83sijkydk4.fsf@gnu.org> <87a95sxkjr.fsf@codesourcery.com> <20140922061654.GA15537@host2.jankratochvil.net> <83a95ry0rp.fsf@gnu.org> <20140922184412.GA23523@host2.jankratochvil.net> X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00073.txt.bz2 > Date: Mon, 22 Sep 2014 20:44:12 +0200 > From: Jan Kratochvil > Cc: yao@codesourcery.com, gdb@sourceware.org > > On Mon, 22 Sep 2014 20:21:14 +0200, Eli Zaretskii wrote: > > Why can't GDB apply all this, and show a value for a given PC? > > There is some reason why GDB could not determine it, this is very normal > situation. It would be really great if GDB could always display all values > for -O2 -g code but that can never be possible (without reducing runtime code > peformance and size). Are you saying that whenever GDB can successfully interpret this information and extract a value, it simply shows that value? 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). 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. 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? > For example the call site may not have matching DW_AT_GNU_call_site_value > because the value is just no longer computable at the caller frame from any > data at that point of execution. Entry values improved the number of cases > where the value is retrievable but it is still far from 100% retrievability. We should say explicitly that GDB is unable to decypher the data, otherwise what we show the user looks like a teaser. > One needs to use -O0 -g to get the values in 100% of cases. When I'm debugging a crash of an optimized binary, and don't yet have a recipe to reproduce the crash, compiling without optimizations is not a useful option. Thanks.