This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



"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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]