[PATCH 2/5] powerpc64-aix processing xlC generated line table

[PATCH 2/5] powerpc64-aix processing xlC generated line table

[Raunaq 12]

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 <function name> and
list <function name> 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.

---
ChangeLog :-
* xcoffread.c (modify_xlc_linenos): New function to modify xlc
generated linetables.
(process_linenos): Make calls to the 'modify_xlc_linenos' to correctly
process linenos is case of xlc compiled binaries.
---
./gdb/xcoffread.c
===================================================================
--- ./gdb.orig/xcoffread.c
+++ ./gdb/xcoffread.c
@@ -241,6 +241,8 @@

 static struct linetable *arrange_linetable (struct linetable *);

+static struct linetable *modify_xlc_linenos (struct linetable *);
+
 static void record_include_end (struct coff_symbol *);

 static void process_linenos (CORE_ADDR, CORE_ADDR);
@@ -589,6 +591,24 @@
     }
 }

+/* 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);

 	  push_subfile ();

---

Re: [PATCH 2/5] powerpc64-aix processing xlC generated line table

[Ulrich Weigand]

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 <function name> and
> list <function name> 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

Re: [PATCH 2/5] powerpc64-aix processing xlC generated line table

[Raunaq 12]

"Ulrich Weigand" <uweigand@de.ibm.com> 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 <function name> and
> > list <function name> 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

Re: [PATCH 2/5] powerpc64-aix processing xlC generated line table

[Ulrich Weigand]

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

Re: [PATCH 2/5] powerpc64-aix processing xlC generated line table

[Raunaq 12]

[-- Attachment #1: Type: text/plain, Size: 4844 bytes --]

"Ulrich Weigand" <uweigand@de.ibm.com> wrote on 08/09/2013 03:31:21 AM:
> 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 ...

Agreed, that would greatly help with future maintainablity of GDB on AIX.
Will plan to take that task up once I am done fixing some other
issues faced by GDB on AIX like stabstring support for XLC++ compiled
binaries.

> > 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?

Thanks for taking time to write this Ulrich. This does solve the problem
but one
extra line had to be added to update the number of items in the line table
as
seen below,

-  newLineTb->nitems = oldLineTb->nitems - function_count;
+  newLineTb->nitems = oldLineTb->nitems - function_count + extra_lines;

Added this line and ran the related testcases. Results same as before.

Can we go ahead and check this in?
If so, please find the changelog entry and attached patch below.
---
ChangeLog :-
* xcoffread.c (arrange_linetable): Add fix to correctly handle
line tables generated by XLC compiled binaries.

(See attached file: gdb-7.6-xcoff_xlc_lines.patch)

Thanks,
Raunaq M. Bathija

[-- Attachment #2: gdb-7.6-xcoff_xlc_lines.patch --]
[-- Type: application/octet-stream, Size: 2272 bytes --]

Index: ./gdb/xcoffread.c
===================================================================
--- ./gdb.orig/xcoffread.c	2013-08-12 10:47:58.000000000 +0600
+++ ./gdb/xcoffread.c		2013-08-12 12:46:54.000000000 +0600
@@ -438,6 +438,7 @@
   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 @@
 	  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,7 @@
   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,13 +497,26 @@
 
   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)
 	newLineTb->item[newline] = oldLineTb->item[jj];
     }
   xfree (fentry);
-  newLineTb->nitems = oldLineTb->nitems - function_count;
+  /* The number of items in the line table must include these
+     extra lines which were added in case of XLC compiled functions.  */
+  newLineTb->nitems = oldLineTb->nitems - function_count + extra_lines;
   return newLineTb;
 }
 

Re: [PATCH 2/5] powerpc64-aix processing xlC generated line table

[Ulrich Weigand]

