From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: tromey@redhat.com (Tom Tromey)
Cc: gdb-patches@sourceware.org
Subject: Re: RFC: implement typed DWARF stack
Date: Thu, 05 May 2011 18:07:00 -0000 [thread overview]
Message-ID: <201105051807.p45I7F7C009704@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <m3tydayyzq.fsf@fleche.redhat.com> from "Tom Tromey" at May 04, 2011 02:47:21 PM
Tom Tromey wrote:
> This patch converts the DWARF expression evaluator to use GDB's value
> types. This approach made it easy to support floating point and also
> decimal floating point; and also paves the way for any future
> improvements.
Huh, so value_binop is back after I eliminated it :-)
http://sourceware.org/ml/gdb-patches/2010-06/msg00514.html
Due to the use of value_as_address in dwarf_expr_fetch_address, this
patch actually ought to still work on the SPU ... I'll do a test.
> There is some ugliness involving signed and unsigned types; this arises
> because "old-style" untyped DWARF values don't have a consistent type.
> Also I needed a little bit of special code to handle logical right
> shifts.
Yes, I'm wondering whether old-style values are handled correctly. We
used to make sure all arithmetic is performed in ctx->addr_size bits
(which is taken from the DWARF section headers). With your patch,
we now always use gdbarch_dwarf2_addr_size -- I'm not sure this is
always the same.
Also, what is the reason for handling the conversion to unsigned so
differently in the DW_OP_mod vs. DW_OP_shr cases?
+ /* We have to special-case "old-style" untyped values
+ -- these must have mod computed using unsigned
+ math. */
+ if (value_type (first) == address_type)
+ {
+ first = value_cast (uaddress_type, first);
+ second = value_cast (uaddress_type, second);
+ }
vs.
+ dwarf_require_integral (value_type (first));
+ dwarf_require_integral (value_type (second));
+ if (!TYPE_UNSIGNED (value_type (first)))
+ {
+ struct type *utype
+ = get_unsigned_type (ctx->gdbarch, value_type (first));
+
+ first = value_cast (utype, first);
+ }
[ In fact, maybe we don't need the whole value_cast business and we could
just operate on ULONGEST without involving value_binop, since both cases
only support integers anyway ... ]
> - dwarf_expr_push (ctx, initial, initial_in_stack_memory);
> + dwarf_expr_push (ctx, value_from_ulongest (dwarf_expr_address_type (ctx, 1),
> + initial),
> + initial_in_stack_memory);
I'd rather see a dwarf_expr_push_address to keep the address-type abstraction
local to dwarf2expr.c ...
> case DW_OP_bra:
> - offset = extract_signed_integer (op_ptr, 2, byte_order);
> - op_ptr += 2;
> - if (dwarf_expr_fetch (ctx, 0) != 0)
> - op_ptr += offset;
> - dwarf_expr_pop (ctx);
> + {
> + struct value *val;
> +
> + offset = extract_signed_integer (op_ptr, 2, byte_order);
> + op_ptr += 2;
> + val = dwarf_expr_fetch (ctx, 0);
> + dwarf_require_integral (value_type (val));
Does DW_OP_bra really require an integral type on the stack? The standard
wording isn't 100% clear to me here ...
> + case DW_OP_GNU_const_type:
> + {
> + ULONGEST type_die;
> + int n;
> + const gdb_byte *data;
> + struct type *type;
> +
> + op_ptr = read_uleb128 (op_ptr, op_end, &type_die);
> + n = *op_ptr++;
> + data = op_ptr;
> + op_ptr += n;
> +
> + type = dwarf_get_base_type (ctx, type_die, n);
> +
> + /* Note that the address does not matter, since there is
> + no way to fetch it. */
> + result_val = value_from_contents_and_address (type, data, 0);
I guess a non_lval value would still seem cleaner here (just as done
below for DW_OP_GNU_reinterpret --- maybe this could be abstracted
into a new value_from_contents helper).
> @@ -182,7 +189,7 @@ struct dwarf_expr_piece
>
> /* The piece's register number or literal value, for
> DWARF_VALUE_REGISTER or DWARF_VALUE_STACK pieces. */
> - ULONGEST value;
> + struct value *value;
Maybe now it would be cleaner to split this into two union members,
a plain "int regnum" for DWARF_VALUE_REGISTER, and the struct value
for DWARF_VALUE_STACK ...
Otherwise this looks good to me.
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-05-05 18:07 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-04 20:48 Tom Tromey
2011-05-05 16:47 ` Tom Tromey
2011-05-05 18:07 ` Ulrich Weigand [this message]
2011-05-05 18:38 ` Tom Tromey
2011-05-05 20:15 ` Tom Tromey
2011-05-09 22:02 ` Ulrich Weigand
2011-05-10 14:15 ` Tom Tromey
2011-05-11 0:15 ` Ulrich Weigand
2011-05-11 14:59 ` Tom Tromey
2011-05-11 19:44 ` Tom Tromey
2011-05-12 0:03 ` Ulrich Weigand
2011-05-12 16:33 ` Tom Tromey
2011-05-13 7:52 ` Regression: " Jan Kratochvil
2011-05-13 15:44 ` Tom Tromey
2011-05-15 8:26 ` gdbindex crash: " Jan Kratochvil
2011-05-16 17:37 ` Tom Tromey
2011-05-17 17:01 ` Tom Tromey
2011-05-13 17:17 ` Tom Tromey
2011-05-13 17:34 ` Jan Kratochvil
2011-05-12 19:32 ` Tom Tromey
2011-05-16 15:50 ` Ulrich Weigand
2011-05-16 18:09 ` Tom Tromey
2011-05-17 8:35 ` Jakub Jelinek
2011-06-03 13:52 ` Tom Tromey
2011-05-10 16:39 ` Tom Tromey
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=201105051807.p45I7F7C009704@d06av02.portsmouth.uk.ibm.com \
--to=uweigand@de.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@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