This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: debugging for egcs
- To: Mike Simons <msimons at saic1 dot com>
- Subject: Re: debugging for egcs
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 23 Feb 1998 22:39:52 -0700
- cc: egcs at cygnus dot com
- Reply-To: law at cygnus dot com
In message <199802231007.FAA03879@aura.saic1.com>you write:
> could this be a short bit information about gdb be added to the
> EGCS web FAQ? some basic things like:
Good point. Added.
> > Checker and egcs-1.0 probably don't work. That's because *many*
> > fixes went into checker after egcs-1.0 was released.
>
> s/egcs-1.0/egcs-1.0.1/
> s/probably/definitely/
>
> Yup, that sums it up nicely.
Yup. The checker support had literally been installed into the
gcc sources the week or so before we did our last merge from gcc2
into egcs for the 1.0 releases.
>
> > Current egcs snapshots should work as well as gcc-2.8 with checker;
> > any regressions would be considered a bug.
>
> Okay, I've kinda been holding out for egcs-1.0.2, because I have so
> many other problems. I'd like to wait to submit reports till then so
> they can be fixed for egcs-1.1.0... (so hurry up and stablize 1.0.2 ;)
Note, 1.0.2 is not going to fix any of the checker problems.
> Speaking of testcases... do all of the short code bug examples reports
> posted to this list turn themselves into additional testsuite cases?
Depends on whether or not folks take the time to put them in a
form suitable for the testsuites :-) Nothing automatically happens,
and I'm too busy to do it myself.
> If not, how should they be packaged so they *are* added to the
> regression suite? (I don't know how dejagnu works)
For C tests which are not system dependent, look at testsuite/gcc.c-torture.
Basically you just have to add the file and the testsuite will
automatically find and run it.
C++ tests are more complicated because they use a more complex (and
more powerful) testing harness.
> Is posting information about failed tests useful? (test name, it's
> exit code... maybe a backtrace)
Many folks do this already via (semi?) automated testing procedures.
If you've got a target that's not regularly tested, then doing the
tests yourself and posting the results would probably greatly
help improve the quality of the port you're using.
jeff