From:	ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Debugging Information && SIGSEGV faults
Date:	12 Aug 1997 07:51:04 GMT
Organization:	The National Capital FreeNet
Lines:	26
Message-ID:	<5sp4l8$2lc@freenet-news.carleton.ca>
References:	<33ED6843 DOT 715EA2D8 AT NO_SPAMccds DOT cc DOT monash DOT edu> <5smf13$5lq AT freenet-news DOT carleton DOT ca> <33EEEA77 DOT 7106E645 AT Mathematik DOT TU-Chemnitz DOT DE>
Reply-To:	ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire)
NNTP-Posting-Host:	freenet3.carleton.ca
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Robert Hoehne (Robert DOT Hoehne AT Mathematik DOT TU-Chemnitz DOT DE) writes:
> Paul Derbyshire wrote:
>> 
>> Well, debuggers don't trace into C++ functions in .h's because they're
>> inlined and have no separate existence as functions at run time. Move a
> 
> That's wrong. The debuggers (at least gdb and RHIDE/RHGDB) can trace
> into inlined functions from header files!!

They can't...at least the copies I have can't. They will if it is moved
into a .cc implementation file and only prototyped in the .h definition
file. And yes, I do compile with debugging information for anything other
than a final, distribution release, as in

gcc this.c that.c -o those.exe -g -lalleg
                              ^^^^
I was given to understand this is the correct syntax to put debug data in
the .exe. And I was not using -fomit-frame-pointer, which I know can
affect debugging, curtail stack trace info and so forth.

--
    .*.  Where feelings are concerned, answers are rarely simple [GeneDeWeese]
 -()  <  When I go to the theater, I always go straight to the "bag and mix"
    `*'  bulk candy section...because variety is the spice of life... [me]
Paul Derbyshire ao950 AT freenet DOT carleton DOT ca, http://chat.carleton.ca/~pderbysh

- Raw text -