X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f From: "Michael Lazarev" Newsgroups: comp.os.msdos.djgpp References: Subject: Re: Maybe it's all GCC's blame Date: Wed, 6 Feb 2002 12:05:13 +0300 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Original-NNTP-Posting-Host: 213.59.208.60 Message-ID: <3c60f267@MAIL.mhogaming.com> X-Original-Trace: 6 Feb 2002 02:07:51 -0700, 213.59.208.60 X-COMPLAINTS: Report abuse to abuse AT mhogaming DOT com Lines: 91 Organization: Newshosting.com - Highest quality at a great price! www.newshosting.com NNTP-Posting-Date: 06 Feb 2002 09:08:19 GMT NNTP-Posting-Host: 384c2fa4.news.newshosting.com X-Trace: DXC=;[n^@m\=iPnfOODeV?iHKiX`1N4>^k1LciF6BbIV4YYbnEaR^cOTQ`d AT 6ndXKWnAkom2lengNZCfeBOWBh@4SCJe\44h=O^TVnf X-Complaints-To: abuse AT newshosting DOT com To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Eli Zaretskii wrote: > See my other mail about this: it's not always practical to have header > files devoid of code in C++ programs. Take a look at the standard C++ > headers, for example. It is matter of practice. Someone hides executable code; ones just want to create some order as they understand it, while another ones are just creating easy-pluggable libraries. In my particular case, which was discussed, it had no mention. Just workaround way to make debugging work somehow. By the way, it failed, of couse. The one working "around" is gathering all sources into one file. > > > Things go even worse, because after "Build all" some time RHIDE warns me > > that I cannot use breakpoint in some line; some time it warns me only after > > CTRL+F9, and it is dreadful. It lets me only one choice "OK", when I wold > > prefer not to run a program at all, if breakpiont is not set. > > For now, you are well advised to use -gstabs+ switch to the compiler. > The default -g means COFF debugging info, which is very deficient for C++ > programs, and the newer DWARF2 debug info, generated if you compile with > -ggdb, still has a few nasty bugs both in the compiler and in GDB. So I > suggest to review your RHIDE settings and make sure it uses -gstabs+ when > it compiles for debugging. You should read my first post, "Debugging in RHIDE (1.4.9)", where I mentioned, that -gstabs+ was only my choice when at least something worked. > > I think the last thing described here is RHIDE bug, not compiler's one, > > because RHIDE must have debugging information on all lines of already built > > program, and must warn that it is unable to set breakpoint right after > > attempt of setting it. > > Your assumptions are wrong: the debugger built into RHIDE does not always > know whether it is feasible to put a breakpoint on any given address. If > the debugger needed to know that at all times, it would require > preposterous amounts of memory (because debug info is typically extremely > voluminous). I wonder if simple binary scale can be done for built-in debugger, where i-th bit is set to 1 when it is possible to set a breakpoint into f1(i)-th line of f2(i)-th file of project. No other info is required, and when program starts, debugger uses "posterous" amounts of memory requierd to do the job. :) Maybe if it can't be done, two buttons could appear in dialog "breakpoint could not be set" after CTRL+F9: "Yes" and "No". Yes to start a program where some breakpoint wasn't set, or No. It could be very useful for those, who don't know if they are managed to set breakpoints, and if not, they wouldn't run a program. Also, it's very interesting, if 20 breakpoints weren't correctly set, RHIDE makes user to press OK 20 times and then executes program? It is instead of pressing "No" once and return to editing? Of course, the last example is idiotic, but buttons is good idea anyway. :) > > I am agree with you. I tried gdb, and saw that gcc really produces wrong > > line numbers and even wrong function lists. Names of class member functions > > are corrupted, and there is wrong debugging info for them. > > I believe this is because you use -g, which produces COFF debug info. > See sections 12.1 and 12.5 of the DJGPP FAQ list for more about this. > I should thank you for excellent FAQ that I always read before posting. I exactly used -gstabs+, although tried another switches. Probably it could occur because of my negligent using of demangling options. Afer moving back to gcc/gpp 2.95.3 the problem disappeared. > > Now I understand why RHIDE developers don't waste their time for working on > > debugging features. > > ??? The debugger built into RHIDE is GDB (stripped of its UI part). GDB > is actively developed by a large group of developers; RHIDE just uses the > results of that effort. I meant "debugging features" is interface of RHIDE with built-in GDB. Maybe I expressed there too sharply and nobody understood me correctly. It was only about temporary delay which seems to undevoted ones, because of known problems of gcc 3.xx with C++. Thank you for comments.