Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: tromey@redhat.com
Cc: gdb-patches@sourceware.org
Subject: Re: FYI: fix big-endian bug with DWARF_VALUE_STACK
Date: Thu, 25 Feb 2010 20:44:00 -0000	[thread overview]
Message-ID: <201002252043.o1PKhxrd015529@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <m3zl2yvbo4.fsf@fleche.redhat.com> from "Tom Tromey" at Feb 24, 2010 09:30:35 AM

Tom Tromey wrote:
> >>>>> "Ulrich" == Ulrich Weigand <uweigand@de.ibm.com> writes:
> Ulrich> So it would seem to me that you should be able to request that
> Ulrich> this value be represented in any arbitrary length ...
> 
> That interpretation makes sense to me, but so does the one making it an
> error.  I suspect we will never run across code that exercises this.  If
> you want to change it, I have no objection.

I agree that it is unlikely code will exercises this, and I'm fine
with leaving the check in.  However, we should at least use the proper
DWARF address size (ctx->addr_size), as is used everywhere else where
the size of values on the DWARF stack is considered, instead of using
gdbarch_addr_bit, which really refers to GDB's internal representation
of target addresses ...

The patch below implements this change; tested on powerpc64-linux.
Does this look reasonable to you?

Bye,
Ulrich

ChangeLog:

	* dwarf2loc.c (struct piece_closure): Remove ARCH member,
	add ADDR_SIZE member.
	(allocate_piece_closure): Update.
	(copy_pieced_value_closure): Likewise.
	(dwarf2_evaluate_loc_desc): Likewise.
	(read_pieced_value): Use DWARF address size instead of
	GDB's gdbarch_addr_bit as size of values on the DWARF stack.


Index: gdb/dwarf2loc.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2loc.c,v
retrieving revision 1.72
diff -u -p -r1.72 dwarf2loc.c
--- gdb/dwarf2loc.c	23 Feb 2010 16:14:36 -0000	1.72
+++ gdb/dwarf2loc.c	25 Feb 2010 18:36:02 -0000
@@ -232,8 +232,8 @@ struct piece_closure
   /* The number of pieces used to describe this variable.  */
   int n_pieces;
 
-  /* The architecture, used only for DWARF_VALUE_STACK.  */
-  struct gdbarch *arch;
+  /* The target address size, used only for DWARF_VALUE_STACK.  */
+  int addr_size;
 
   /* The pieces themselves.  */
   struct dwarf_expr_piece *pieces;
@@ -244,12 +244,12 @@ struct piece_closure
 
 static struct piece_closure *
 allocate_piece_closure (int n_pieces, struct dwarf_expr_piece *pieces,
-			struct gdbarch *arch)
+			int addr_size)
 {
   struct piece_closure *c = XZALLOC (struct piece_closure);
 
   c->n_pieces = n_pieces;
-  c->arch = arch;
+  c->addr_size = addr_size;
   c->pieces = XCALLOC (n_pieces, struct dwarf_expr_piece);
 
   memcpy (c->pieces, pieces, n_pieces * sizeof (struct dwarf_expr_piece));
@@ -298,13 +298,12 @@ read_pieced_value (struct value *v)
 
 	case DWARF_VALUE_STACK:
 	  {
-	    size_t n;
-	    int addr_size = gdbarch_addr_bit (c->arch) / 8;
-	    n = p->size;
-	    if (n > addr_size)
-	      n = addr_size;
+	    struct gdbarch *gdbarch = get_type_arch (value_type (v));
+	    size_t n = p->size;
+	    if (n > c->addr_size)
+	      n = c->addr_size;
 	    store_unsigned_integer (contents + offset, n,
-				    gdbarch_byte_order (c->arch),
+				    gdbarch_byte_order (gdbarch),
 				    p->v.expr.value);
 	  }
 	  break;
@@ -377,7 +376,7 @@ copy_pieced_value_closure (struct value 
 {
   struct piece_closure *c = (struct piece_closure *) value_computed_closure (v);
   
-  return allocate_piece_closure (c->n_pieces, c->pieces, c->arch);
+  return allocate_piece_closure (c->n_pieces, c->pieces, c->addr_size);
 }
 
 static void
@@ -439,7 +438,8 @@ dwarf2_evaluate_loc_desc (struct symbol 
       struct piece_closure *c;
       struct frame_id frame_id = get_frame_id (frame);
 
-      c = allocate_piece_closure (ctx->num_pieces, ctx->pieces, ctx->gdbarch);
+      c = allocate_piece_closure (ctx->num_pieces, ctx->pieces,
+				  ctx->addr_size);
       retval = allocate_computed_value (SYMBOL_TYPE (var),
 					&pieced_value_funcs,
 					c);

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


  reply	other threads:[~2010-02-25 20:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-23 16:08 Tom Tromey
2010-02-23 16:16 ` Tom Tromey
2010-02-23 19:53 ` Ulrich Weigand
2010-02-23 20:26   ` Tom Tromey
2010-02-24 14:12     ` Ulrich Weigand
2010-02-24 14:20       ` Mark Wielaard
2010-02-24 16:10         ` Ulrich Weigand
2010-02-24 16:30       ` Tom Tromey
2010-02-25 20:44         ` Ulrich Weigand [this message]
2010-02-25 21:03           ` Tom Tromey
2010-02-26 12:50             ` Ulrich Weigand

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=201002252043.o1PKhxrd015529@d12av02.megacenter.de.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