This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |