rfg@uunet.uu.net (Ron Guilmette) (11/14/90)
--text follows this line-- Tom Wood @ Data General <wood@dg-rtp.dg.com> writes to his gnu_beta mailing list regarding his latest release of the DG version of GCC: > Here are the patches for 1.37.27. These should apply just fine to > 1.37.26. The changes are: > > * Ron Guilmette's dwarf changes have been integrated. This > includes some changes to SDB information. For those of you do don't already know, DWARF is the name given to the new debugging information format used in System V Release 4. These patches may be obtained as part of a complete DG version of GCC via anonmous FTP from dg-rtp.dg.com in the pub/gnu subdirectory. I hope to also make available patches to GDB (in the not too distant future) which provide support for DWARF debugging information, either embedded within V.4 ELF object files or within old System V COFF files. In the meantime, if you have System V Release 4, I encourage you to play with the DWARF support provided in Tom's recent release of DG GCC. One thing that you should be aware of is that the DWARF support has only been tested for use with 88000-based systems. It may work on other types of systems, but that is not assured. I encourage all users of the DWARF support patches for GCC to put: #define DWARF_DESCRIBE_FILES in your tm-*.h files. This causes additional information about filenames (and especially include filenames) to be added to your object files. At some point, GDB may find this extra information particularly useful. In any case, it causes no incompatabilities with existing DWARF tools to use this optional feature, and using it increases the size of object files (but not the loaded part of object files) very little, so I suggest that you use it from day one. Once you get Tom Wood's latest version of GCC (DG 1.37.26) you should also apply the following minor patches. These cleanup some minor problems with the DWARF_LOCATION_ATTRIBUTES extension and add additional information to the README.DWARF file which more clearly describes the effects of using the DWARF_DESCRIBE_FILES extension. Tom will be incorporating these patches into his GCC version DG/1.37.28. Oh, yea. You should definitely read the README.DWARF files. Enjoy, // rfg *** dwarfout.c- Sun Nov 11 18:36:55 1990 --- dwarfout.c Mon Nov 5 20:25:34 1990 *************** *** 94,99 **** #endif #define AT_GAP 0x10 ! #define AT_file (AT_string_length+AT_GAP|FORM_DATA4) ! #define AT_line (AT_file+AT_GAP|FORM_ADDR) #endif --- 94,99 ---- #endif #define AT_GAP 0x10 ! #define AT_file ((AT_string_length&~FORM_MASK)+AT_GAP|FORM_ADDR) ! #define AT_line ((AT_file&~FORM_MASK)+AT_GAP|FORM_DATA4) #endif *************** *** 1454,1458 **** char label[MAX_ARTIFICIAL_LABEL_BYTES]; ! ASM_OUTPUT_DWARF_ATTRIBUTE (asm_out_file, AT_string_length); sprintf (label, FILE_ENTRY_LABEL_FMT, file_number); ASM_OUTPUT_DWARF_ADDR (asm_out_file, label); --- 1454,1458 ---- char label[MAX_ARTIFICIAL_LABEL_BYTES]; ! ASM_OUTPUT_DWARF_ATTRIBUTE (asm_out_file, AT_file); sprintf (label, FILE_ENTRY_LABEL_FMT, file_number); ASM_OUTPUT_DWARF_ADDR (asm_out_file, label); *** README.DWARF- Wed Oct 24 14:29:03 1990 --- README.DWARF Sun Nov 11 19:16:48 1990 *************** *** 8,20 **** This file accompanies a set of patches (i.e. a patch kit) to the Data General ! 1.37.26 version of the GNU C compiler (GCC). When applied to the DG ! 1.37.26 version of GCC, the result should be a version of GCC which is able to generate DWARF debugging information for systems based on the ! Motorola 88000 processor. No attempt has been made to insure that the ! patch kit is either useful or correct when used with other versions of ! GCC or when used for other target processors. In short, if it don't ! work for non-88k systems, or for GCC releases other than the one specified ! here, don't blame me. The DWARF patches have been generously donated by Network Computing Devices to the Free Software Foundation, and are covered under the GNU General Public --- 8,26 ---- This file accompanies a set of patches (i.e. a patch kit) to the Data General ! 1.37.27 version of the GNU C compiler (GCC). When applied to the DG ! 1.37.27 version of GCC, the result should be a version of GCC which is able to generate DWARF debugging information for systems based on the ! Motorola 88000 processor. + Note that as of DG version 1.37.27 of GCC, all patches necessary for + generating DWARF debugging information have been completely pre-integrated + into DG versions of GCC. + + No attempt has been made to insure that the code which implements the + support for DWARF generation is either useful or correct when used with + other versions of GCC or when used for target processors other that 88k's. + In short, if it don't work for non-88k systems, or for GCC releases other + than the one specified here, don't blame me. + The DWARF patches have been generously donated by Network Computing Devices to the Free Software Foundation, and are covered under the GNU General Public *************** *** 251,255 **** Note that the implementation of full DWARF support for g++ is (as yet) unfinished. If you want to use DWARF debugging information with the g++ ! compiler you will have to finish the work yourself. -------------------------------- --- 257,263 ---- Note that the implementation of full DWARF support for g++ is (as yet) unfinished. If you want to use DWARF debugging information with the g++ ! compiler you will have to finish the work yourself. (Note: you may want ! to contact John Hassey @ DG <hassey@dg-rtp.dg.com> if you have a serious ! interest in this.) -------------------------------- *************** *** 298,304 **** code generated for each compilation unit. ! See the dwarfout.c file or the actual output of GCC for further information ! regarding the information generated into the .files and .finfo sections ! when this option is in effect. -------------------------------- --- 306,382 ---- code generated for each compilation unit. ! To understand this GNU DWARF extension, imagine that the sequence of entries ! in the .lines section is broken up into several subsections. Each contiguous ! sequence of .line entries which relates to a sequence of lines (or statements) ! from one particular file (either a `base' file or an `include' file) could ! be called a `line entries chunk' (LEC). ! ! For each LEC there is one entry in the .finfo section. ! ! Each *normal* entry in the .finfo section contains two parts: ! ! (1) A 4-byte pointer to the start of the first .line entry in the ! given LEC, and ! ! (2) a 4-byte pointer to a string in the .files section. ! ! Obviously, each .finfo entry allows you to find the relevant filename, and ! it also points you to the first .line entry that was generated as a result ! of having compiled a given source line from the given source file. ! ! Each subsequent .line entry should also be assumed to have been produced ! as a result of compiling yet more lines from the same file. The end of ! any given LEC is easily found by looking at the first 4-byte pointer in ! the *next* .finfo entry. That next .finfo entry points to a new and ! different LEC, so the preceeding LEC (implicitly) must have ended with ! the last .line section entry which occurs at the 2 1/2 words just before ! the address given in the first pointer of the new .finfo entry. ! ! The following picture may help to clarify this feature. Let's assume that ! `LE' stands for `.line entry'. Also, assume that `* 'stands for a pointer. ! ! ! .line section .finfo section .files section ! ---------------------------------------------------------------- ! ! LE <---------------------- * ! LE * -----------------> "foobar.c" <--- ! LE | ! LE | ! LE <---------------------- * | ! LE * -----------------> "foobar.h" <| | ! LE | | ! LE | | ! LE <---------------------- * | | ! LE * -----------------> "inner.h" | | ! LE | | ! LE <---------------------- * | | ! LE * ------------------------------- | ! LE | ! LE | ! LE | ! LE | ! LE <---------------------- * | ! LE * ----------------------------------- ! LE ! LE ! LE ! ! In effect, each entry in the .finfo section points to *both* a filename ! and to (the start of) a block of (consecutive) LEs. ! ! Note that just like in the .line section, there are specialized first and ! last entries in the .finfo section for each object file. These special ! first and last entries are different from normal ones and they can clearly ! indicate (to the debugger) where the set of .finfo entries for that object ! file begins and ends. The debugger will need this information in order ! to correctly interpret the .finfo entries. ! ! Note also that the first string in the .files section for each object file ! will be the full absolute pathname of the directory from which the compiler ! was invoked when the given object file was produced. This tells debuggers ! which directory all other (relative) pathnames in the .files section are ! relative to. Proper use of this `compilation directory' string can make ! commands like GDB's `directory' command obsolete. --------------------------------