GCC support for DWARF debugging info format now available
Ron Guilmette
lupine!rfg at uunet.uu.net
Wed Nov 14 18:35:46 AEST 1990
--text follows this line--
Tom Wood @ Data General <wood at 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 at 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.
--------------------------------
More information about the Comp.lang.c
mailing list