This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: frameworklet to assess the quality of debug information
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Ian Lance Taylor" <iant at google dot com>
- Cc: "Alexandre Oliva" <aoliva at redhat dot com>, gcc at gcc dot gnu dot org, "Andrew MacLeod" <amacleod at redhat dot com>, "Janis Johnson" <janis187 at us dot ibm dot com>, "Michael Matz" <matz at suse dot de>, "Daniel Jacobowitz" <drow at false dot org>
- Date: Tue, 29 Jul 2008 11:24:20 +0200
- Subject: Re: frameworklet to assess the quality of debug information
- References: <or7ib5r8mb.fsf@oliva.athome.lsd.ic.unicamp.br> <m3od4h4bw2.fsf@google.com>
On Tue, Jul 29, 2008 at 5:17 AM, Ian Lance Taylor <iant@google.com> wrote:
> Alexandre Oliva <aoliva@redhat.com> writes:
>
>> Here's my first cut at trying to tell how well or how bad we perform
>> in terms of debug info, that can be dropped into the GCC run-time test
>> infrastructure and used by means of #include in new tests that add
>> GUALCHK* annotations (or with separate compilation, if some stuff is
>> moved into a separate header).
>>
>> Thoughts, comments, suggestions, tomatoes, eggs? :-)
>
> It's an interesting approach. Have you considered an approach more
> like Dejagnu's dg support? It would be harder to write tests, but
> would permit testing debugging info less invasively.
>
> int
> main (int argc, char *argv[])
> {
> int i = argc+1;
> int j = argc-2;
> int k = 5;
>
> /* { gualchk argc 1 } */
> /* { gualchk i 2 } */
> /* { gualchk j -1 } */
> }
I am less concerned about this - we are writing debug testcases after
all. I am more concerned that the current implementation has an
effect on the generated code we want to check (yes, I recognized
the comment about a two-stage approach ;)). In that light, why not
pair the testcase with a gdb script directly? (can one conditionally
exit gdb with a non-zero exit code?)
Thanks,
Richard.