From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28273 invoked by alias); 18 Feb 2003 15:41:55 -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 28266 invoked from network); 18 Feb 2003 15:41:54 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 18 Feb 2003 15:41:54 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h1IFfsK12803 for ; Tue, 18 Feb 2003 10:41:54 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1IFfsa18260 for ; Tue, 18 Feb 2003 10:41:54 -0500 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1IFfr521996 for ; Tue, 18 Feb 2003 10:41:53 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id B4F60FF79; Tue, 18 Feb 2003 10:45:59 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15954.21815.72753.33336@localhost.redhat.com> Date: Tue, 18 Feb 2003 15:41:00 -0000 To: Jim Ingham Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [patch] Fix to processing end of function stab in dbxread.c In-Reply-To: <54F92956-95BF-11D6-AB35-00039379E320@apple.com> References: <20020712173056.GA989@nevyn.them.org> <54F92956-95BF-11D6-AB35-00039379E320@apple.com> X-SW-Source: 2003-02/txt/msg00372.txt.bz2 I've committed this change. elena Jim Ingham writes: > Daniel, > > On Friday, July 12, 2002, at 10:30 AM, Daniel Jacobowitz wrote: > > > On Thu, Jul 11, 2002 at 02:10:49PM -0700, Jim Ingham wrote: > >>> I judge from your example that MacOSX has resolved addresses attached > >>> to N_SLINE stabs, but not in ending N_FUN stabs? GDB assumes that > >>> function_start_offset applies to both of them equally (and it will be > >>> zero if we expect both to be resolved). On GNU/Linux both N_SLINE > >>> and > >>> final N_FUN have offsets within the function. I suspect that on some > >>> Solaris variant N_SLINE and final N_FUN will both have resolved > >>> values. > >>> In that case using last_function_start + valu will put us well > >>> outside > >>> of the actual function, causing mayhem. > >> > >> That's right. MacOS X's linker does fix up the SLINE stabs, but it > >> does what stabs.texi says to do with the end of function stabs. > >> > >> It would suprise me if there were a Solaris compile/linker that does > >> otherwise with the end of FUN stab. After all, it seems like the > >> Solaris tools go out of their way to avoid having STABS that the > >> linker > >> has to fix up. Also, the comment in stabs.texi says "Recent versions > >> of GCC will mark the end of the function with an N_FUN symbol..." > >> Sounds like the Solaris compilers may not have this end of function > >> FUN > >> stab at all. > >> > >> Would somebody with access to a Solaris box with acc on it compile a > >> simple program with "-g" and see if it has this stab, and if so what > >> its value is? > >> > >> I bet the code I suggested will work fine. > > > > ACC is HP/UX, isn't it? The Sun compiler is Sun Workshop CC. In any > > case, it appears that Solaris does not mark the end of functions with > > stabs. I'm satisfied; sorry for the runaround. > > It has been five or six years since I actually worked on a Sun box that > somebody had paid for Sun's tools for, but my memory was the actual > binary was called acc. I remember it wasn't called cc, 'cause it > ticked me off at the time... > > Anywya, thanks for looking into this. > > > > > You might want to repost the patch not-mangled this time; since your > > mail client persistently wraps things attaching it might be simplest. > > Yeah, it is an okay mailer in many other ways, but it does have this > little quirk... Here is the ChangeLog, and the patch as an attachment: > > 2002-07-10 Jim Ingham > > * dbxread.c (process_one_symbol): Use last_function_start rather > than function_start_offset to find the real beginning of the > current function. The latter is just the text section offset on > some systems, the former is always the real function start... > > > > > Jim > -- > Jim Ingham jingham@apple.com > Developer Tools - gdb > Apple Computer >