Re: debugging for egcs

Re: debugging for egcs

[Mike Simons]

David,

> 	If you are worried about EGCS and GDB, I would suggest that you
> test out the publicly-available gdb-4.17 pre-release snapshots to see if
> any or most of your problems have been addressed.  Hasn't this been
> mentioned on the GDB newsgroups?  The GDB mailinglists now are open and
> served by majordomo as well.

  the only gdb news group I have seen is gnu.gdb.bug, and that has been
*very* dead (6 posts in the last 4 weeks).  The only announcement like thing
I've seen was a post to this list a few weeks back:

Date: Tue, 27 Jan 1998 09:17:06 -0800
From: Jason Molenda <jsm@cygnus.com>
Subject: Preparing for a GDB 4.17 release

- mentioned the branch was being made for release, 4.16.85 (which was 
  installed on our machines two days after it appeared on the ftp site :).
- mentioned the gdb-patches@cygnus.com list to send any patches we had 
  for gdb.
- mentioned the location of the "current GDB snapshot:
  ftp://ftp.cygnus.com/private/gdb/
- explained how to subscribe to the gdb-testers list.
  there have been four posts in the last four days.

So a few questions...
+ is that the list(s) that you meant?
+ is gdb-4.16.85.tar.gz in /private/gdb the "publicly-available pre-release"?
+ which newsgroups are you referring to?

  Mail from that list tends to get hidden behind the *huge* volume the 
three egcs lists produce... (i have really got to figure out and *use* 
procmail ;)


> The problems are with GDB, not EGCS, so
> there is a limit on what EGCS can/should do to fix it when EGCS is
> producing correct debugging information.

  Yes I realize it's not a fault with EGCS... just got incredibly miffed
with Jeff's answer when I first read it because, I read it like "bugs 
between gdb and egcs???  wow, this is news to us... why don't you give us a 
better list of specifics to that we can try to figure out the problem?"
  (that is not what he said... and not what he meant.)

> GDB moved up its planned release just to address the EGCS bug reports.

  uhmm... are any GNU projects really planned?

  I thought it was GNU policy *not* to announce release dates... by not
announcing they one doesn't need to plan.  How can one "move up" something 
that wasn't scheduled in the first place?  Some utilities have been 
in the 'expecting to release a new version any day now' for years.  =)

  I understand and agree with the reasoning behind not announcing release
dates... people developing reliable software can't predict the unknown.
I just felt like poking fun at the idea one could "move up" something
that no one could expect was ever coming... 

  gdb 4.16 came out in Apr of 1996.
  gcc 2.7.2 came out in Nov of 1995.
  gcc 2.8.0 came out on Jan of 1998.
  
  if history is a good indication of the future we can hope for a gdb 4.17 
sometime in June.  and if it gets "moved up" two months it will be out 
late April!  :P

-- 

    Thanks,
      Mike Simons
      Science Applications International Corporation
      msimons@saic1.com                  703-925-5674

ps: 
  if you didn't follow the GNU mailing lists you might have thought the 
gcc development had stagnated by 1997... two years and no release?!?
  i _am_ ignoring the three patches for 2.7.2...

Re: debugging for egcs

[Jeffrey A Law]

  In message < 199802230913.EAA03831@aura.saic1.com >you write:
  >   the only gdb news group I have seen is gnu.gdb.bug, and that has been
  > *very* dead (6 posts in the last 4 weeks).  The only announcement like thing
  > I've seen was a post to this list a few weeks back:
Most of the traffic these days is on the patches and testers mailing
lists.   Here's some info on them:

  We've just created some new mailing lists, we'll be putting a GDB web
  page together, and all of the mailing lists are now archived on the web
  (with hypermail).  If you've seen the EGCS setup, none of this will be
  a surprise.

  The current GDB mailing lists are

     gdb
     gdb-announce     moderated announcements only
     gdb-bugs
     gdb-patches
     gdb-testers

  All have open subscription policies, you can subscribe to them by sending
  a note to majordomo@cygnus.com with the usual 'subscribe $list-name'
  message.  You can subscribe to multiple lists in a single message to
  majordomo.

  The mailing lists are all archived at http://www.cygnus.com/ml/$list-name .
  Things are a little rough right now, please be patient if something
  doesn't work right.

  > > GDB moved up its planned release just to address the EGCS bug reports.
  > 
  >   uhmm... are any GNU projects really planned?
Some aspects of GNU projects are planned....


  >   I thought it was GNU policy *not* to announce release dates... by not
  > announcing they one doesn't need to plan.  How can one "move up" something 
  > that wasn't scheduled in the first place?  Some utilities have been 
  > in the 'expecting to release a new version any day now' for years.  =)
Well, the gdb team probably has some kind of rough schedule that they'd
like to follow for a release, much like egcs, binutils and many other
tools have.  Those dates (of course) aren't set in stone.

  >   gdb 4.16 came out in Apr of 1996.
  >   gcc 2.7.2 came out in Nov of 1995.
  >   gcc 2.8.0 came out on Jan of 1998.
gdb and gcc are managed by two completely different groups.

The reason behind the lag time in gdb releases is not many folks
have been asking for a new release.  That kind of changed when egcs
going...

  > ps: 
  >   if you didn't follow the GNU mailing lists you might have thought the 
  > gcc development had stagnated by 1997... two years and no release?!?
  >   i _am_ ignoring the three patches for 2.7.2...
