Sender: crough45 AT amc DOT de
Message-Id: <97Oct4.150833gmt+0100.11649@internet01.amc.de>
Date: Sat, 4 Oct 1997 14:13:20 +0100
From: Chris Croughton <crough45 AT amc DOT de>
Mime-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Bad debugging code for class functions in header
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

If I have a header file like:

class foo
{
public:
  void fred()
  {
    for (int i = 1; i < 1000; i++)
       bill(i);
  }
  void bill() {}
};

and in the .cc file (which includes the header 
file first) have something like:

int main()
{
  foo bar;
  bar.fred();
  return 0;
}


then in the output code the object file will contain
code for main() and then code for foo::fred().  So far,
this is what's expected (note that foo::fred() has to 
be complex enough that it can't be inlined).

However, the debugging code (with -g) generates incorrect
line numbers for foo::fred(), and gdb therefore thinks that
foo::fred() is declared in the same file as main() but off
the end somewhere.  This can be shown if (under gdb) you
do "b main", "r" and then "s" to step into foo::fred() -
gdb will come up with "line NNN not found, XXX.cc only
has 8 lines" or something like that.

If you use "as -anhld foo.cc" to get an assember listing 
with embedded source, it similarly generates no source
for foo::fred();

Note that this works fine on Linux gcc (2.7.2.2) and DEC
Alpha gcc (2.7.2.2).

(As an aside, DJGPP's gdb also can't handle the C++ 'long double'
type, it displays it as 'void'!)

If anyone wants real code to test this with, I can zip and
uuencode my test program and send it.  Please tell me if this
also needs to be posted elsewhere (djgpp-workers or whatever).

Chris C