From: Jim Blandy <jimb@redhat.com>
To: Andrew Cagney <cagney@gnu.org>
Cc: gdb@sources.redhat.com
Subject: Re: interface to partial support for DW_OP_piece in dwarf2expr.[ch]
Date: Wed, 04 Aug 2004 22:22:00 -0000 [thread overview]
Message-ID: <vt2pt66zgul.fsf@zenia.home> (raw)
In-Reply-To: <41115B4F.1080700@gnu.org>
Andrew Cagney <cagney@gnu.org> writes:
> > Andrew Cagney <cagney@gnu.org> writes:
> >
> >>>> > Andrew Cagney <cagney@gnu.org> writes:
> >>>> >
> >>>
> >>>>>> >>> I'm just having trouble getting my head around how this will affect
> >>>>>> >>> core-gdb, and seeing how this addresses our need to meet GCC 3.5's
> >>>>>> >>> requirements?
> >>>>>> >>> Can we expand on that?
> >>
> >>> ?
> > I answered this. The dwarf2.expr.h change I posted doesn't get into
> > GCC 3.5's requirements, and it shouldn't. It's just meant to allow
> > dwarf2expr.[ch] to return the results of the computation it did; it's
> > up to its caller what to do with that.
>
> Ok. Can we just expand a little on how/where the caller, core-gdb,
> will use this then?
Well, in the immediate term, dwarf2loc.c should simply reject
locations with pieces, and generate an error message. This is the
same behavior we have now, but instead of dwarf2expr.c saying
"Unrecognized opcode 0x93", dwarf2loc.c can say something more
informative like "The value of variable 'foo' is distributed across
several locations, and GDB cannot access its value."
The next step is to have something that will recognize when a series
of pieces is actually a reference to a single register --- presumably
one that GDB has a number for, but one that Dwarf only has numbers for
pieces of. That needs to be an arch method that recognizes the cases
that can be simplified, and passes on the cases it can't handle. This
will address all the current uses of DW_OP_piece, I believe.
In the long run, it's just as you said: there should be some kind of
'struct location' that 'struct value' can refer to, and that things
like value_fetch_lazy and value_assign understand and operate on. I
don't have a lot of insight into how that all ought to fit together.
But I don't think that affects the form of the best interface to
dwarf2expr.c: that should simply provide all the information it has,
and leave it to the caller to decide what to do with it.
next prev parent reply other threads:[~2004-08-04 22:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-03 7:15 Jim Blandy
2004-08-04 16:53 ` Andrew Cagney
[not found] ` <vt2fz7292z3 dot fsf at zenia dot home>
[not found] ` <41112BAE dot 9080304 at gnu dot org>
[not found] ` <vt2hdri4mi1 dot fsf at zenia dot home>
[not found] ` <41115B4F dot 1080700 at gnu dot org>
[not found] ` <vt2pt66zgul dot fsf at zenia dot home>
2004-08-04 18:26 ` Jim Blandy
2004-08-04 18:32 ` Andrew Cagney
2004-08-04 21:35 ` Jim Blandy
2004-08-04 21:55 ` Andrew Cagney
2004-08-04 22:22 ` Jim Blandy [this message]
2004-08-04 23:04 ` Daniel Jacobowitz
2004-08-04 23:17 ` Jim Blandy
2004-08-05 9:54 ` Mark Kettenis
2004-08-05 14:31 ` Jim Blandy
2004-08-05 16:27 ` Joel Brobecker
2004-08-05 18:45 ` Jim Blandy
2004-08-05 18:47 ` Daniel Jacobowitz
2004-08-05 19:56 ` Andrew Cagney
2004-08-05 20:36 ` Daniel Jacobowitz
2004-08-05 20:50 ` Andrew Cagney
2004-08-06 9:39 ` Eli Zaretskii
2004-08-10 19:55 ` Jim Blandy
2004-08-11 20:31 ` Jim Blandy
2004-08-11 20:33 ` Daniel Jacobowitz
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=vt2pt66zgul.fsf@zenia.home \
--to=jimb@redhat.com \
--cc=cagney@gnu.org \
--cc=gdb@sources.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