cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp/1999/04/12/13:26:16

Date: Mon, 12 Apr 1999 19:25:44 +0200
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Message-Id: <199904121725.TAA03056@acp3bf.physik.rwth-aachen.de>
To: djgpp AT delorie DOT com
Subject: Re: #line statements
Newsgroups: comp.os.msdos.djgpp
Organization: RWTH Aachen, III. physikalisches Institut B
X-Newsreader: TIN [version 1.2 PL2]
Reply-To: djgpp AT delorie DOT com

In article <371215093C DOT 3617IANNI AT si DOT deis DOT unical DOT it> you wrote:
> Many commercial compilers can use #line command in order to track
> compiling & runtime errors on original files (as example a bison/yacc
> grammar file) instead of using generated *.c files. 

> Can I do the same with RHIDE ?

RHIDE has almost no influence at all on this feature. It's entirely
the compiler's task to do that.

Actually, bison does already spit out #line directives, if you want
them. The pity is that the default type of gcc debugging information
(the one you get by 'gcc -g') will not transport them to the debugging
stage unharmed: the numbers will be seen by the debugger, but the file
name changes won't, so it'll try to read foo.c, line 1234, if the
previous #line directive pointed to foo.y, line 1234.

This same reason causes inline functions of C++, with their
implementations found in header files, to fail as well, and the
solution is the same for both problems.

You have to use '-gstabs' (or '-ggdb') as the debugging flag, instead.
These 'stabs' debugging informations correctly carry over the source
file changes, and #line directives should work. IIRC, '-gstabs' works
with gcc-2.8.* for DJGPP, only. The older gcc binaries don't have
stabs support.

--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -


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