This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: frameworklet to assess the quality of debug information


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.


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