From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10887 invoked by alias); 18 Jun 2004 21:59:18 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10874 invoked from network); 18 Jun 2004 21:59:17 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.77.109) by sourceware.org with SMTP; 18 Jun 2004 21:59:17 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i5ILxFu3001025; Fri, 18 Jun 2004 23:59:16 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i5ILxFVx001543; Fri, 18 Jun 2004 23:59:15 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i5ILxF9G001540; Fri, 18 Jun 2004 23:59:15 +0200 (CEST) Date: Fri, 18 Jun 2004 21:59:00 -0000 Message-Id: <200406182159.i5ILxF9G001540@elgar.kettenis.dyndns.org> From: Mark Kettenis To: m.mueller99@kay-mueller.de CC: gdb-patches@sources.redhat.com, binutils@sources.redhat.com In-reply-to: <40D32489.9070503@kay-mueller.de> (message from Michael Mueller on Fri, 18 Jun 2004 19:21:13 +0200) Subject: Re: [RFC]: patch #2 for Sun C compiled target programs References: <40D32489.9070503@kay-mueller.de> X-SW-Source: 2004-06/txt/msg00450.txt.bz2 Date: Fri, 18 Jun 2004 19:21:13 +0200 From: Michael Mueller 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