missing line info in mips mdebug section

["Ken Greenberg" <ken at calast dot com>]

I am trying to use the line number information produced by gcc for my own 
tool, and have noticed an interesting phenomenon which is preventing me 
from doing so efficiently. The default debug format for mips is to produce the 
.mdebug section, which I understand reasonably well. What I notice, 
however, is that if I simply say mips-elf-gcc -g -c foo.c, then the resulting .o 
file does not contain any line entries in the .mdebug section. On further 
investigation, I noted the following. Suppose you compile foo.c to foo.s first, 
then assemble.

mips-elf-gcc -g -S foo.c
mips-elf-gcc -g -c foo.s

This is more or less what the compiler does, except it uses a temp file. No 
line information appears. However,

mips-elf-gcc -g -c foo.S

does produce line information. (We assume foo.s and foo.S are the same 
file, possibly through a symbolic link.) The only difference here is that a .S 
file is run through cpp one more time. This is done because mips assembly 
language makes extensive use of macros, and anyone who wants to write in 
mips assembly language (an ISR, for example) is highly likely to use these 
macros in the interest of retaining some sanity. By naming the file ".S" the 
preprocessor is automatically invoked before assembly by the compiler driver.

So why should running the assembly source through cpp cause line number 
information to be output? An examination of the assembler source file shows 
that proper stabs are emitted in stabn form, containing the line number from 
the C source file and the corresponding location. These do not seem to 
appear in the mdebug section of the .o file, although stabs in "stab s" form 
do appear in the mdebug strings section. Thus, the stabn information gets 
lost - but if run through cpp then it is converted into the proprietary mdebug 
line information through some process that is not obvious.

This does not seem to be version-dependent. I believe the compiler itself is 
behaving reasonably, but the assembler is not. There are no differences in 
invocation flags between specifying ".s" versus ".S" - just an extra pass. 
Interestingly, if the resulting executable file is loaded into gdb, you can say 
"list foo" and the source code will be properly displayed. So gdb must be 
using some other way of locating the source lines. An objdump of the 
mdebug section of the executable confirms that the mdebug section 
contains no line entries in either the procedure descriptor tables or the file 
descriptor tables. 

So, does anyone have any insight into what is going on here?

-Ken

"Humankind owes its evolutionary success in large measure
to mastery and transmission of tool-making and tool-using."
 -McClellan & Dorn, "Science and Technology in World History"

Kenneth F. Greenberg, President
California Advanced Software Tools, Inc.
400 Los Gatos Blvd., Los Gatos, CA 95032
Voice: (408) 356-9249  FAX: (408) 358-4089
http://www.calast.com/

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com