From: Petr Sorfa <petrs@caldera.com>
To: Jim Blandy <jimb@redhat.com>
Cc: Daniel Berlin <dan@dberlin.org>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Let dwarf2 CFI's execute_stack_op be used outside of CFI
Date: Tue, 02 Apr 2002 06:50:00 -0000 [thread overview]
Message-ID: <3CA9C6DC.12980657@caldera.com> (raw)
In-Reply-To: <npsn6knubd.fsf@zwingli.cygnus.com>
Hi Jim,
I've implemented a dwarf3 location expression parser for GDB. My
solution is, well, different than yours. I've gone for a more simpler
(limited) solution based on the existing dwarf2read.c decode_locdesc
function. It basically processes the location expression data passed to
through a "dwarf block" which contains the raw DWARF data block and it's
size.
Since GDB currently does not have an intermediate location expression
framework, I attach the dwarf blocks to relevant areas, such as:
struct general_symbol_info (for data location)
struct type (for array ranges (upper and lower bounds, stride),
associated and allocated expressions)
I understand that you are suggesting a more useful and generic solution
which can be detached from gdb completely.
Just letting you know the approach I took.
Petr
> I've read through the new Dwarf spec some more. You're right ---
> they've added a bunch of stuff like DW_OP_push_object_address and
> DW_OP_call, and cases where you're supposed to push stuff on the
> stack, etc.
>
> But what I'm going for here is something we could, in the long run,
> put in libiberty and just have GDB use from there. Surely there are
> other applications that could use a Dwarf expression interpreter.
>
> Would something like the below be sufficient? Rename to taste. (Feel
> free to say, "Yes, but that's way beyond what I offered to do." Also
> feel free to say, "You look like you're trying to write C++ programs
> in C.")
>
> struct dwarf_expr_context
> {
> /* The stack of values, allocated with xmalloc. */
> ADDR_TYPE *stack;
>
> /* The number of values currently pushed on the stack, and the
> number of elements allocated to the stack. */
> int stack_len, stack_allocated;
>
> /* The size of an address, in bits. */
> int addr_size;
>
> /* Return the value of register number REGNUM. */
> ADDR_TYPE (*read_reg) (void *baton, int regnum);
> void *read_reg_baton;
>
> /* Return the LEN-byte value at ADDR. */
> ADDR_TYPE (*read_mem) (void *baton, ADDR_TYPE addr, size_t len);
> void *read_mem_baton;
>
> /* Return the location expression for the frame base attribute. The
> result must be live until the current expression evaluation is
> complete. */
> unsigned char *(*get_frame_base) (void *baton);
> void *get_frame_base_baton;
>
> /* Return the location expression for the dwarf expression
> subroutine in the die at OFFSET in the current compilation unit.
> The result must be live until the current expression evaluation
> is complete. */
> unsigned char *(*get_subr) (void *baton, offset_t offset);
> void *get_subr_baton;
>
> /* Return the `object address' for DW_OP_push_object_address. */
> ADDR_TYPE (*get_object_address) (void *baton);
> void *get_object_address_baton;
>
> /* The current depth of dwarf expression recursion, via DW_OP_call*,
> DW_OP_fbreg, DW_OP_push_object_address, etc., and the maximum
> depth we'll tolerate before raising an error. */
> int recursion_depth, max_recursion_depth;
>
> /* Add whatever you want here; the caller is supposed to use
> new_dwarf_expr_context to make these, which can fill in default
> values. */
> };
>
> /* Return a new context, with no values on the stack. */
> struct dwarf_expr_context *new_dwarf_expr_context ();
>
> /* Free CONTEXT. */
> void free_dwarf_expr_context (struct dwarf_expr_context *context);
>
> /* Push VALUE on CONTEXT's stack. Reallocate the stack as needed. */
> void dwarf_expr_push (struct dwarf_expr_context *context, ADDR_TYPE value);
>
> /* Evaluate the LEN bytes at ADDR as a dwarf expression in CONTEXT. */
> void dwarf_expr_eval (struct dwarf_expr_context *context,
> unsigned char *addr, size_t len);
>
> /* Return the value N values down from the top of CONTEXT's stack.
> This raises an error if there aren't at least N+1 values on the stack. */
> ADDR_TYPE dwarf_expr_fetch (struct dwarf_expr_context *context, int n);
next prev parent reply other threads:[~2002-04-02 14:50 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
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 [this message]
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=3CA9C6DC.12980657@caldera.com \
--to=petrs@caldera.com \
--cc=dan@dberlin.org \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@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