From:	Lyle <lpak1 AT NO_SPAMccds DOT cc DOT monash DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Debugging Information && SIGSEGV faults
Date:	Wed, 13 Aug 1997 20:35:53 +1000
Organization:	Monash Uni
Lines:	74
Message-ID:	<33F18E09.C93AB447@NO_SPAMccds.cc.monash.edu>
References:	<m0wxoSA-000S1fC AT inti DOT edu DOT ar>
NNTP-Posting-Host:	ascend-1-30.cc.monash.edu.au
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Salvador Eduardo Tropea (SET) wrote:
> 
> ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire) wrote:
> > Lyle (lpak1 AT NO_SPAMccds DOT cc DOT monash DOT edu) writes:
> > > Now heres, where the debugging info comes in. I can't seem to trace the
> > > program in gdb (or RHIDE for that matter, but then RHIDE dpends on gdb
> > > so that is to be expected). for some reason, i can only trace the code
> > > in the top source for each of my objects, ie
> > > I have object sources, and witihin those sources i have #include "sddsd"
> > > for some more code relating to that object.
> To Lyle: A very bad thing if they aren't inline. So I guess they are inline
> members.

Humn - i'm not sure what you are talking about - ithink C++ ?? Either
way the #include files are not header files, but other source files
related to the object. I'm sure there is nothing wrong with hvaing more
than one source file for an object???

> 
> >> GDB doesn;t tract into any
> > > of the #include files, only the ones specified in the make file? Am i
> > > doing something wrong??
> To Lyle: Nothing wrong from you.
> 
> > 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.
> 100% wrong. GCC is smart enough to generate the debug info to show from where
> he (he for a compiler? forgive me) taked the function inlined. I saw the code
> generated and is greate how even optimized code have good debug info.
> 
> > Move a
> > member function out of the .h into the .cc or .cpp file, that is causing
> > the problem, and you can then trace into it, and when you fix it, you can
> > move it back. (I learned this recently and the hard way by the way. :-))
> Isn't a good idea. At least no for me. I have tons of inline members in my
> classes.
> The problem isn't in the inline members and isn't in gdb. Isn't even in gcc. Is
> just the DOS configuration used by DJGPP. You can change it enabling the STABs
> debug information, with this GCC can tell that some function comes from a
> header.
> 
> For it you MUST patch GCC.
> 

well this is the second time somones "hinted" at what to do. I'm not
sure i can be any more obvious than; I HAVE NO IDEA WHAT I AM DOING! I
hvae only used the compiler for about 2 hours all up, and didn;t think
there would be too much trouble porting my code across. Most of the
objects are ansi c, and the ones that wern't, were easily fixed up (for
the most part :)). However, getting the bluddy thing to work and be able
to use the development environemnt is proving a real hassle. Could you
please tell me WHAT to do. I have tunred on ALL Debug information, and
even tried conbinations to no sucess??

Cheers,
	Lyle 

> SET
> ------------------------------------ 0 --------------------------------
> Visit my home page: http://www.geocities.com/SiliconValley/Vista/6552/
> Salvador Eduardo Tropea (SET). (Electronics Engineer)
> Address: Curapaligue 2124, Caseros, 3 de Febrero
> Buenos Aires, (1678), ARGENTINA
> TE: +(541) 759 0013

-- 
NOTE: Remove The comment "NO_SPAM" To Reply via Email!

-------------------------------[ **NEW ADDRESS**
lpak1 AT ccds DOT cc DOT monash DOT edu DOT au]
" Hello Chevra Kadish, You Kill 'em, We Chill 'em "            .----,
						               | oO |
	HTTP://www-personal.monash.edu.au/~lpak1/              | \/ |
		                                               `----'

- Raw text -