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: Sun, 22 Feb 1998 21:25:00 -0000 Message-id: <199802230525.AAA03604@aura.saic1.com> References: <10164.888186440@hurl.cygnus.com> X-SW-Source: 1998-02/msg01047.html Jeff Law wrote: >Daniel J. Bernstein wrote: >> Where can I get a reliable debugger that works with egcs 1.0.1? >> I am currently using GNU gdb 4.16, and frankly, it is pitiful when >> used with EGCS. > > On what platform? Without that information we can't even begin to > address your problem. Jeff, 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. I think there was some discussion here about the changes in dwarf information format, that the new compiler puts out but gdb-4.16 doesn't know how to handle. (I didn't understand most of the exchange back then so if someone could list what platforms this change should affect?) Also debugging shared libraries is a problem for gdb-4.16 on the same platforms. I think these are just problems with the debugger itself. I have been having a terrible time trying to get gdb working here, for weeks, I've not been very effective... just trying to narrow down the problems and send off bug reports to the gdb list. I don't remember getting replies to many of my reports/requests. I couldn't begin to solve the problems I'm seeing: if gdb core dumped yes I can fix it... if it just doesn't "do the right thing" I can't. There seem to me to be alot of requests for help and very few replies (I've been looking for gdb answers). (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, the only person around here who has got working binaries out of the combination is me. Purify doesn't seem to like the shared libraries we've been feeding it. In many cases I have to force feed purify with options like -best-effort. Compiling statically works, but for some of our programs that isn't an option: our apps that use sockets need /lib/libnsl.a which has calls to dlopen, which is only found in /lib/libdl.so*. I agree this is a problem with the Sun libraries, libnsl.a *SHOULD NOT* be making calls to dlopen... (see dlopen(3), paragraph 2). I don't have source to fix it. I did see a fix for libnsl.a somewhere many months ago, that involved using source from the MIT distribution from X11, but at the time it was just an interesting thing to note. Now that I *need it to work* I don't have a clue where I saw the instructions. Does anyone remember seeing something about this? From: dbristow@lynx.dac.neu.edu Date: Thu, 12 Feb 1998 11:24:17 -0500 (EST) Subject: Checker and egcs Jeff Law replied: >David Bristow wrote: >>Has anybody tried to use Checker-0.8 with egcs? It has some patches to >>2.7.2.x to add testing code in. > >egcs should have all the checker code that was submitted to gcc. The compiler code changes are to operate with the new version of Checker-0.9 not the old Checker-0.8. on Thu, 22 Jan 1998 11:29:38 +0100, Tristan Gingold wrote: :I have just released Checker. It is available on alpha.gnu.org/~ftp/gnu. :Please, report all bugs/comments/ideas.... current location: ftp://alpha.gnu.org/gnu/Checker-0.9.2.tar.gz I did some preliminary tests with Checker-0.9.tar.gz... ggcs-2.8.0 and egcs-1.0.1... on both Linux and Solaris. In my simple tests (compile the example.c that comes with the Checker source): GGCS and checker: - solaris - gcc/g++ worked fine. - linux - gcc/g++ worked fine. EGCS and checker: - solaris - gcc/g++ produces an executable, which runs correctly until it receives a SIGSEGV, then it loops infinitely printing a message about it. - linux - gcc/g++ core dumps during compile. So the results are that something(s) is missing or added to EGCS. I have not tried Checker-0.9.2 yet... I would _love_ to see checker work with egcs, for both gcc and g++ so I can stop messing with purify. Too much time is wasted trying to get a working gdb haven't had a chance to generate a bug report on that. -- Argh, Mike Simons Science Applications International Corporation msimons@saic1.com 703-925-5674