Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Mueller <m.mueller99@kay-mueller.de>
To: gdb-patches@sources.redhat.com,  binutils@sources.redhat.com
Subject: [RFC]: patch #2 for Sun C compiled target programs
Date: Fri, 18 Jun 2004 17:21:00 -0000	[thread overview]
Message-ID: <40D32489.9070503@kay-mueller.de> (raw)

[-- Attachment #1: Type: text/plain, Size: 3469 bytes --]

For Sun C compiled 64 bit target programs "print localvar" does not work 
(PR gdb/1669).

I verified this against these compiler versions:

   Sun C 5.5 2003/03/12
   Forte Developer 7 C 5.4 2002/03/09
   Sun WorkShop 6 update 2 C 5.3 2001/05/15
   Sun WorkShop 6 2000/04/07 C 5.1

This is what happens:

   GNU gdb 2004-06-17-cvs
   Copyright 2004 Free Software Foundation, Inc.
   GDB is free software, covered by the GNU General Public License, and 
you are
   welcome to change it and/or distribute copies of it under certain 
conditions.
   Type "show copying" to see the conditions.
   There is absolutely no warranty for GDB.  Type "show warranty" for 
details.
   This GDB was configured as "sparc-sun-solaris2.8"...
   (gdb) b main
   Breakpoint 1 at 0x100000894: file p2.c, line 6.
   (gdb) run
   Starting program: /export/home/michaelm/gdb/gdb-6.1.patch/tst/p2

   Breakpoint 1, main () at p2.c:6
   6               int n = 7;
   (gdb) p n
   Cannot access memory at address 0x7ffff009


There are 2 different problems that need to be fixed. One might involve 
binutils.

*** Problem 1 *************************************************

In dbxread.c function read_ofile_symtab macro INTERNALIZE_SYMBOL (nlist, 
bufp, abfd) is called to set nlist.n_value (type bfd_vma = unsigned 
long, size 64 bit) to the negative offset of a local variable inside the 
stack frame. This offset is taken from bufp->e_value which is 4 bytes 
(bfd_byte e_value[4]). This is the macro definition:

#define INTERNALIZE_SYMBOL(intern, extern, abfd)                 \
   {                                                              \
     (intern).n_type = bfd_h_get_8 (abfd, (extern)->e_type);      \
     (intern).n_strx = bfd_h_get_32 (abfd, (extern)->e_strx);     \
     (intern).n_desc = bfd_h_get_16 (abfd, (extern)->e_desc);     \
     if (bfd_get_sign_extend_vma (abfd))                          \
       (intern).n_value = bfd_h_get_signed_32 (abfd, (extern)->e_value);\
     else                                                         \
       (intern).n_value = bfd_h_get_32 (abfd, (extern)->e_value); \
   }

The problem is that bfd_get_sign_extend_vma returns 0 and the negative 
value is not sign extended and turns into a large positive number.

There was a similar problem in the past for mips 64 bit:

     The problem with stabs and sign extension
     http://sources.redhat.com/ml/gdb/2001-08/msg00078.html

     db/ChangeLog-2001:
     2001-08-14  H.J. Lu  (hjl@gnu.org)

It was fixed by introducing the call to bfd_get_sign_extend_vma into the 
macro. Following this example one could fix this by changing binutils to 
make bfd_get_sign_extend_vma return 1 for sparc solaris 64 bit.

Function bfd_get_sign_extend_vma is also called in dwarf2read.c and I 
don't know what the effects of such a change would be there. I'm also 
not sure if this it the intended use of bfd_get_sign_extend_vma.

As a temporary workaround I changed INTERNALIZE_SYMBOL to always call 
bfd_h_get_signed_32 (see the appended dbxread.workaround).


*** Problem 2 *************************************************

Function sparc64_frame_base_address in sparc64-tdep.c needs to be fixed:

   /* ??? Should we take BIAS into account here?  */
   return cache->base;


The answer to the question in comment is yes, see the appended patch.



2004-05-18  Michael Mueller  <m.mueller99@kay-mueller.de>
     * sparc64-tdep.c: fix PR gdb/1669, printing of 64 bit
       local variables


[-- Attachment #2: sparc64-tdep.patch --]
[-- Type: text/plain, Size: 796 bytes --]

Index: sparc64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sparc64-tdep.c,v
retrieving revision 1.12
diff -c -p -r1.12 sparc64-tdep.c
*** sparc64-tdep.c	7 Jun 2004 02:02:55 -0000	1.12
--- sparc64-tdep.c	18 Jun 2004 12:41:26 -0000
*************** sparc64_frame_base_address (struct frame
*** 568,575 ****
    struct sparc_frame_cache *cache =
      sparc64_frame_cache (next_frame, this_cache);
  
!   /* ??? Should we take BIAS into account here?  */
!   return cache->base;
  }
  
  static const struct frame_base sparc64_frame_base =
--- 568,574 ----
    struct sparc_frame_cache *cache =
      sparc64_frame_cache (next_frame, this_cache);
  
!   return cache->base + BIAS;
  }
  
  static const struct frame_base sparc64_frame_base =

[-- Attachment #3: dbxread.workaround --]
[-- Type: text/plain, Size: 837 bytes --]




###### This is a WORKAROUND, not a proper patch: #######


*** dbxread.c.orig	Fri Jun 18 14:56:56 2004
--- dbxread.c	Fri Jun 18 14:56:55 2004
*************** stabs_seek (int sym_offset)
*** 852,861 ****
--- 852,865 ----
      (intern).n_type = bfd_h_get_8 (abfd, (extern)->e_type);		\
      (intern).n_strx = bfd_h_get_32 (abfd, (extern)->e_strx);		\
      (intern).n_desc = bfd_h_get_16 (abfd, (extern)->e_desc);  		\
+ /*** workaround for Solaris sparc 64					\
      if (bfd_get_sign_extend_vma (abfd))					\
+ ***/									\
        (intern).n_value = bfd_h_get_signed_32 (abfd, (extern)->e_value);	\
+ /*** workaround for Solaris sparc 64					\
      else								\
        (intern).n_value = bfd_h_get_32 (abfd, (extern)->e_value);	\
+ ***/									\
    }
  
  /* Invariant: The symbol pointed to by symbuf_idx is the first one

             reply	other threads:[~2004-06-18 17:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-18 17:21 Michael Mueller [this message]
2004-06-18 21:59 ` Mark Kettenis
2004-06-21 15:05   ` Michael Mueller
2004-06-24 19:34     ` Mark Kettenis
2004-06-24 19:47     ` Mark Kettenis
2004-06-24 20:57       ` Michael Mueller
2004-06-28  8:16       ` Michael Mueller

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=40D32489.9070503@kay-mueller.de \
    --to=m.mueller99@kay-mueller.de \
    --cc=binutils@sources.redhat.com \
    --cc=gdb-patches@sources.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