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: Thu, 28 Mar 2002 13:12:00 -0000 [thread overview]
Message-ID: <np4rj0pfam.fsf@zwingli.cygnus.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0203262201390.13327-100000@dberlin.org>
Daniel Berlin <dan@dberlin.org> writes:
> I didn't want to deal with the issue of whether we want to return a struct
> value, and the issue of how best to keep track of whether it's in memory
> or a register, without getting an opinion first.
I spoke with Andrew on the phone yesterday, and he and I have
different ideas about how things should go. I don't think I
understood the path of changes he wanted to see.
My personal inclination is to make the Dwarf 2 location expression
interpreter as independent from GDB as possible. It can use the
CORE_ADDR type for stack elements, but it should take arguments
specifying:
- the expression as a simple char * pointer and length,
- the architecture's address size,
- function pointers for reading memory and registers that simply hand
back a CORE_ADDR value (thus keeping the interpreter innocent of
endianness issues), and
- the frame base address (for DW_OP_fbreg)
It should return a structure that says whether the location expression
specified a particular register (i.e., DW_OP_reg0 and friends) or an
address. Actually, the return value should be a list of pieces, each
of which gives a byte length and then a register or address.
But I tend to think it shouldn't take a struct frame_info or struct
context, and it shouldn't return a struct value. Sure, you'll need
more glue code than you would if it took just the right arguments for
the use we have in mind, but keeping it as innocent of GDB as possible
makes the interface easier to understand: you don't need to wonder how
it interacts with a frame's saved registers, how it finds the frame
base, and so on. You can look at the code and say, "Ah, this doesn't
worry about any of that." There's a simple test for the module
boundaries: if a behavior is described in the Dwarf spec chapter on
location expressions, it should be inside; otherwise, it should be
outside. And once you've written frame/struct value glue code,
everyone can use that and nobody minds.
What a lot of hand-waving. Sorry. Hopefully you'll see what I'm
getting at.
next prev parent reply other threads:[~2002-03-28 21:12 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 [this message]
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
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=np4rj0pfam.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