From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Simons To: law@cygnus.com Cc: egcs@cygnus.com Subject: Re: debugging for egcs Date: Mon, 23 Feb 1998 02:14:00 -0000 Message-id: <199802231007.FAA03879@aura.saic1.com> References: <6911.888212683@hurl.cygnus.com> X-SW-Source: 1998-02/msg01052.html Jeff Law wrote: >In message < 199802230525.AAA03604@aura.saic1.com > msimons wrote: >> For Linux and Solaris the "pitiful" description sums up nicely. >> >> I *think* most of the egcs developers are aware that debugging >> C++ programs practically is impossible with gdb 4.16 at least on >> Solaris and Linux. > >Use -gstabs to force stabs debugging until gdb-4.17 is released (it's >in beta testing right now). thanks for the info... grepping through my egcs list output I see that -gstabs was mentioned as a fix 2 times by you and Robert Lipe, around Fed 3rd. I should have tried it but I think I missed those messages. could this be a short bit information about gdb be added to the EGCS web FAQ? some basic things like: - gdb 4.16 doesn't understand a DWARF2, egcs and ggcs use DWARF2 for c++. - if you have problems debugging try using -gstabs instead of -g. ...or if you want to help get the new gdb out sooner... - the ftp site for the latest experimental version of gdb is X. - the mailing list for gdb is Y. - send in your bug reports and patches to Z... >> (purify 4.1 and egcs 1.0.1 on SunOS 5.5) >> On Solaris purify and egcs don't seem to get along very well > > This is pretty typical -- anytime purify sees something it does not > understand it craps out. Having dealt with the problems with purify > and gcc over the years -- I can say that every case I've run into so > far where purify chokes has been a Purify bug. ANd there's not much > we can do about them. I'm not impressed with purify either... I think some people lean on it just a little too much... when we first started moving our work onto Linux it was SIGSEGV'ing our code. Some people decided Linux being buggy (yeah right) "because purify on the sparcs report no memory errors on that code". There were about 10 places we *were* over running arrays, every run, all the time, even on the Sparcs... It took stepping with gdb to show how 'i' went from 0 to 15, indexing into arrays of size 10, before the idea that there "might be a problem" with our code. It seems that knowing purify exisits... some just write a bunch of code and run it through purify. Without exerting effort to write good leakless code. > 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. > 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 ;) > We'd need some testcases > to fix them -- but also note that everyone is quite busy, so it may > take a while before anyone can fix your problem. Speaking of testcases... do all of the short code bug examples reports posted to this list turn themselves into additional testsuite cases? If not, how should they be packaged so they *are* added to the regression suite? (I don't know how dejagnu works) Is posting information about failed tests useful? (test name, it's exit code... maybe a backtrace) -- Thanks alot, Mike Simons Science Applications International Corporation msimons@saic1.com 703-925-5674 re: testsuites I am very impressed with the number of tests that can be run over the compiler with a simple "make check"... something I would like to start doing with our stuff someday, actually watching the regression tests pass give me a lot of confidence that a "make install" isn't going to cause me hours of grief the next work day/morning when people start using the new compiler. :)