Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: raunaq12@in.ibm.com (Raunaq 12)
Cc: brobecker@adacore.com, gdb-patches@sourceware.org,
	       palves@redhat.com (Pedro Alves),
	tromey@redhat.com
Subject: Re: [PATCH 2/5] powerpc64-aix processing xlC generated line table
Date: Thu, 08 Aug 2013 22:01:00 -0000	[thread overview]
Message-ID: <201308082201.r78M1L4R020039@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <OFEDD6697A.D1616883-ON65257BC1.003CA46B-65257BC1.00424726@in.ibm.com> from "Raunaq 12" at Aug 08, 2013 05:32:49 PM

Raunaq 12 wrote:
> "Ulrich Weigand" <uweigand@de.ibm.com> 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


  reply	other threads:[~2013-08-08 22:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <OF1EDEDB55.9DF54135-ON65257BBA.003B42B8-65257BBA.003D0F4D@LocalDomain>
2013-08-07 11:37 ` Raunaq 12
2013-08-07 15:23   ` Ulrich Weigand
2013-08-08 12:04     ` Raunaq 12
2013-08-08 22:01       ` Ulrich Weigand [this message]
2013-08-12  7:50         ` Raunaq 12
2013-08-26 15:30           ` Ulrich Weigand
2013-08-01 11:07 Raunaq 12
  -- strict thread matches above, loose matches on Subject: below --
2013-07-29  6:15 Raunaq 12
2013-07-29 16:58 ` Pedro Alves
2013-07-31  9:57   ` Raunaq 12
     [not found]   ` <OF668B9A7A.5414653D-ON65257BB9.00351B5A-65257BB9.003675D7@LocalDomain>
2013-07-31 10:03     ` Raunaq 12
2013-07-24 12:37 Raunaq 12

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201308082201.r78M1L4R020039@d06av02.portsmouth.uk.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=raunaq12@in.ibm.com \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox