From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31345 invoked by alias); 12 Jul 2002 17:46:58 -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 31297 invoked from network); 12 Jul 2002 17:46:53 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 12 Jul 2002 17:46:53 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g6CHkmA08162 for ; Fri, 12 Jul 2002 10:46:53 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 12 Jul 2002 10:46:44 -0700 Received: from inghji.apple.com (inghji.apple.com [17.201.22.240]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g6CHkiT13709; Fri, 12 Jul 2002 10:46:44 -0700 (PDT) Date: Fri, 12 Jul 2002 11:03:00 -0000 Subject: Re: [patch] Fix to processing end of function stab in dbxread.c Content-Type: multipart/mixed; boundary=Apple-Mail-5-944164857 Mime-Version: 1.0 (Apple Message framework v533) Cc: gdb-patches@sources.redhat.com To: Daniel Jacobowitz From: Jim Ingham In-Reply-To: <20020712173056.GA989@nevyn.them.org> Message-Id: <54F92956-95BF-11D6-AB35-00039379E320@apple.com> X-SW-Source: 2002-07/txt/msg00274.txt.bz2 --Apple-Mail-5-944164857 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Content-length: 2630 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... --Apple-Mail-5-944164857 Content-Disposition: attachment; filename=dbxread.c.patch Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="dbxread.c.patch" Content-length: 1591 Index: dbxread.c =================================================================== RCS file: /cvs/src/src/gdb/dbxread.c,v retrieving revision 1.33 diff -c -w -r1.33 dbxread.c *** dbxread.c 10 May 2002 07:32:50 -0000 1.33 --- dbxread.c 12 Jul 2002 17:34:50 -0000 *************** *** 2761,2768 **** static CORE_ADDR last_function_start; /* If this is nonzero, we've seen an N_SLINE since the start of the current ! function. Initialized to nonzero to assure that last_function_start ! is never used uninitialized. */ static int sline_found_in_function = 1; /* If this is nonzero, we've seen a non-gcc N_OPT symbol for this source --- 2761,2768 ---- static CORE_ADDR last_function_start; /* If this is nonzero, we've seen an N_SLINE since the start of the current ! function. We use this to tell us to move the first sline to the beginning ! of the function regardless of what its given value is. */ static int sline_found_in_function = 1; /* If this is nonzero, we've seen a non-gcc N_OPT symbol for this source *************** *** 2799,2805 **** { /* This N_FUN marks the end of a function. This closes off the current block. */ ! record_line (current_subfile, 0, function_start_offset + valu); within_function = 0; new = pop_context (); --- 2799,2806 ---- { /* This N_FUN marks the end of a function. This closes off the current block. */ ! record_line (current_subfile, 0, last_function_start + valu); ! within_function = 0; new = pop_context (); --Apple-Mail-5-944164857 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Content-length: 110 Jim -- Jim Ingham jingham@apple.com Developer Tools - gdb Apple Computer --Apple-Mail-5-944164857--