public inbox for archer-commits@sourceware.org
help / color / mirror / Atom feed
From: tromey@sourceware.org
To: archer-commits@sourceware.org
Subject: [SCM]  tromey/gcc-pr-55608-fallout: automatically dereference synthetic pointers when printing
Date: Tue, 14 May 2013 17:46:00 -0000	[thread overview]
Message-ID: <20130514174646.18151.qmail@sourceware.org> (raw)

The branch, tromey/gcc-pr-55608-fallout has been updated
  discards  936cb089be1cb6f79063fd3b4200a6ac9d74db4e (commit)
  discards  047bd5a85ec05c3e757ae54b2ec0f0b3bcb69d94 (commit)
       via  d8869b0d5043736df641eccb3743a95b1a5a51ee (commit)
       via  eaf69d968852d383fc3dcd9c75c5bcda9aa8cd92 (commit)
      from  936cb089be1cb6f79063fd3b4200a6ac9d74db4e (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email.

- Log -----------------------------------------------------------------
commit d8869b0d5043736df641eccb3743a95b1a5a51ee
Author: Tom Tromey <tromey@redhat.com>
Date:   Wed Mar 27 10:49:54 2013 -0600

    automatically dereference synthetic pointers when printing
    
    This automatically dereferences synthetic pointers when printing.
    However it has weird effects sometimes:
    
    (gdb) p c
    $2 = (byte *) <synthetic pointer> No frame selected.
    
    and doesn't print strings properly yet
    
    (gdb) p c
    $1 = (byte *) <synthetic pointer> 114 'r'

commit eaf69d968852d383fc3dcd9c75c5bcda9aa8cd92
Author: Tom Tromey <tromey@redhat.com>
Date:   Tue Apr 23 11:45:11 2013 -0600

    Fix PR symtab/15391
    
    PR symtab/15391 is a failure with the DW_OP_GNU_implicit_pointer
    feature.
    
    I tracked it down to a logic error in read_pieced_value.  The code
    truncates this_size_bits according to the type size and offset too
    early -- it should do it after taking bits_to_skip into account.
    
    This patch fixes the bug.
    
    While testing this, I also tripped across a latent bug because
    indirect_pieced_value does not sign-extend where needed.  This patch
    fixes this bug as well.
    
    Finally, Pedro pointed out that a previous version implemented sign
    extension incorrectly.  This version introduces a new gdb_sign_extend
    function for this.  A couple of notes on this function:
    
    * It has the gdb_ prefix to avoid clashes with various libraries that
      felt free to avoid proper namespacing.  There is a "sign_extend"
      function in a Tile GX header, in an SOM-related BFD header (and in
      sh64-tdep.c and as a macro in arm-wince-tdep.c, but those are
      ours...)
    
    * I looked at all the sign extensions in gdb and didn't see ones that
      I felt comfortable converting to use this function; in large part
      because I don't have a good way to test the conversion.
    
    Built and regtested on x86-64 Fedora 18.  New test cases included;
    this required a minor addition to the DWARF assembler.  Note that the
    DWARF CU made by implptrpiece.exp uses a funny pointer size in order
    to show the sign-extension bug on all platforms.
    
    	* dwarf2loc.c (read_pieced_value): Truncate this_size_bits
    	after taking bits_to_skip into account.  Sign extend byte_offset.
    	* utils.h (gdb_sign_extend): Declare.
    	* utils.c (gdb_sign_extend): New function.
    
    	* gdb.dwarf2/implptrpiece.exp: New file.
    	* gdb.dwarf2/implptrconst.exp (d): New variable.
    	Print d.
    	* lib/dwarf2.exp (Dwarf::_location): Handle DW_OP_piece.

-----------------------------------------------------------------------

Summary of changes:
 gdb/dwarf2loc.c |    9 ++-------
 gdb/utils.c     |   17 +++++++++++++++++
 gdb/utils.h     |    5 +++++
 3 files changed, 24 insertions(+), 7 deletions(-)

First 500 lines of diff:
diff --git a/gdb/dwarf2loc.c b/gdb/dwarf2loc.c
index 7beb927..bb600d1 100644
--- a/gdb/dwarf2loc.c
+++ b/gdb/dwarf2loc.c
@@ -2093,13 +2093,8 @@ indirect_pieced_value (struct value *value)
      sign-extend it manually as appropriate.  */
   byte_offset = value_as_address (value);
   if (TYPE_LENGTH (value_type (value)) < sizeof (LONGEST))
-    {
-      LONGEST nbits = 8 * TYPE_LENGTH (value_type (value));
-      LONGEST m1 = -1;
-
-      if (((byte_offset >> (nbits - 1)) & 1) != 0)
-	byte_offset |= m1 << nbits;
-    }
+    byte_offset = gdb_sign_extend (byte_offset,
+				   8 * TYPE_LENGTH (value_type (value)));
   byte_offset += piece->v.ptr.offset;
 
   gdb_assert (piece);
diff --git a/gdb/utils.c b/gdb/utils.c
index 218faed..aeb4242 100644
--- a/gdb/utils.c
+++ b/gdb/utils.c
@@ -3233,6 +3233,23 @@ align_down (ULONGEST v, int n)
   return (v & -n);
 }
 
+/* See utils.h.  */
+
+LONGEST
+gdb_sign_extend (LONGEST value, int bit)
+{
+  gdb_assert (bit >= 1 && bit <= 8 * sizeof (LONGEST));
+
+  if (((value >> (bit - 1)) & 1) != 0)
+    {
+      LONGEST signbit = ((LONGEST) 1) << (bit - 1);
+
+      value = (value ^ signbit) - signbit;
+    }
+
+  return value;
+}
+
 /* Allocation function for the libiberty hash table which uses an
    obstack.  The obstack is passed as DATA.  */
 
diff --git a/gdb/utils.h b/gdb/utils.h
index ad5bea4..0c423a8 100644
--- a/gdb/utils.h
+++ b/gdb/utils.h
@@ -377,4 +377,9 @@ extern int myread (int, char *, int);
 extern ULONGEST align_up (ULONGEST v, int n);
 extern ULONGEST align_down (ULONGEST v, int n);
 
+/* Sign extend VALUE.  BIT is the (1-based) index of the bit in VALUE
+   to sign-extend.  */
+
+extern LONGEST gdb_sign_extend (LONGEST value, int bit);
+
 #endif /* UTILS_H */


hooks/post-receive
--
Repository for Project Archer.


             reply	other threads:[~2013-05-14 17:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-14 17:46 tromey [this message]
  -- strict thread matches above, loose matches on Subject: below --
2013-06-18 18:10 tromey
2013-05-14 13:54 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=20130514174646.18151.qmail@sourceware.org \
    --to=tromey@sourceware.org \
    --cc=archer-commits@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).