From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29068 invoked by alias); 4 Oct 2011 19:32:15 -0000 Received: (qmail 29059 invoked by uid 22791); 4 Oct 2011 19:32:14 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate1.uk.ibm.com (HELO mtagate1.uk.ibm.com) (194.196.100.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Oct 2011 19:31:59 +0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate1.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p94JVtUi023159 for ; Tue, 4 Oct 2011 19:31:55 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p94JVs5V2605064 for ; Tue, 4 Oct 2011 20:31:54 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p94JVsXZ028414 for ; Tue, 4 Oct 2011 13:31:54 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id p94JVr9R028400; Tue, 4 Oct 2011 13:31:53 -0600 Message-Id: <201110041931.p94JVr9R028400@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 04 Oct 2011 21:31:53 +0200 Subject: Re: [RFA] fetch result of locdesc expressions as integer (not address) To: brobecker@adacore.com (Joel Brobecker) Date: Tue, 04 Oct 2011 19:32:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, brobecker@adacore.com (Joel Brobecker), jan.kratochvil@redhat.com (Jan Kratochvil) In-Reply-To: <1317676214-7683-1-git-send-email-brobecker@adacore.com> from "Joel Brobecker" at Oct 03, 2011 02:10:14 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2011-10/txt/msg00112.txt.bz2 Joel Brobecker wrote: > 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. It seems the problem is a bit more complex: different callers of decode_locdesc have different expectations. As the comment before the routine says: NOTE drow/2003-11-18: This function is called in two situations now: for the address of static or global variables (partial symbols only) and for offsets into structures which are expected to be (more or less) constant. In the first of these situations, dwarf_expr_fetch_address is probably required on some architectures. Of course, in the second situation (which is the one you ran into), we need to treat the result as integer instead of address ... Maybe we ought to have two routines (or a parameter) here. [ In any case, from a quick look at the callers, some of those really want to evaluate DWARF expressions only, not generic location descriptions. But this distinction is mostly ignored in the rest of our DWARF code as well ... that should probably be cleaned up at some point. ] Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com