From: Broeker AT physik DOT rwth-aachen DOT de
Date: Fri, 17 May 1996 15:44:43 +0200 (MET DST)
Subject: gdb problem with foo.cpp, with a fix
To: djgpp-workers AT delorie DOT com
Cc: Broeker AT axpmgr DOT physik DOT rwth-aachen DOT de
Message-id: <01I4TFXFDRSI00167C@mail.rwth-aachen.de>
Content-type: text
Content-transfer-encoding: 7BIT

Hello, everyone

In this message I (try to) provide a patch for gcc that seems to fix the
genuine FSF gcc bug described in Eli's FAQ # 12.6, named "gdb finds only
.cc source". I would like to hear your comments on this fix.

The problem manifests itself this way: for 'gcc -g foo.cpp', all the
DJGPP debuggers will think the source file name is 'foo.cc' instead,
and therefore fail to find it. Eli's hint in the FAQ is only nearly
correct, I think: he points in the direction of the "-dumpbase foo.cc"
switch that gcc.exe will pass to cc1plus.exe in this situation, which is
obviously not what you'd expect it to be. But this, IMHO isn't the real
error. The 'dumpbase' information passed is completely correct in
itself, but it is *used* in one incorrect way.

The actual bug is in config/i386/bfd.h, in the definition of the
ASM_FILE_START(FILE) macro. This macro, as distributed in the original
FSF sources (unchanged in DJGPP), will write the *dumpbase* name into
the generated assembler source file, instead of the *actual* input file
name. IMHO, this is incorrect. If I'm not totally mistaken, the
dumpbase name is intended mainly to used as a base name for all the
compiler's intermediate debugging dumps you can get by using the '-d'
option series. This bad choice also seems to have risen the suspicion of
RMS himself, as suggested by a source annotation right above the
location of the bug.

Substituting 'dump_base_name' with 'main_input_filename' in this place
fixes the bug in a breeze (FYI: dump_base_name is what was given as the
argument to the '-dumpbase' flag, or 'gccdump' otherwise; and
main_input_filename contains the name of the file that has been passed
to gcc on the command line, as passed inside the preprocessed file by
means of the initial '#line' directives). To double-check my change, I
also grepped through several other definitions of ASM_FILE_START, and
found that each of them uses exactly one of these two variables, and
there's no apparent rule to say which is chosen for which target (e.g.,
svr3.h uses 'dump_base_name', but svr4.h uses 'main_input_filename').

As to a possible reason for the current way this is done, I'm stymied.
The only situation I can think up where this might make some sense would
be when 'main_input_filename' were containing a filename with a path
(absolute or relative) description in it. It might then be better to use
some name that doesn't contain any pathname, in case such a path
information is no more usable at debugging time (source moved, relative
path information invalid, etc.). But then, I'm not sure this can
actually happen, i.e. if main_input_filename might be stripped of any
paths anyhow.

I must admit there's a small drawback with this method: if you now
compile in a two-step process, like 'gcc -E foo.c >foo.i ; gcc -c
foo.i', the resulting foo.o will name foo.i as its source file, instead
of foo.c (which the old dumpbase method would have generated, using
gcc.exe's knowledge that foo.i is actually a C source file). But that's
far less of a problem than the braindead behaviour we have now, IMHO:
that two-step process doesn't make any sense anyway. It might even be a
valuable change in its own right (just in case anyone actually writes .i
files himself, or at least edits them:-).

If this patch breaks any other target versions of gcc (which I have no
means to test, sorry), then this changed macro definition could still be
moved into config/i386/go32.h, I think, with an #undef prepended, to
overwrite the definition from bsd.h.

Feel free to integrate this into the next DJGPP distribution, or submit
it to the FSF (I won't do that myself, unless I receive some positive
comments first). I can also upload it into the Bug tracker, if you think
that's where it should go. So, whatever you think about this, please
tell me. For now, I'll only send it to the djgpp-workers mailing list
(I'm not on that list, so please cc: any comments to me as well).

Just for the fun of it, here's the actual patch (in diff -cb format):

======== beginning of patch =================
*** config/i386/bsd.h_o Thu Jun 15 15:44:46 1995
--- config/i386/bsd.h	Fri May  3 03:34:56 1996
***************
*** 47,56 ****
  
  /* Output at beginning of assembler file.
     ??? I am skeptical of this -- RMS.  */
  
  #define ASM_FILE_START(FILE) \
    do {	fprintf (FILE, "\t.file\t");				\
! 	output_quoted_string (FILE, dump_base_name);		\
  	fprintf (FILE, "\n");					\
    } while (0)
  
--- 47,60 ----
  
  /* Output at beginning of assembler file.
     ??? I am skeptical of this -- RMS.  */
+ /* HBB: I think RMS was correct in being sceptical :-)
+    (The reason is that, for C++, dump_base_name is always, 'foo.cc',
+    even if you are compiling 'foo.C' or 'foo.cpp')
+    Let's see if may dare to 'fix' this: */
  
  #define ASM_FILE_START(FILE) \
    do {	fprintf (FILE, "\t.file\t");				\
!         output_quoted_string (FILE, main_input_filename);	\
  	fprintf (FILE, "\n");					\
    } while (0)
  
======= end of patch =========

Hans-Bernhard Br"oker (Aachen, Germany)
EMail: Broeker AT axpmgr DOT physik DOT rwth-aachen DOT de
SMail: (in case of emergency :-) Templergraben 39a, D-52062 Aachen