missing line info in mips mdebug section
Ken Greenberg
ken@calast.com
Thu Apr 18 13:20:00 GMT 2002
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
More information about the crossgcc
mailing list