Re: [RFC]: patch #2 for Sun C compiled target programs

[Mark Kettenis <kettenis@chello.nl>]

   Date: Fri, 18 Jun 2004 19:21:13 +0200
   From: Michael Mueller <m.mueller99@kay-mueller.de>

   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

Would it be difficult for you to test with GCC too?

   This is what happens:

   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).

Sorry but that change is unacceptable.  It's an obvious hack and might
break other targets.  It's not at all clear what values are supposed
to be sign-extended and what values are not, as mentioned in the
thread cited by you.

The real problem is that dbxread.c was initially written as 32-bit
only code.  The sign-extension problem you're seeing here can also be
interpreted as a 64-bit-dirty issue.

   *** 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.

That sounds reasonable.  I'll commit that bit if it works with
GCC/DWARF too.

Mark