From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28326 invoked by alias); 21 Sep 2009 03:48:20 -0000 Received: (qmail 28308 invoked by uid 22791); 21 Sep 2009 03:48:15 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Sep 2009 03:48:11 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8L3m9lK017666 for ; Sun, 20 Sep 2009 23:48:09 -0400 Received: from gateway.sf.frob.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n8L3m9cH014894; Sun, 20 Sep 2009 23:48:09 -0400 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 8432A357B; Sun, 20 Sep 2009 20:48:08 -0700 (PDT) Received: by magilla.sf.frob.com (Postfix, from userid 5281) id 46D0F13F35; Sun, 20 Sep 2009 20:48:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [rfc] Decode "is a variable with complex or multiple locations" (PR 8399) In-Reply-To: Jan Kratochvil's message of Sunday, 20 September 2009 22:51:09 +0200 <20090920205109.GA24360@host0.dyn.jankratochvil.net> References: <20090916201132.366872766@magilla.sf.frob.com> <20090920205109.GA24360@host0.dyn.jankratochvil.net> Message-Id: <20090921034808.46D0F13F35@magilla.sf.frob.com> Date: Mon, 21 Sep 2009 03:48:00 -0000 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: 2009-09/txt/msg00652.txt.bz2 > (gdb) info address val > Symbol "val" is a variable with multiple locations, for PC inclusive - exclusive: > 0x5157c9 - 0x5157e9: stored relative to frame base at offset -20 > 0x5157e9 - 0x5157f2: stored relative to register rsp at offset 60 > 0x5157f2 - 0x515835: stored relative to frame base at offset -20 > and optimized out in ranges not covered above. My hero! > (a) While it does what `info address' should do I think you (+me) wished more > just the single line valid for the current PC. Actually I think "info address" as it stands probably ought to print just the one for the current PC, that seems most consistent with what it does when it works. But there should be easy ways to get both the current location and all the locations for that name in the current scope, and I don't really care what the command syntax is for either of them. > This would do `info scope *$pc' but that one prints _all_ the visible > variables with no way how to request just one variable. To me it seems most usefully concise for "info scope *PC" to give only the locations that actually apply at PC, most of the time. (It would be dwimmy to have "info scope foo.c:23" or "info scope func" to make the constraint be all PCs that the expression implies as given, but I don't imagine that is what the natural division of labor makes straightforward to do.) As with info addr, clearly one wants both options available somehow. Perhaps: info addr sym <-- as above, all PCs for sym in current scope info addr sym *0x1234 <-- sym (resolved as per "scope *0x1234") location for 0x1234 only info scope *0x1234 <-- full details about locals in "scope *0x1234" info scope *0x1234 *0x1234 <-- those locals' locations at PC=0x1234 only > One IMO expects info on `struct value' (with its lvalue address incl. > registers) than on `struct dwarf2_locexpr_baton' (DWARF block content). I don't follow this part. > (b) It prints it in a human readable format so more complex expressions are still > not decoded. That wins for a huge majority of cases, I'm sure. The plain expression dump (as by readelf) would make me more than happy enough (though giving appropriate $names to the DWARF register operations would be spiffy), but I'd be satisfied enough for now with just a symfile name + hex DIE offset to tell me what DWARF to go decode myself. > (c) "a variable in register rsi" vs. "DW_OP_reg4": If you are printing things in DWARF-speak it is not really a big deal one way or the other to have register names vs numbers, just a nicety. The person reading this sort of output is already expected to grok DWARF magic. Whenever the whole story is explainable in human terms instead of DWARF-speak, that is clearly the better default feature. (Of course someone like me would always like more options to tell me precise DWARF bits, but I'm funny that way.) Thanks, Roland