Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: gdb-patches@sourceware.org
Subject: [RFA][1/5] New port: Cell BE SPU (dwarf2loc.c fix)
Date: Sat, 11 Nov 2006 18:37:00 -0000	[thread overview]
Message-ID: <200611111837.kABIbcwQ031159@d12av02.megacenter.de.ibm.com> (raw)

Hello,

this fixes a problem in dwarf2loc.c that triggers for the SPU port.

The code in dwarf_expr_read_reg currently expects that in order to
retrieve an address value from a register, it's OK to assume the
address can always be extracted using extract_unsigned_integer
on the full size of the register.

This fails on the SPU, because all registers are 16 bytes wide, and
a pointer is represented by simply using the uppermost 4 bytes and
ignoring the contents of the remaining 12 bytes.  I would assume
that there's also other architectures where the assumption in 
dwarf_expr_read_reg might fail, e.g. due to sign extension issues
or other required fiddling.

So, to fix this I thought that we already *know* how to extract
values of a certain type from a register: value_from_register does
just that, and provides all sorts of configurability for the back
end to have it just do the right thing.  Since the value retrieved
by dwarf_expr_read_reg is always a pointer to some data object 
(normally on the stack), it should be OK to get it by using
value_from_register (builtin_type_void_data_ptr, ...).

This is what the patch below does, and it works fine on SPU.
Additionally tested without regressions on s390-ibm-linux and
s390x-ibm-linux.

OK?

Bye,
Ulrich

	* dwarf2loc.c (dwarf_expr_read_reg): Use value_from_register to
	retrieve address from register.


diff -ur gdb-orig/gdb/dwarf2loc.c gdb-head/gdb/dwarf2loc.c
--- gdb-orig/gdb/dwarf2loc.c	2006-11-10 03:00:22.000000000 +0100
+++ gdb-head/gdb/dwarf2loc.c	2006-11-11 18:16:58.663849888 +0100
@@ -115,23 +115,23 @@
 /* Helper functions for dwarf2_evaluate_loc_desc.  */
 
 /* Using the frame specified in BATON, return the value of register
-   REGNUM, treated as an unsigned integer.  */
+   REGNUM, treated as a pointer.  */
 static CORE_ADDR
 dwarf_expr_read_reg (void *baton, int dwarf_regnum)
 {
   struct dwarf_expr_baton *debaton = (struct dwarf_expr_baton *) baton;
+  struct value *value;
   CORE_ADDR result;
-  gdb_byte *buf;
-  int regnum, regsize;
+  int regnum;
 
   regnum = DWARF2_REG_TO_REGNUM (dwarf_regnum);
-  regsize = register_size (current_gdbarch, regnum);
-  buf = alloca (regsize);
 
-  frame_register_read (debaton->frame, regnum, buf);
-  /* NOTE: cagney/2003-05-22: This extract is assuming that a DWARF 2
-     address is always unsigned.  That may or may not be true.  */
-  result = extract_unsigned_integer (buf, regsize);
+  value = value_from_register (builtin_type_void_data_ptr,
+			       regnum, debaton->frame);
+
+  result = value_as_address (value);
+  release_value (value);
+  value_free (value);
 
   return result;
 }
-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


             reply	other threads:[~2006-11-11 18:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-11 18:37 Ulrich Weigand [this message]
2006-11-13 19:40 ` Jim Blandy
2006-11-15 21:57   ` Ulrich Weigand
2006-11-22  1:42     ` Jim Blandy
2006-11-22  2:30       ` Daniel Jacobowitz
2006-11-22 14:10       ` 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=200611111837.kABIbcwQ031159@d12av02.megacenter.de.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=gdb-patches@sourceware.org \
    /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