delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2002/02/05/06:35:15

X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f
Date: Tue, 5 Feb 2002 13:31:42 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Michael Lazarev <milaz AT newmail DOT ru>
cc: djgpp AT delorie DOT com
Subject: Re: Maybe it's all GCC's blame
In-Reply-To: <3c5fa244@MAIL.mhogaming.com>
Message-ID: <Pine.SUN.3.91.1020205132358.22795D-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Tue, 5 Feb 2002, Michael Lazarev wrote:

> > You should not have executable code in a .h file, so breakpoints there
> > are unnecessary
> 
> Yes, you are right. Header files are for declarative purposes.

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.

> 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.

> 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 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.

> 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.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019