From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8244 invoked by alias); 7 Aug 2013 15:23:57 -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 8235 invoked by uid 89); 7 Aug 2013 15:23:56 -0000 X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,MSGID_FROM_MTA_HEADER,RCVD_IN_DNSWL_MED,RCVD_IN_HOSTKARMA_W,RDNS_NONE,SPF_PASS autolearn=ham version=3.3.1 Received: from Unknown (HELO e06smtp18.uk.ibm.com) (195.75.94.114) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 07 Aug 2013 15:23:56 +0000 Received: from /spool/local by e06smtp18.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 7 Aug 2013 16:17:18 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp18.uk.ibm.com (192.168.101.148) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 7 Aug 2013 16:17:17 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 437AD1B08067 for ; Wed, 7 Aug 2013 16:23:46 +0100 (BST) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps4076.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r77FNX7628967028 for ; Wed, 7 Aug 2013 15:23:34 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r77FNitw012061 for ; Wed, 7 Aug 2013 09:23:45 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id r77FNg0G012039; Wed, 7 Aug 2013 09:23:42 -0600 Message-Id: <201308071523.r77FNg0G012039@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 07 Aug 2013 17:23:42 +0200 Subject: Re: [PATCH 2/5] powerpc64-aix processing xlC generated line table To: raunaq12@in.ibm.com (Raunaq 12) Date: Wed, 07 Aug 2013 15:23:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, brobecker@adacore.com, tromey@redhat.com, palves@redhat.com (Pedro Alves) In-Reply-To: from "Raunaq 12" at Aug 07, 2013 05:04:57 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13080715-6892-0000-0000-000005F3A98B X-SW-Source: 2013-08/txt/msg00202.txt.bz2 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. 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? > +/* 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 ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com