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
next 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