Message-Id: Comments: Authenticated sender is From: "Salvador Eduardo Tropea (SET)" Organization: INTI To: Lyle , djgpp AT delorie DOT com Date: Thu, 14 Aug 1997 15:19:15 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Debugging Information && SIGSEGV faults Precedence: bulk Lyle wrote: > 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??? What?! header files are for prototypes and inline functions. Any other use (like a way to emulate a library including code) is a very bad practise and will produce hard problems soon or later in your project. > > >> 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?? 1) Move the code to a .cc file. 2) If you still having problems and have the time patch the compiler to allow the generation of STABs debug info. Greetings, 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