Raunaq Bathija wrote:
> "Ulrich Weigand" <uweigand@de.ibm.com> wrote on 08/09/2013 03:31:21 AM:
> > 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 ...
> 
> Agreed, that would greatly help with future maintainablity of GDB on AIX.
> Will plan to take that task up once I am done fixing some other
> issues faced by GDB on AIX like stabstring support for XLC++ compiled
> binaries.

Thanks!

> Thanks for taking time to write this Ulrich. This does solve the problem
> but one
> extra line had to be added to update the number of items in the line table
> as
> seen below,
> 
> -  newLineTb->nitems = oldLineTb->nitems - function_count;
> +  newLineTb->nitems = oldLineTb->nitems - function_count + extra_lines;
> 
> Added this line and ran the related testcases. Results same as before.
> 
> Can we go ahead and check this in?

Looks good, and thanks for testing!  I've checked this in now.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

[PATCH 2/5] powerpc64-aix processing xlC generated line table

[Raunaq 12]

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 <function name> and
list <function name> 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.

---
ChangeLog :-
* xcoffread.c (modify_xlc_linenos): New function to modify xlc
generated linetables.
(process_linenos): make calls to the 'modify_xlc_linenos' to correctly
process linenos is case of xlc compiled binaries.
---
./gdb/xcoffread.c
===================================================================
--- ./gdb.orig/xcoffread.c
+++ ./gdb/xcoffread.c
@@ -241,6 +241,8 @@

 static struct linetable *arrange_linetable (struct linetable *);

+static struct linetable *modify_xlc_linenos (struct linetable *);
+
 static void record_include_end (struct coff_symbol *);

 static void process_linenos (CORE_ADDR, CORE_ADDR);
@@ -589,6 +591,24 @@
     }
 }

+/* 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);

 	  push_subfile ();

---

[PATCH 2/5] powerpc64-aix processing xlC generated line table

[Raunaq 12]

powerpc-ibm-aix: Fix line number handling for xlc compiled binaries.

xlc compiled binaries have a line table which is different from gcc
compiled ones.
It does not contain 1 extra entry which indicates the function start PC.

Because of this, listing functions, eg: 'list main' or
breaking at functions, eg: 'break function1' give wrong line numbers.

To fix this, we check if the function entry point has an entry in the
line table (in case of gcc, it does). If it does not have this entry, then
we retain
the function entry lines marked as line number equal to 0 and assign the
line number
equal to the succeeding line table entry.
---

ChangeLog :-
* xcoffread.c (process_linenos): Add fix to correctly process linenos in
case of xlc compiled binaries.

---
Index: ./gdb/xcoffread.c
===================================================================
--- ./gdb.orig/xcoffread.c
+++ ./gdb/xcoffread.c
@@ -602,7 +602,7 @@
 static void
 process_linenos (CORE_ADDR start, CORE_ADDR end)
 {
-  int offset, ii;
+ int offset, ii, jj;
   file_ptr max_offset
     = XCOFF_DATA (this_symtab_objfile)->max_lineno_offset;

@@ -698,10 +698,24 @@

       lv = main_subfile.line_vector;

+      /* 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. */
+
+      lineTb = lv;
+
+      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;
+        }
+
       /* 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 +744,24 @@

          lv = (inclTable[ii].subfile)->line_vector;

+          /* 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. */
+
+          lineTb = lv;
+
+          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;
+            }
+
          /* Line numbers are not necessarily ordered.  xlc compilation
will
             put static function to the end.  */

-         lineTb = arrange_linetable (lv);
+        lineTb = arrange_linetable (lineTb);

          push_subfile ();

---

Re: [PATCH 2/5] powerpc64-aix processing xlC generated line table

[Pedro Alves]

On 07/29/2013 07:15 AM, Raunaq 12 wrote:
> +      /* 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. */
> +
> +      lineTb = lv;
> +
> +      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;
> +        }
> +

...

> 
> +          /* 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. */
> +
> +          lineTb = lv;
> +
> +          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;
> +            }

