From: Lyle 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: NNTP-Posting-Host: ascend-1-30.cc.monash.edu.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk 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/ | \/ | `----'