Mail Archives: djgpp/1997/08/14/14:12:12
Lyle <lpak1 AT NO_SPAMccds DOT cc DOT monash DOT edu> 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
- Raw text -