From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17595 invoked by alias); 8 Aug 2013 22:01:36 -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 17568 invoked by uid 89); 8 Aug 2013 22:01:35 -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 e06smtp12.uk.ibm.com) (195.75.94.108) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 08 Aug 2013 22:01:34 +0000 Received: from /spool/local by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 8 Aug 2013 22:55:29 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 8 Aug 2013 22:55:28 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id C816317D8057 for ; Thu, 8 Aug 2013 23:03:12 +0100 (BST) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps4075.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r78M1CtT50331824 for ; Thu, 8 Aug 2013 22:01:12 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 r78M1Mms020057 for ; Thu, 8 Aug 2013 16:01:23 -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 r78M1L4R020039; Thu, 8 Aug 2013 16:01:21 -0600 Message-Id: <201308082201.r78M1L4R020039@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 09 Aug 2013 00:01:21 +0200 Subject: Re: [PATCH 2/5] powerpc64-aix processing xlC generated line table To: raunaq12@in.ibm.com (Raunaq 12) Date: Thu, 08 Aug 2013 22:01:00 -0000 From: "Ulrich Weigand" Cc: brobecker@adacore.com, gdb-patches@sourceware.org, palves@redhat.com (Pedro Alves), tromey@redhat.com In-Reply-To: from "Raunaq 12" at Aug 08, 2013 05:32:49 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: 13080821-8372-0000-0000-000006D973EC X-SW-Source: 2013-08/txt/msg00259.txt.bz2 Raunaq 12 wrote: > "Ulrich Weigand" wrote on 08/07/2013 08:53:42 PM: > > 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. Well, the test suite is supposed to handle different compilers, but since only very few people test with anything but GCC, support for other compilers tends to bit-rot. As a suggestion to help with future maintainability of GDB on AIX, it would be nice if you could go through the test suite at some point and clean those problems up ... > 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. OK, excellent! > 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. Well, I guess what I'm concerned about is that your patch eliminates the possibility for arrange_linetable to see separate functions in the line table (since the line number 0 markers have actually been erased). Since arrange_linetable wants to sort the line table by function, I'd have expected this to cause issues. (Unless there is no real reason any more to perform this sorting?) > So I cannot make these changes in arrange_linetable(). It's probably easier to show what I had been thinking of in the form of a patch. Note that this is completely untested and just intended to show the idea: Index: gdb/xcoffread.c =================================================================== RCS file: /cvs/src/src/gdb/xcoffread.c,v retrieving revision 1.114 diff -u -p -r1.114 xcoffread.c --- gdb/xcoffread.c 6 May 2013 19:38:04 -0000 1.114 +++ gdb/xcoffread.c 8 Aug 2013 21:52:42 -0000 @@ -438,6 +438,7 @@ arrange_linetable (struct linetable *old struct linetable_entry *fentry; /* function entry vector */ int fentry_size; /* # of function entries */ struct linetable *newLineTb; /* new line table */ + int extra_lines = 0; #define NUM_OF_FUNCTIONS 20 @@ -459,6 +460,12 @@ arrange_linetable (struct linetable *old fentry[function_count].line = ii; fentry[function_count].pc = oldLineTb->item[ii].pc; ++function_count; + + /* If the function was compiled with XLC, we may have to add an + extra line entry later. Reserve space for that. */ + if (ii + 1 < oldLineTb->nitems + && oldLineTb->item[ii].pc != oldLineTb->item[ii + 1].pc) + extra_lines++; } } @@ -475,7 +482,8 @@ arrange_linetable (struct linetable *old newLineTb = (struct linetable *) xmalloc (sizeof (struct linetable) + - (oldLineTb->nitems - function_count) * sizeof (struct linetable_entry)); + ((oldLineTb->nitems - function_count + extra_lines) + * sizeof (struct linetable_entry))); /* If line table does not start with a function beginning, copy up until a function begin. */ @@ -490,6 +498,17 @@ arrange_linetable (struct linetable *old for (ii = 0; ii < function_count; ++ii) { + /* If the function was compiled with XLC, we may have to add an + extra line to cover the function prologue. */ + jj = fentry[ii].line; + if (jj + 1 < oldLineTb->nitems + && oldLineTb->item[jj].pc != oldLineTb->item[jj + 1].pc) + { + newLineTb->item[newline] = oldLineTb->item[jj]; + newLineTb->item[newline].line = oldLineTb->item[jj + 1].line; + newline++; + } + for (jj = fentry[ii].line + 1; jj < oldLineTb->nitems && oldLineTb->item[jj].line != 0; ++jj, ++newline) Does this also solve the problem you were trying to address? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com