IMHO gcc development had stagnated by late 1996 or even earlier due
to the 6 month+ code freeze that was in effect for gcc-2.7*.
Others may or may not share that opinion.

jeff

Re: debugging for egcs

[Mike Stump]

> Date: Tue, 24 Feb 1998 13:54:16 -0700
> From: Jeffrey A Law <law@hurl.cygnus.com>

> The c-torture framework does not need the source annotated with
> additional information.  The C++ tests do.

They don't require it.  For example, here is conv1.C:

--------------------
enum E { C };
 
E foo() {
  return C;
}
 
main() {
  if (foo() != C)
    return 1;
}
--------------------

As you can see, nothing funny, nothing special.  Though, to be fair to
your comment, putting in testsuite directives is useful and done with
regularity.  I put them in half (43%) of the time.

Re: debugging for egcs

[Mike Stump]

> Date: Mon, 23 Feb 1998 22:39:52 -0700
> From: Jeffrey A Law <law@cygnus.com>

> C++ tests are more complicated because they use a more complex (and
> more powerful) testing harness.

Hum, I thought it was as easy as it could get.... :-) I'll have to
jump the fence and investigate the C testcases, my impression was that
the typical testcase was no easier to do than it was for C++.

Re: debugging for egcs

[Jeffrey A Law]

  In message < 199802242051.MAA19444@kankakee.wrs.com >you write:
  > > Date: Mon, 23 Feb 1998 22:39:52 -0700
  > > From: Jeffrey A Law <law@cygnus.com>
  > 
  > > C++ tests are more complicated because they use a more complex (and
  > > more powerful) testing harness.
  > 
  > Hum, I thought it was as easy as it could get.... :-) I'll have to
  > jump the fence and investigate the C testcases, my impression was that
  > the typical testcase was no easier to do than it was for C++.
The c-torture framework does not need the source annotated with
additional information.  The C++ tests do.



jeff

Re: debugging for egcs

[Mike Stump]

> From: Mike Simons <msimons@saic1.com>
> Date: Mon, 23 Feb 1998 05:07:43 -0500 (EST)
> Cc: egcs@cygnus.com

>   Speaking of testcases... do all of the short code bug examples
> reports posted to this list turn themselves into additional
> testsuite cases?

No, some just get dumped on the floor.  :-( Counter claims are
welcome.  They are in the mailing list archive, but I think that is
about it.  Unless you submit an AI testcase that knows how to add
itself to the testsuite, testcases will never add themselves to the
testsuite.  :-)

> If not, how should they be packaged so they *are* added to the
> regression suite?

Well, the word `regression' has a meaning, and not all of the little
bug examples are regressions.

It would be good to have an expected to be broken directory
(non-regression), and add all the various broken things to it.

They way to get a testcase into such a place, is to find out the right
place, and submit diffs to add it.

For C++, you can check out any (or all) of the C++ testcases, and get
a fairly good feel, fairly quickly.  `make check' isn't that hard to
type.

	make check-c++ 'RUNTESTFLAGS=-v -v old-deja.exp=eh6.C'

for example will run just a single C++ testcase.

A couple canonical example testcases:

    nit i;	// ERROR - we should get an error message

and:

    int i;	// gets bogus error - come on, compile it for me

As you can see, they are really easy to write, each one it just one
line, and hopefully is really easy to understand.  If people want to
add non-regression testcases into the testsuite, how about a new
directory, gcc/testsuite/g++.old-deja/g++.broken?  Just start
submitting diffs for new files (diff -N)...

debugging for egcs

[D. Bernstein]

Hello,

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.

Dan
-- 
Daniel J. Bernstein
Partner, Computer Science Services Group, LLC

[ NOTE: to get my REAL e-mail address, remove the e-mail
spam-killer, ".DIE-SPAM-DIE". ]

E: dan@cssgroup.DIE-SPAM-DIE.com
W: http://www2.southwind.net/~css

Obligatory quote:

"A lot has been said about politics; some of it complimentary,
but most of it accurate."

    -- Eric Idle

Re: debugging for egcs

[Mike Simons]

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.

Dan,
  I can't say these are much better, but _some_ things work better.
In my experience trying to debug any C++ code inside shared libraries is 
hopeless.  Non C++ works very well, non shared libraries works okay in many
cases.


latest snapshot:
ftp://ftp.cygnus.com/private/gdb/gdb-980122.tar.gz

latest branch/snapshot that will be gdb-4.17:
ftp://ftp.cygnus.com/private/gdb/gdb-4.16.85.tar.gz

if you want to subscribe to the gdb list... send to majordomo@cygnus.com,
a message with no subject just the contents:
subscribe gdb-testers you@host.domain

-- 

    Later,
      Mike Simons
      Science Applications International Corporation
      msimons@saic1.com                  703-925-5674

Re: debugging for egcs

[Jeffrey A Law]

  In message < 34EDB473.7C97@cssgroup.com >you write:
  > Hello,
  > 
  > 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

Re: debugging for egcs

[Mike Simons]

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

Re: debugging for egcs

[Jeffrey A Law]

  In message < 199802230525.AAA03604@aura.saic1.com >you write:
  >   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).

  > (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 
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.

Checker and egcs-1.0 probably don't work.  That's because *many*
fixes went into checker after egcs-1.0 was released.

Current egcs snapshots should work as well as gcc-2.8 with checker;
any regressions would be considered a bug.  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.


jeff

Re: debugging for egcs

[Mike Simons]

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.  <sigh>
  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.  :)

Re: debugging for egcs

[Jeffrey A Law]

  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