From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16881 invoked by alias); 25 Feb 2003 23:17:04 -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 16873 invoked from network); 25 Feb 2003 23:17:02 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 25 Feb 2003 23:17:02 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 953E0800049; Tue, 25 Feb 2003 18:17:02 -0500 (EST) Message-ID: <3E5BF96E.2020301@redhat.com> Date: Tue, 25 Feb 2003 23:17:00 -0000 From: "J. Johnston" Organization: Red Hat Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: dbxread patch References: <3E5AB25A.30504@redhat.com> Content-Type: multipart/mixed; boundary="------------080901010009020101000605" X-SW-Source: 2003-02/txt/msg00674.txt.bz2 This is a multi-part message in MIME format. --------------080901010009020101000605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1386 Jim Blandy wrote: > Yes, looks good. > > Please add a comment briefly explaining why the check is needed > (hand-generated stabs that contain N_FUN stabs but no N_SLINE stabs). > I have attached a new patch with a comment. > Elena suggested the change, right? She should be credited in the > ChangeLog entry. > You are correct - thanks for spotting this oversight. 2003-02-25 Jeff Johnston From Elena Zannoni * dbxread.c (process_one_symbol): Only record line 0 if one or more sline entries have been seen for the function. Ok now? -- Jeff J. > "J. Johnston" writes: > > >>The following patch fixes a problem when the stabs debug info >>for a file does not contain sline entries. This happens, for >>example with the glibc syscall code which is generated assembler >>code. In process_one_symbol in dbxread.c, a line 0 is recorded for the >>end of the function. When there are no other line numbers, we end up finding this >>line 0 as our alt_symtab in symtab:find_pc_sect_line() and we end up >>subtracting one resulting in line -1. This problem manifests itself >>when we attempt to break at the generated glibc functions such as >>kill. >> >>The patch changes process_one_symbol() to only record line 0 if sline info >>has been found for the function. >> >>Ok to commit? >> >>-- Jeff J. >> >> --------------080901010009020101000605 Content-Type: text/plain; name="dbxread.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dbxread.patch" Content-length: 754 Index: dbxread.c =================================================================== RCS file: /cvs/src/src/gdb/dbxread.c,v retrieving revision 1.43 diff -u -r1.43 dbxread.c --- dbxread.c 20 Feb 2003 18:31:14 -0000 1.43 +++ dbxread.c 25 Feb 2003 23:12:07 -0000 @@ -2831,7 +2831,13 @@ break; } - record_line (current_subfile, 0, last_function_start + valu); + /* The following check is added before recording line 0 at + end of function so as to handle hand-generated stabs + which may have an N_FUN stabs at the end of the function, but + no N_SLINE stabs. */ + if (sline_found_in_function) + record_line (current_subfile, 0, last_function_start + valu); + within_function = 0; new = pop_context (); --------------080901010009020101000605--