From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: brobecker@adacore.com (Joel Brobecker)
Cc: gdb-patches@sourceware.org,
brobecker@adacore.com (Joel Brobecker),
jan.kratochvil@redhat.com (Jan Kratochvil)
Subject: Re: [RFA] fetch result of locdesc expressions as integer (not address)
Date: Tue, 04 Oct 2011 19:32:00 -0000 [thread overview]
Message-ID: <201110041931.p94JVr9R028400@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <1317676214-7683-1-git-send-email-brobecker@adacore.com> from "Joel Brobecker" at Oct 03, 2011 02:10:14 PM
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
next prev parent reply other threads:[~2011-10-04 19:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-03 21:10 Joel Brobecker
2011-10-04 17:16 ` Tom Tromey
2011-10-04 19:32 ` Ulrich Weigand [this message]
2011-10-04 19:38 ` Joel Brobecker
2011-10-04 23:06 ` Ulrich Weigand
2011-10-05 1:09 ` Joel Brobecker
2011-10-05 12:30 ` Ulrich Weigand
2011-10-09 16:35 ` [patch#2] " Jan Kratochvil
2011-10-17 1:56 ` Joel Brobecker
2011-10-17 7:59 ` Tristan Gingold
2011-10-17 13:22 ` [commit] " Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201110041931.p94JVr9R028400@d06av02.portsmouth.uk.ibm.com \
--to=uweigand@de.ibm.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox