From: Jim Blandy <jimb@redhat.com>
To: Daniel Berlin <dan@dberlin.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI
Date: Mon, 01 Apr 2002 11:00:00 -0000 [thread overview]
Message-ID: <np7knrkzvx.fsf@zwingli.cygnus.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0203291959580.9698-100000@dberlin.org>
It may well be overengineered. A libdwarf is indeed what I had in
mind; I thought it might be nice to start putting together the pieces
for it.
Daniel Berlin <dan@dberlin.org> writes:
> In particular, you just need some initial value, or no initial value, not
> a push object address value/other types of things that may get pushed to
> the front.
Well, DW_AT_data_member_location expressions want the base address of
the innermost enclosing structure on the stack, whereas
DW_AT_use_location expressions want the pointer-to-member value and
the object's base address on the stack. So we've got situations which
need zero, one, and two values on the stack. So it seems like the
basic interface should let people push as much as they want.
> Also, why would something need our evaluator if they already knew how to
> read DIE's at a given offset? It's very likely they can also evaluate
> expressions if they can read DWARF2 at all.
Well, to share code, I guess. They'd toss their interpreter to use
ours, and spread the maintenance job around. I have no clients in
mind, just general principle. When we've got something whose behavior
is well-specified with no reference to GDB, it just seems like good
practice to produce an implementation that, likewise, is independent
of GDB.
> If, however, this is what GDB people want it to look like, i'll happily
> implement it. It's not like it'll be that much more work for me.
I'd approve it. :)
next prev parent reply other threads:[~2002-04-01 19:00 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-25 15:57 Daniel Berlin
2002-03-25 16:07 ` Andrew Cagney
2002-03-25 16:21 ` Daniel Berlin
2002-03-26 7:52 ` Daniel Berlin
2002-03-26 9:49 ` Andrew Cagney
2002-03-26 9:52 ` Daniel Berlin
2002-03-26 11:09 ` Daniel Berlin
2002-03-26 12:06 ` Andreas Jaeger
2002-03-26 17:59 ` Daniel Berlin
2002-03-27 0:09 ` Andreas Jaeger
2002-03-27 6:24 ` Andrew Cagney
2002-03-27 6:32 ` Andreas Jaeger
2002-03-26 18:06 ` Andrew Cagney
2002-03-27 20:56 ` Richard Stallman
2002-03-26 9:27 ` Andrew Cagney
2002-03-26 9:49 ` Daniel Berlin
2002-03-26 11:59 ` Jim Blandy
2002-03-26 13:42 ` Jim Blandy
2002-03-26 14:43 ` Daniel Berlin
2002-03-26 14:53 ` Andrew Cagney
2002-03-26 15:26 ` Daniel Berlin
2002-03-26 17:09 ` Andrew Cagney
2002-03-26 17:18 ` Daniel Berlin
2002-03-26 18:12 ` Andrew Cagney
2002-03-26 18:19 ` Andrew Cagney
2002-03-26 18:26 ` Daniel Berlin
2002-03-26 15:21 ` Jim Blandy
2002-03-26 19:17 ` Daniel Berlin
2002-03-28 13:12 ` Jim Blandy
2002-03-28 13:32 ` Daniel Berlin
2002-03-28 15:31 ` Jim Blandy
2002-03-29 17:06 ` Daniel Berlin
2002-04-01 11:00 ` Jim Blandy [this message]
2002-04-02 6:59 ` Daniel Berlin
2002-04-02 11:28 ` Jim Blandy
2002-04-02 11:31 ` Daniel Jacobowitz
2002-04-02 11:46 ` Daniel Berlin
2002-04-02 11:57 ` Daniel Jacobowitz
2002-04-02 13:12 ` Daniel Berlin
2002-04-02 13:15 ` Daniel Jacobowitz
2002-04-02 11:47 ` Daniel Berlin
2002-04-02 18:55 ` Daniel Berlin
2002-04-02 21:02 ` Daniel Jacobowitz
2002-04-03 13:05 ` Jim Blandy
2002-04-03 14:12 ` Daniel Berlin
2002-04-03 12:58 ` Stan Shebs
2002-04-03 18:59 ` Andrew Cagney
2002-04-02 6:50 ` Petr Sorfa
2002-04-02 6:56 ` Daniel Berlin
2002-04-02 8:19 ` [PATCH] Let dwarf2 CFI's execute_stack_op be used outside ofCFI Petr Sorfa
2002-04-04 12:24 ` [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI Daniel Berlin
2002-04-04 12:30 ` Daniel Jacobowitz
2002-04-04 13:11 ` Jim Blandy
2002-03-28 15:03 ` Andrew Cagney
2002-03-27 7:50 ` Petr Sorfa
2002-03-27 8:09 ` Daniel Berlin
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=np7knrkzvx.fsf@zwingli.cygnus.com \
--to=jimb@redhat.com \
--cc=dan@dberlin.org \
--cc=gdb-patches@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