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
next prev parent 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