Mail Archives: djgpp/1997/08/18/13:19:44
Hi,
Eli Zaretskii wrote:
>
> On Wed, 13 Aug 1997, Lyle wrote:
>
> > 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
>
> I wasn't following this thread from its beginning, so let me apologize
> up front if I'm not talking to your point below, but I hope it will
> help you.
>
> As far as I understand, your problem is with debugging code that comes
> from #include'd files. If that is correct, then the DJGPP debuggers
> won't be able to debug such code unless you get a patched version of
> GCC which can generate the so-called ``stabs debug information''. The
> version of GCC in the stock DJGPP distribution doesn't support stubs
> debugging, that's why adding -gstabs to the GCC command line didn't
> help you.
>
> Several people advised you to get PGCC (GCC with Pentium
> optimizations) or rebuild GCC with a certain patch that enables stabs
> support. While this advice is certainly valid, I won't recommend that
> approach for a person who is new to DJGPP (as you have described
> yourself), since you obviously want to make your program work *fast*.
> Building GCC is no small feat, it requires that you download and
> install several optional DJGPP packages and be ready to battle
> problems that pop up in some cases when you build GCC. PGCC is still
> in beta phase and might get you in trouble in other places.
> So these are solutions for somebody who is ready to invest a
> significant amount of time into learning to use these tools. If you
> are ready for such an investment of time and effort, by all means go
> ahead with one of these options.
>
> If not, here's the approaches to debugging your problem that I can
> recommend:
>
> 1) Make a special version of the program source that doesn't
> use code from included files, by inserting the contents of
> these file into the main source file. (If you can guess
> which inclded files you need to debug, insert only them.)
> Debug that version with any debugger you fancy. When you
> have found the bug(s) and corrected them, go back to the
> original source files and correct them as well.
>
> 2) Use ``printf debugging''. That is, insert calls to `printf'
> in strategic points of the program that will print values of
> variables which can explain how does the problem happen.
> Examine the output of these `printf' calls and try to
> induce what is causing the bug.
>
> 3) Try to make a small (100 lines or less) program that
> exhibits the same behavior, post it to this forum and ask
> people to tell what's wrong with it.
It's just that i don't ahve time - and i would really like to compile
the program in 32 bit. However, i can't waste time trying to debug it
using 'primitive' methods. I appreciate your suggestions, however in my
situtation they are unrealistic. I might give the pgcc a go and see what
happens? Maybe i could use that to debug and the distributed gcc to do
final compileS? However, i guess i'm inviting myself to unexplicable
errors :)
Anyway thanks for your informative reply!
Cheers,
Lyle
--
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 -