Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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