Seems to me this duplicate code could/should be factored out to a helper
function.

-- 
Pedro Alves

Re: [PATCH 2/5] powerpc64-aix processing xlC generated line table

[Raunaq 12]

> > +          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;
> > +            }
>
> Seems to me this duplicate code could/should be factored out to a helper
> function.

Agreed. Implementation looks much cleaner after using a function for the
duplicate code. Here is the modified patch and changelog.
---
ChangeLog :-
* xcoffread.c (modify_xlc_linenos): New function to modify xlc
generated linetables.
(process_linenos): make calls to the 'modify_xlc_linenos' to correctly
process linenos is case of xlc compiled binaries.
---
Index: ./gdb/xcoffread.c
===================================================================
--- ./gdb.orig/xcoffread.c
+++ ./gdb/xcoffread.c
@@ -241,6 +241,8 @@

 static struct linetable *arrange_linetable (struct linetable *);

+static struct linetable *modify_xlc_linenos (struct linetable *);
+
 static void record_include_end (struct coff_symbol *);

 static void process_linenos (CORE_ADDR, CORE_ADDR);
@@ -589,6 +591,24 @@
     }
 }

+/* 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);

 	  push_subfile ();

---
this is ok?
Note :- without this patch we are not able to break into functions at the
entry
point and we are not able to list functions by their name. eg :- list main

Regards,
Raunaq

Re: [PATCH 2/5] powerpc64-aix processing xlC generated line table

[Raunaq 12]

Corrected a few formatting errors that i just realised :-
---
./gdb/xcoffread.c
===================================================================
--- ./gdb.orig/xcoffread.c
+++ ./gdb/xcoffread.c
@@ -241,6 +241,8 @@

 static struct linetable *arrange_linetable (struct linetable *);

+static struct linetable *modify_xlc_linenos (struct linetable *);
+
 static void record_include_end (struct coff_symbol *);

 static void process_linenos (CORE_ADDR, CORE_ADDR);
@@ -589,6 +591,24 @@
     }
 }

+/* 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);

 	  push_subfile ();

---
Regards,
Raunaq

[PATCH 2/5] powerpc64-aix processing xlC generated line table

[Raunaq 12]

powerpc-ibm-aix: Fix line number handling for xlc compiled binaries.

xlc compiled binaries have a line table which is different from gcc
compiled ones.
It does not contain 1 extra entry which indicates the function start PC.

Because of this, listing functions, eg: 'list main' or
breaking at functions, eg: 'break function1' give wrong line numbers.

To fix this, we check if the function entry point has an entry in the
line table (in case of gcc, it does). If it does not have this entry, then
we retain
the function entry lines marked as line number equal to 0 and assign the
line number
equal to the succeeding line table entry.
---

ChangeLog :-
* xcoffread.c (process_linenos): Add fix to correctly process linenos in
case of xlc compiled binaries.

---
Index: ./gdb/xcoffread.c
===================================================================
--- ./gdb.orig/xcoffread.c
+++ ./gdb/xcoffread.c
@@ -602,7 +602,7 @@
 static void
 process_linenos (CORE_ADDR start, CORE_ADDR end)
 {
-  int offset, ii;
+ int offset, ii, jj;
   file_ptr max_offset
     = XCOFF_DATA (this_symtab_objfile)->max_lineno_offset;

@@ -698,10 +698,24 @@

       lv = main_subfile.line_vector;

+      /* 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. */
+
+      lineTb = lv;
+
+      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;
+        }
+
       /* 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 +744,24 @@

          lv = (inclTable[ii].subfile)->line_vector;

+          /* 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. */
+
+          lineTb = lv;
+
+          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;
+            }
+
          /* Line numbers are not necessarily ordered.  xlc compilation
will
             put static function to the end.  */

-         lineTb = arrange_linetable (lv);
+        lineTb = arrange_linetable (lineTb);

          push_subfile ();

---