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: gdb-patches@sourceware.org, brobecker@adacore.com,
	tromey@redhat.com,        palves@redhat.com (Pedro Alves)
Subject: Re: [PATCH 2/5] powerpc64-aix processing xlC generated line table
Date: Wed, 07 Aug 2013 15:23:00 -0000	[thread overview]
Message-ID: <201308071523.r77FNg0G012039@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <OF01E8FD54.0C7BFC8C-ON65257BC0.003F914D-65257BC0.003FB9C7@in.ibm.com> from "Raunaq 12" at Aug 07, 2013 05:04:57 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.

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


  reply	other threads:[~2013-08-07 15:23 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 [this message]
2013-08-08 12:04     ` Raunaq 12
2013-08-08 22:01       ` Ulrich Weigand
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=201308071523.r77FNg0G012039@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