From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7690 invoked by alias); 8 Aug 2013 12:04:29 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 7609 invoked by uid 89); 8 Aug 2013 12:04:28 -0000 X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_MED,RCVD_IN_HOSTKARMA_W,RDNS_NONE,SPF_PASS autolearn=ham version=3.3.1 Received: from Unknown (HELO e28smtp07.in.ibm.com) (122.248.162.7) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 08 Aug 2013 12:04:25 +0000 Received: from /spool/local by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 8 Aug 2013 17:25:42 +0530 Received: from d28dlp01.in.ibm.com (9.184.220.126) by e28smtp07.in.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 8 Aug 2013 17:25:41 +0530 Received: from d28relay05.in.ibm.com (d28relay05.in.ibm.com [9.184.220.62]) by d28dlp01.in.ibm.com (Postfix) with ESMTP id 3CE3CE0053 for ; Thu, 8 Aug 2013 17:34:30 +0530 (IST) Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r78C4BwA47186024 for ; Thu, 8 Aug 2013 17:34:11 +0530 Received: from d28av04.in.ibm.com (localhost [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r78C4D4p011563 for ; Thu, 8 Aug 2013 17:34:13 +0530 Received: from d23ml188.in.ibm.com (d23ml188.in.ibm.com [9.182.8.144]) by d28av04.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id r78C4D8U011551; Thu, 8 Aug 2013 17:34:13 +0530 In-Reply-To: <201308071523.r77FNg0G012039@d06av02.portsmouth.uk.ibm.com> References: from "Raunaq 12" at Aug 07, 2013 05:04:57 PM <201308071523.r77FNg0G012039@d06av02.portsmouth.uk.ibm.com> Subject: Re: [PATCH 2/5] powerpc64-aix processing xlC generated line table X-KeepSent: EDD6697A:D1616883-65257BC1:003CA46B; type=4; name=$KeepSent To: "Ulrich Weigand" Cc: brobecker@adacore.com, gdb-patches@sourceware.org, palves@redhat.com (Pedro Alves), tromey@redhat.com Message-ID: From: Raunaq 12 Date: Thu, 08 Aug 2013 12:04:00 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13080811-8878-0000-0000-0000084F20E2 X-SW-Source: 2013-08/txt/msg00239.txt.bz2 "Ulrich Weigand" wrote on 08/07/2013 08:53:42 PM: Raunaq 12 wrote: > > xlc generated binaries have a line table which is not the same as GCC. > > GCC compiled binaries have an extra line entry in the line table to > > signify start of a function whereas xlc does not have this entry. > > > > Due to this difference, commands like break and > > list give wrong results. > > > > To fix this issue I have written a function modify_xlc_linenos > > which will add a line table entry at the function start points > > if there is no extra entry in the line table as in the case of xlc. > > > > Hence, > > breakpoints and listing functions will work as expected even for xlc > > compiled binaries. Ulrich Weigand wrote: > I don't have much experience with the XCOFF file format or the > XLC debug info ... > > Did you confirm -via test suite runs- that: > - this patch improves results when using XLC, and > - this patch does not regress when using GCC? Yes, I did test it. Running the entire test bucket when test cases are compiled with xlc is a pain as many compiler options used to compile the test programs are not compatible with xlc. But the main focus of this patch is to read the correct line number for function entry points. I ran the test cases gdb.base/list.exp and gdb.base/break.exp as they give a good indication if gdb recognizes function entry lines correctly. Same is the case with all break point related test cases. on Running - gmake check RUNTESTFLAGS='"gdb.base/*break*.exp"' with xlc:- Without patch applied- 131 PASS | 43 FAIL With patch applied- 169 PASS | 5 FAIL This is because GDB wrongly interprets function entry points in case of xlc compiled binaries as the line table is different. No regressions with gcc also confirmed. With/Without patch applied- 172 PASS | 5 FAIL Tested the same way for list.exp as well. Plus ran the overall gdb.base bucket with and without patch applied, results were identical. > > +/* xlc compiled binaries have one less entry in the line table. > > + So the function entry lines marked as line number equal to 0 > > + will be retained in the line table with line numbers equal > > + to its succeeding line table entry. */ > > + > > +static struct linetable * > > +modify_xlc_linenos (struct linetable *lineTb) > > +{ > > + int jj; > > + for (jj = 0; jj < lineTb->nitems; jj++) > > + { > > + if (lineTb->item[jj].line == 0 && (lineTb->item[jj].pc > > + != lineTb->item[jj + 1].pc)) > > + lineTb->item[jj].line = lineTb->item[jj + 1].line; > > + } > > + return lineTb; > > +} > > + > > /* Global variable to pass the psymtab down to all the routines involved > > in psymtab to symtab processing. */ > > static struct partial_symtab *this_symtab_psymtab; > > @@ -698,10 +718,14 @@ > > > > lv = main_subfile.line_vector; > > > > + /* Add extra line entry in case of xlc compiled binaries. */ > > + > > + lineTb = modify_xlc_linenos (lv); > > + > > /* Line numbers are not necessarily ordered. xlc compilation will > > put static function to the end. */ > > > > - lineTb = arrange_linetable (lv); > > + lineTb = arrange_linetable (lineTb); > > if (lv == lineTb) > > { > > current_subfile->line_vector = (struct linetable *) > > @@ -730,10 +754,14 @@ > > > > lv = (inclTable[ii].subfile)->line_vector; > > > > + /* Add extra line entry in case of xlc compiled binaries */ > > + > > + lineTb = modify_xlc_linenos (lv); > > + > > /* Line numbers are not necessarily ordered. xlc compilation will > > put static function to the end. */ > > > > - lineTb = arrange_linetable (lv); > > + lineTb = arrange_linetable (lineTb); > > Is there any reason why the change done in the new modify_xlc_linenos > routine cannot be done inline in arrange_linetable? The latter > routine already appears to do a number of checks related to the > end of line table entries ... arrange_linetable basically takes a line table, removes the entries marked as line number 0 as they are to indicate function entry points and returns the new table without these "line number 0" entries. The function I have added- modify_xlc_linenos is for adding additional entries into the line table which will have the PC for start of a function (this is already there for gcc) and the line number as equal to the immediate next line table entry. So this must be taken care of before we call arrange_linetable to take care of the "line number 0" function markers. So I cannot make these changes in arrange_linetable(). Any thoughts ? Thanks, Raunaq M. Bathija