This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [RFC]: patch #2 for Sun C compiled target programs
- From: Mark Kettenis <kettenis at chello dot nl>
- To: m dot mueller99 at kay-mueller dot de
- Cc: gdb-patches at sources dot redhat dot com, binutils at sources dot redhat dot com
- Date: Fri, 18 Jun 2004 23:59:15 +0200 (CEST)
- Subject: Re: [RFC]: patch #2 for Sun C compiled target programs
- References: <40D32489.9070503@kay-mueller.de>
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