From: Lyle Newsgroups: comp.os.msdos.djgpp Subject: Re: Debugging Information && SIGSEGV faults Date: Fri, 15 Aug 1997 13:26:16 +1000 Organization: Monash Uni Lines: 80 Message-ID: <33F3CC58.FF6BC872@NO_SPAMccds.cc.monash.edu> References: NNTP-Posting-Host: ascend-1-06.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 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/ | \/ | `----'