From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16412 invoked by alias); 3 Oct 2011 21:10:48 -0000 Received: (qmail 16404 invoked by uid 22791); 3 Oct 2011 21:10:47 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Oct 2011 21:10:24 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 98C262BAFBC; Mon, 3 Oct 2011 17:10:23 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cIq3479oYGVY; Mon, 3 Oct 2011 17:10:23 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 57C902BAFAC; Mon, 3 Oct 2011 17:10:23 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id CC2BA145615; Mon, 3 Oct 2011 17:10:18 -0400 (EDT) From: Joel Brobecker To: gdb-patches@sourceware.org Cc: Joel Brobecker , Jan Kratochvil Subject: [RFA] fetch result of locdesc expressions as integer (not address) Date: Mon, 03 Oct 2011 21:10:00 -0000 Message-Id: <1317676214-7683-1-git-send-email-brobecker@adacore.com> 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: 2011-10/txt/msg00053.txt.bz2 This is a problem that showed up on AVR as well. The debugger crashes while trying to print the contents of any struct value. I was able to reduce the testcase as follow: % cat foo.c struct blob { int a; int b; }; struct blob global_blob = {1234, 5678}; int main (void) { global_blob.a++; /* Stop here */ return 0; } To reproduce: % gdb foo (gdb) target sim (gdb) load foo (gdb) start Starting program: /[...]/foo Temporary breakpoint 1, main () at foo.c:13 13 global_blob.a++; (gdb) p global_blob [SEGV] The problem is that the debugger is treating the result of the DWARF location expressions as addresses, whereas this is just an offset in this case. I think that this was an unintentional side-effect of simplifying the code that fetches the result from the DWARF expression computation stack. We had a bit of code that used to fetch it, and turn it into a struct value. And we replaced it by one call to a function that seemed to be doing the same: dwarf_expr_fetch_address. The problem is that dwarf_expr_fetch_address treats the result as an address, and thus applies the integer_to_address gdbarch method. We do not want that for struct field offsets... gdb/ChangeLog: * dwarf2read.c (decode_locdesc): Fetch the result of the expression evaluation as an integer rather than an address. Tested on x86_64-linux, no regression. Is that OK? Thanks, -- Joel --- gdb/dwarf2read.c | 14 +++++++++++++- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c index fc6a4d5..6f768a4 100644 --- a/gdb/dwarf2read.c +++ b/gdb/dwarf2read.c @@ -14175,7 +14175,19 @@ decode_locdesc (struct dwarf_block *blk, struct dwarf2_cu *cu) case DWARF_VALUE_MEMORY: case DWARF_VALUE_STACK: { - CORE_ADDR address = dwarf_expr_fetch_address (ctx, 0); + /* Fetch the result of the expression as an integer, + not as an address. We don't know whether it is an + address or not; for instance, it could be an expression + that returns the offset of a field inside a struct. + If we were to fetch the result as an address, we would + end up applying the integer_to_address gdbarch method. + That would be wrong in the case of an offset. */ + struct value *val = dwarf_expr_fetch (ctx, 0); + enum bfd_endian byte_order = gdbarch_byte_order (ctx->gdbarch); + CORE_ADDR address = + extract_unsigned_integer (value_contents (val), + TYPE_LENGTH (value_type (val)), + byte_order); do_cleanups (old_chain); return address; -- 1.7.1