🚀 go-pugleaf

| [I mailed this to bug-gcc@prep.ai.mit.edu a week ago, but never
|  saw it appear on the gnu.gcc.bug newsgroup]
| 
| GCC 1.40 on DECstations doesn't handle generated C files correctly
| (it doesn't do the right thing with #line's), and debuggers get
| confused, looking at the generated C code, instead of the original
| source.  GCC 1.40 running on Sparcstations, on the other hand,
| works correctly.
| 
| The problem is that the .file directive at the beginning of the
| asm file emitted by GCC points to the generated C file instead
| of the original file specifed in a #line directive.
| 
| For example, given /tmp/foo.c, which looks like
| 	#line 1 "/u/gvr/foo.c"
| 	/* code */
| the first line of foo.s will be
| 	.file "/tmp/foo.c"
| As /tmp/foo.c is generated on the fly and removed after compilation,
| this is a problem for debugging.
| 
| The following extract from compile_file() in toplev.c indicates that
| GCC is trying to do the right thing, but failing:
|   /* the beginning of the file is a new line; check for # */
|   /* With luck, we discover the real source file's name from that
|      and put it in input_filename.  */
|   ungetc (check_newline (), finput);
| 
| GCC 1.40 on Sparcstations doesn't issue an initial directive corresponding
| to .file, so it doesn't screw up.

The problem is not the .file at the beginning of the source (which if
removed would cause more problems).  Instead it is a problem with the
MIPS ECOFF object file format (and also the System V.[23] COFF object
file format which ECOFF is based upon).  On the Sun, which uses the
BSD a.out object file format, it handles this situation -- by the way,
there is a .file on the sun, it's just encoded in the .stabs.

MIPS ECOFF has a requirement that the source file never change within
a function.  This is because the line numbers are compressed to be
delta's from the previous line, with no loopholes for switching files.

System V.[23] COFF is worse in that it can't switch files ever within
a compilation unit, and furthermore, line numbers within a function
must not be decreasing (ie, inlines really mess it up).

Some of us believe that the C in COFF stands for crippled instead of
common, as AT&T claimed in it's documentation.

--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

You are in a twisty little passage of standards, all conflicting.