X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-bounces using -f
From:	"Michael Lazarev" <milaz AT newmail DOT ru>
Newsgroups:	comp.os.msdos.djgpp
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1020205132358 DOT 22795D-100000 AT is>
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.

- Raw text -