|
Packit |
cdaae3 |
\."
|
|
Packit |
cdaae3 |
\." the following line may be removed if the ff ligature works on your machine
|
|
Packit |
cdaae3 |
.lg 0
|
|
Packit |
cdaae3 |
\." set up heading formats
|
|
Packit |
cdaae3 |
.ds HF 3 3 3 3 3 2 2
|
|
Packit |
cdaae3 |
.ds HP +2 +2 +1 +0 +0
|
|
Packit |
cdaae3 |
.nr Hs 5
|
|
Packit |
cdaae3 |
.nr Hb 5
|
|
Packit |
cdaae3 |
\." ==============================================
|
|
Packit |
cdaae3 |
\." Put current date in the following at each rev
|
|
Packit |
cdaae3 |
.ds vE rev 1.18, 31 March 2005
|
|
Packit |
cdaae3 |
\." ==============================================
|
|
Packit |
cdaae3 |
\." ==============================================
|
|
Packit |
cdaae3 |
.ds | |
|
|
Packit |
cdaae3 |
.ds ~ ~
|
|
Packit |
cdaae3 |
.ds ' '
|
|
Packit |
cdaae3 |
.if t .ds Cw \&\f(CW
|
|
Packit |
cdaae3 |
.if n .ds Cw \fB
|
|
Packit |
cdaae3 |
.de Cf \" Place every other arg in Cw font, beginning with first
|
|
Packit |
cdaae3 |
.if \\n(.$=1 \&\*(Cw\\$1\fP
|
|
Packit |
cdaae3 |
.if \\n(.$=2 \&\*(Cw\\$1\fP\\$2
|
|
Packit |
cdaae3 |
.if \\n(.$=3 \&\*(Cw\\$1\fP\\$2\*(Cw\\$3\fP
|
|
Packit |
cdaae3 |
.if \\n(.$=4 \&\*(Cw\\$1\fP\\$2\*(Cw\\$3\fP\\$4
|
|
Packit |
cdaae3 |
.if \\n(.$=5 \&\*(Cw\\$1\fP\\$2\*(Cw\\$3\fP\\$4\*(Cw\\$5\fP
|
|
Packit |
cdaae3 |
.if \\n(.$=6 \&\*(Cw\\$1\fP\\$2\*(Cw\\$3\fP\\$4\*(Cw\\$5\fP\\$6
|
|
Packit |
cdaae3 |
.if \\n(.$=7 \&\*(Cw\\$1\fP\\$2\*(Cw\\$3\fP\\$4\*(Cw\\$5\fP\\$6\*(Cw\\$7\fP
|
|
Packit |
cdaae3 |
.if \\n(.$=8 \&\*(Cw\\$1\fP\\$2\*(Cw\\$3\fP\\$4\*(Cw\\$5\fP\\$6\*(Cw\\$7\fP\\$8
|
|
Packit |
cdaae3 |
.if \\n(.$=9 \&\*(Cw\\$1\fP\\$2\*(Cw\\$3\fP\\$4\*(Cw\\$5\fP\\$6\*(Cw\\$7\fP\\$8\
|
|
Packit |
cdaae3 |
*(Cw
|
|
Packit |
cdaae3 |
..
|
|
Packit |
cdaae3 |
.nr Cl 4
|
|
Packit |
cdaae3 |
.SA 1
|
|
Packit |
cdaae3 |
.TL
|
|
Packit |
cdaae3 |
MIPS Extensions to DWARF Version 2.0
|
|
Packit |
cdaae3 |
.AF ""
|
|
Packit |
cdaae3 |
.AU "Silicon Graphics Computer Systems"
|
|
Packit |
cdaae3 |
.PF "'\*(vE'- \\\\nP -''"
|
|
Packit |
cdaae3 |
.AS 1
|
|
Packit |
cdaae3 |
This document describes the MIPS/Silicon Graphics extensions
|
|
Packit |
cdaae3 |
to the "DWARF Information Format" (version 2.0.0 dated July 27, 1993).
|
|
Packit |
cdaae3 |
DWARF3 draft 8 (or draft 9) is out as of 2005, and
|
|
Packit |
cdaae3 |
is mentioned below where applicable.
|
|
Packit |
cdaae3 |
MIPS/IRIX compilers emit DWARF2 (with extensions).
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
Rather than alter the base documents to describe the extensions
|
|
Packit |
cdaae3 |
we provide this separate document.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
The extensions documented here are subject to change.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
It also describes known bugs resulting in incorrect dwarf usage.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
\*(vE
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.AE
|
|
Packit |
cdaae3 |
.MT 4
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 1 "INTRODUCTION"
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
This
|
|
Packit |
cdaae3 |
document describes MIPS extensions
|
|
Packit |
cdaae3 |
to the DWARF debugging information format.
|
|
Packit |
cdaae3 |
The extensions documented here are subject to change at
|
|
Packit |
cdaae3 |
any time.
|
|
Packit |
cdaae3 |
.H 1 "64 BIT DWARF"
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
The DWARF2 spec has no provision for 64 bit offsets.
|
|
Packit |
cdaae3 |
SGI-IRIX/MIPS Elf64 objects contain DWARF 2 with all offsets
|
|
Packit |
cdaae3 |
(and addresses) as 64bit values.
|
|
Packit |
cdaae3 |
This non-standard extension was adopted in 1992.
|
|
Packit |
cdaae3 |
Nothing in the dwarf itself identifies the dwarf as 64bit.
|
|
Packit |
cdaae3 |
This extension 64bit-offset dwarf cannot be mixed with 32bit-offset dwarf
|
|
Packit |
cdaae3 |
in a single object or executable, and SGI-IRIX/MIPS compilers
|
|
Packit |
cdaae3 |
and tools do not mix the sizes.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
In 2001 DWARF3 adopted a very different 64bit-offset
|
|
Packit |
cdaae3 |
format which can be mixed usefully with 32bit-offset DWARF2 or DWARF3.
|
|
Packit |
cdaae3 |
It is not very likely SGI-IRIX/MIPS compilers will switch to the
|
|
Packit |
cdaae3 |
now-standard
|
|
Packit |
cdaae3 |
DWARF3 64bit-offset scheme, but such a switch is theoretically
|
|
Packit |
cdaae3 |
possible and would be a good idea.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
SGI-IRIX/MIPS Elf32 objects
|
|
Packit |
cdaae3 |
contain DWARF2 with all offsets (and addresses) 32 bits.
|
|
Packit |
cdaae3 |
.H 1 "How much symbol information is emitted"
|
|
Packit |
cdaae3 |
The following standard DWARF V2 sections may be emitted:
|
|
Packit |
cdaae3 |
.AL
|
|
Packit |
cdaae3 |
.LI
|
|
Packit |
cdaae3 |
Section .debug_abbrev
|
|
Packit |
cdaae3 |
contains
|
|
Packit |
cdaae3 |
abbreviations supporting the .debug_info section.
|
|
Packit |
cdaae3 |
.LI
|
|
Packit |
cdaae3 |
Section .debug_info
|
|
Packit |
cdaae3 |
contains
|
|
Packit |
cdaae3 |
Debug Information Entries (DIEs).
|
|
Packit |
cdaae3 |
.LI
|
|
Packit |
cdaae3 |
Section .debug_frame
|
|
Packit |
cdaae3 |
contains
|
|
Packit |
cdaae3 |
stack frame descriptions.
|
|
Packit |
cdaae3 |
.LI
|
|
Packit |
cdaae3 |
Section .debug_line
|
|
Packit |
cdaae3 |
contains
|
|
Packit |
cdaae3 |
line number information.
|
|
Packit |
cdaae3 |
.LI
|
|
Packit |
cdaae3 |
Section .debug_aranges
|
|
Packit |
cdaae3 |
contains
|
|
Packit |
cdaae3 |
address range descriptions.
|
|
Packit |
cdaae3 |
.LI
|
|
Packit |
cdaae3 |
Section .debug_pubnames
|
|
Packit |
cdaae3 |
contains
|
|
Packit |
cdaae3 |
names of global functions and data.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
The following
|
|
Packit |
cdaae3 |
are MIPS extensions.
|
|
Packit |
cdaae3 |
Theses were created to allow debuggers to
|
|
Packit |
cdaae3 |
know names without having to look at
|
|
Packit |
cdaae3 |
the .debug_info section.
|
|
Packit |
cdaae3 |
.LI
|
|
Packit |
cdaae3 |
Section .debug_weaknames
|
|
Packit |
cdaae3 |
is a MIPS extension
|
|
Packit |
cdaae3 |
containing .debug_pubnames-like entries describing weak
|
|
Packit |
cdaae3 |
symbols.
|
|
Packit |
cdaae3 |
.LI
|
|
Packit |
cdaae3 |
Section .debug_funcnames
|
|
Packit |
cdaae3 |
is a MIPS extension
|
|
Packit |
cdaae3 |
containing .debug_pubnames-like entries describing file-static
|
|
Packit |
cdaae3 |
functions (C static functions).
|
|
Packit |
cdaae3 |
The gcc extension of nested subprograms (like Pascal)
|
|
Packit |
cdaae3 |
adds non-global non-static functions. These should be treated like
|
|
Packit |
cdaae3 |
static functions and gcc should add such to this section
|
|
Packit |
cdaae3 |
so that IRIX libexc(3C) will work correctly.
|
|
Packit |
cdaae3 |
Similarly, Ada functions which are non-global should be here too
|
|
Packit |
cdaae3 |
so that libexc(3C) can work.
|
|
Packit |
cdaae3 |
Putting it another way, every function (other than inline code)
|
|
Packit |
cdaae3 |
belongs either in .debug_pubnames or in .debug_funcnames
|
|
Packit |
cdaae3 |
or else libexc(3C) cannot find the function name.
|
|
Packit |
cdaae3 |
.LI
|
|
Packit |
cdaae3 |
Section .debug_varnames
|
|
Packit |
cdaae3 |
is a MIPS extension
|
|
Packit |
cdaae3 |
containing .debug_pubnames-like entries describing file-static
|
|
Packit |
cdaae3 |
data symbols (C static variables).
|
|
Packit |
cdaae3 |
.LI
|
|
Packit |
cdaae3 |
Section .debug_typenames
|
|
Packit |
cdaae3 |
is a MIPS extension
|
|
Packit |
cdaae3 |
containing .debug_pubnames-like entries describing file-level
|
|
Packit |
cdaae3 |
types.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
The following are not currently emitted.
|
|
Packit |
cdaae3 |
.LI
|
|
Packit |
cdaae3 |
Section .debug_macinfo
|
|
Packit |
cdaae3 |
Macro information is not currently emitted.
|
|
Packit |
cdaae3 |
.LI
|
|
Packit |
cdaae3 |
Section .debug_loc
|
|
Packit |
cdaae3 |
Location lists are not currently emitted.
|
|
Packit |
cdaae3 |
.LI
|
|
Packit |
cdaae3 |
Section .debug_str
|
|
Packit |
cdaae3 |
The string section is not currently emitted.
|
|
Packit |
cdaae3 |
.LE
|
|
Packit |
cdaae3 |
.H 2 "Overview of information emitted"
|
|
Packit |
cdaae3 |
We emit debug information in 3 flavors.
|
|
Packit |
cdaae3 |
We mention C here.
|
|
Packit |
cdaae3 |
The situation is essentially identical for f77, f90, and C++.
|
|
Packit |
cdaae3 |
.AL
|
|
Packit |
cdaae3 |
.LI
|
|
Packit |
cdaae3 |
"default C"
|
|
Packit |
cdaae3 |
We emit line information and DIEs for each subprogram.
|
|
Packit |
cdaae3 |
But no local symbols and no type information.
|
|
Packit |
cdaae3 |
Frame information is output.
|
|
Packit |
cdaae3 |
The DW_AT_producer string has the optimization level: for example
|
|
Packit |
cdaae3 |
"-O2".
|
|
Packit |
cdaae3 |
We put so much in the DW_AT_producer that the string
|
|
Packit |
cdaae3 |
is a significant user of space in .debug_info --
|
|
Packit |
cdaae3 |
this is perhaps a poor use of space.
|
|
Packit |
cdaae3 |
When optimizing the IRIX CC/cc option -DEBUG:optimize_space
|
|
Packit |
cdaae3 |
eliminates such wasted space.
|
|
Packit |
cdaae3 |
Debuggers only currently use the lack of -g
|
|
Packit |
cdaae3 |
of DW_AT_producer
|
|
Packit |
cdaae3 |
as a hint as to how a 'step' command should be interpreted, and
|
|
Packit |
cdaae3 |
the rest of the string is not used for anything (unless
|
|
Packit |
cdaae3 |
a human looks at it for some reason), so if space-on-disk
|
|
Packit |
cdaae3 |
is an issue, it is quite appropriate to use -DEBUG:optimize_space
|
|
Packit |
cdaae3 |
and save disk space.
|
|
Packit |
cdaae3 |
Every function definition (not inline instances though) is mentioned
|
|
Packit |
cdaae3 |
in either .debug_pubnames or .debug_funcnames.
|
|
Packit |
cdaae3 |
This is crucial to allow libexc(3C) stack-traceback to work and
|
|
Packit |
cdaae3 |
show function names (for all languages).
|
|
Packit |
cdaae3 |
.LI
|
|
Packit |
cdaae3 |
"C with full symbols"
|
|
Packit |
cdaae3 |
All possible info is emitted.
|
|
Packit |
cdaae3 |
DW_AT_producer string has all options that might be of interest,
|
|
Packit |
cdaae3 |
which includes -D's, -U's, and the -g option.
|
|
Packit |
cdaae3 |
These options look like they came from the command line.
|
|
Packit |
cdaae3 |
We put so much in the DW_AT_producer that the string
|
|
Packit |
cdaae3 |
is a significant user of space in .debug_info.
|
|
Packit |
cdaae3 |
this is perhaps a poor use of space.
|
|
Packit |
cdaae3 |
Debuggers only currently use the -g
|
|
Packit |
cdaae3 |
of DW_AT_producer
|
|
Packit |
cdaae3 |
as a hint as to how a 'step' command should be interpreted, and
|
|
Packit |
cdaae3 |
the rest of the string is not used for anything (unless
|
|
Packit |
cdaae3 |
a human looks at it for some reason).
|
|
Packit |
cdaae3 |
Every function definition (not inline instances though) is mentioned
|
|
Packit |
cdaae3 |
in either .debug_pubnames or .debug_funcnames.
|
|
Packit |
cdaae3 |
This is crucial to allow libexc(3C) stack-traceback to work and
|
|
Packit |
cdaae3 |
show function names (for all languages).
|
|
Packit |
cdaae3 |
.LI
|
|
Packit |
cdaae3 |
"Assembler (-g, non -g are the same)"
|
|
Packit |
cdaae3 |
Frame information is output.
|
|
Packit |
cdaae3 |
No type information is emitted, but DIEs are prepared
|
|
Packit |
cdaae3 |
for globals.
|
|
Packit |
cdaae3 |
.LE
|
|
Packit |
cdaae3 |
.H 2 "Detecting 'full symbols' (-g)"
|
|
Packit |
cdaae3 |
The debugger depends on the existence of
|
|
Packit |
cdaae3 |
the DW_AT_producer string to determine if the
|
|
Packit |
cdaae3 |
compilation unit has full symbols or not.
|
|
Packit |
cdaae3 |
It looks for -g or -g[123] and accepts these as
|
|
Packit |
cdaae3 |
full symbols but an absent -g or a present -g0
|
|
Packit |
cdaae3 |
is taken to mean that only basic symbols are defined and there
|
|
Packit |
cdaae3 |
are no local symbols and no type information.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
In various contexts the debugger will think the program is
|
|
Packit |
cdaae3 |
stripped or 'was not compiled with -g' unless the -g
|
|
Packit |
cdaae3 |
is in the DW_AT_producer string.
|
|
Packit |
cdaae3 |
.H 2 "DWARF and strip(1)"
|
|
Packit |
cdaae3 |
The DWARF section ".debug_frame" is marked SHF_MIPS_NOSTRIP
|
|
Packit |
cdaae3 |
and is not stripped by the strip(1) program.
|
|
Packit |
cdaae3 |
This is because the section is needed for doing
|
|
Packit |
cdaae3 |
stack back traces (essential for C++
|
|
Packit |
cdaae3 |
and Ada exception handling).
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
All .debug_* sections are marked with elf type
|
|
Packit |
cdaae3 |
SHT_MIPS_DWARF.
|
|
Packit |
cdaae3 |
Applications needing to access the various DWARF sections
|
|
Packit |
cdaae3 |
must use the section name to discriminate between them.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "Evaluating location expressions"
|
|
Packit |
cdaae3 |
When the debugger evaluates location expressions, it does so
|
|
Packit |
cdaae3 |
in 2 stages. In stage one it simply looks for the trivial
|
|
Packit |
cdaae3 |
location expressions and treats those as special cases.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
If the location expression is not trivial, it enters stage two.
|
|
Packit |
cdaae3 |
In this case it uses a stack to evaluate the expression.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
If the application is a 32-bit application, it does the operations
|
|
Packit |
cdaae3 |
on 32-bit values (address size values). Even though registers
|
|
Packit |
cdaae3 |
can be 64 bits in a 32-bit program all evaluations are done in
|
|
Packit |
cdaae3 |
32-bit quantities, so an attempt to calculate a 32-bit quantity
|
|
Packit |
cdaae3 |
by taking the difference of 2 64-bit register values will not
|
|
Packit |
cdaae3 |
work. The notion is that the stack machine is, by the dwarf
|
|
Packit |
cdaae3 |
definition, working in address size units.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
These values are then expanded to 64-bit values (addresses or
|
|
Packit |
cdaae3 |
offsets). This extension does not involve sign-extension.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
If the application is a 64-bit application, then the stack
|
|
Packit |
cdaae3 |
values are all 64 bits and all operations are done on 64 bits.
|
|
Packit |
cdaae3 |
.H 3 "The fbreg location op"
|
|
Packit |
cdaae3 |
Compilers shipped with IRIX 6.0 and 6.1
|
|
Packit |
cdaae3 |
do not emit the fbreg location expression
|
|
Packit |
cdaae3 |
and never emit the DW_AT_frame_base attribute that it
|
|
Packit |
cdaae3 |
depends on.
|
|
Packit |
cdaae3 |
However, this changes
|
|
Packit |
cdaae3 |
with release 6.2 and these are now emitted routinely.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 1 "Frame Information"
|
|
Packit |
cdaae3 |
.H 2 "Initial Instructions"
|
|
Packit |
cdaae3 |
The DWARF V2 spec
|
|
Packit |
cdaae3 |
provides for "initial instructions" in each CIE (page 61,
|
|
Packit |
cdaae3 |
section 6.4.1).
|
|
Packit |
cdaae3 |
However, it does not say whether there are default
|
|
Packit |
cdaae3 |
values for each column (register).
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
Rather than force every CIE to have a long list
|
|
Packit |
cdaae3 |
of bytes to initialize all 32 integer registers,
|
|
Packit |
cdaae3 |
we define that the default values of all registers
|
|
Packit |
cdaae3 |
(as returned by libdwarf in the frame interface)
|
|
Packit |
cdaae3 |
are 'same value'.
|
|
Packit |
cdaae3 |
This is a good choice for many non-register-windows
|
|
Packit |
cdaae3 |
implementations.
|
|
Packit |
cdaae3 |
.H 2 "Augmentation string in debug_frame"
|
|
Packit |
cdaae3 |
The augmentation string we use in shipped compilers (up thru
|
|
Packit |
cdaae3 |
irix6.2) is the empty string.
|
|
Packit |
cdaae3 |
IRIX6.2 and later has an augmentation string
|
|
Packit |
cdaae3 |
the empty string ("")
|
|
Packit |
cdaae3 |
or "z" or "mti v1"
|
|
Packit |
cdaae3 |
where the "v1" is a version number (version 1).
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
We do not believe that "mti v1" was emitted as the
|
|
Packit |
cdaae3 |
augmentation string in any shipped compiler.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
.H 3 "CIE processing based on augmentation string:"
|
|
Packit |
cdaae3 |
If the augmentation string begins with 'z', then it is followed
|
|
Packit |
cdaae3 |
immediately by a unsigned_leb_128 number giving the code alignment factor.
|
|
Packit |
cdaae3 |
Next is a signed_leb_128 number giving the data alignment factor.
|
|
Packit |
cdaae3 |
Next is a unsigned byte giving the number of the return address register.
|
|
Packit |
cdaae3 |
Next is an unsigned_leb_128 number giving the length of the 'augmentation'
|
|
Packit |
cdaae3 |
fields (the length of augmentation bytes, not
|
|
Packit |
cdaae3 |
including the unsigned_leb_128 length itself).
|
|
Packit |
cdaae3 |
As of release 6.2, the length of the CIE augmentation fields is 0.
|
|
Packit |
cdaae3 |
What this means is that it is possible to add new
|
|
Packit |
cdaae3 |
augmentations, z1, z2, etc and yet an old consumer to
|
|
Packit |
cdaae3 |
understand the entire CIE as it can bypass the
|
|
Packit |
cdaae3 |
augmentation it does not understand because the
|
|
Packit |
cdaae3 |
length of the augmentation fields is present.
|
|
Packit |
cdaae3 |
Presuming of course that all augmentation fields are
|
|
Packit |
cdaae3 |
simply additional information,
|
|
Packit |
cdaae3 |
not some 'changing of the meaning of
|
|
Packit |
cdaae3 |
an existing field'.
|
|
Packit |
cdaae3 |
Currently there is no CIE data in the augmentation for things
|
|
Packit |
cdaae3 |
beginning with 'z'.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
If the augmentation string is "mti v1" or "" then it is followed
|
|
Packit |
cdaae3 |
immediately by a unsigned_leb_128 number giving the code alignment factor.
|
|
Packit |
cdaae3 |
Next is a signed_leb_128 number giving the data alignment factor.
|
|
Packit |
cdaae3 |
Next is a unsigned byte giving the number of the return address register.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
If the augmentation string is something else, then the
|
|
Packit |
cdaae3 |
code alignment factor is assumed to be 4 and the data alignment
|
|
Packit |
cdaae3 |
factor is assumed to be -1 and the return
|
|
Packit |
cdaae3 |
address register is assumed to be 31. Arbitrarily.
|
|
Packit |
cdaae3 |
The library (libdwarf) assumes it does not understand the rest of the CIE.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
.H 3 "FDE processing based on augmentation"
|
|
Packit |
cdaae3 |
If the CIE augmentation string
|
|
Packit |
cdaae3 |
for an fde begins with 'z'
|
|
Packit |
cdaae3 |
then the next FDE field after the address_range field
|
|
Packit |
cdaae3 |
is an
|
|
Packit |
cdaae3 |
unsigned_leb_128 number giving the length of the 'augmentation'
|
|
Packit |
cdaae3 |
fields, and those fields follow immediately.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 4 "FDE augmentation fields"
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
If the CIE augmentation string is "mti v1" or ""
|
|
Packit |
cdaae3 |
then the FDE is exactly as described in the Dwarf Document section 6.4.1.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
Else, if the CIE augmentation string begins with "z"
|
|
Packit |
cdaae3 |
then the next field after the FDE augmentation length field
|
|
Packit |
cdaae3 |
is a Dwarf_Sword size offset into
|
|
Packit |
cdaae3 |
exception tables.
|
|
Packit |
cdaae3 |
If the CIE augmentation string does not begin with "z"
|
|
Packit |
cdaae3 |
(and is neither "mti v1" nor "")
|
|
Packit |
cdaae3 |
the FDE augmentation fields are skipped (not understood).
|
|
Packit |
cdaae3 |
Note that libdwarf actually (as of MIPSpro7.3 and earlier)
|
|
Packit |
cdaae3 |
only tests that the initial character of the augmentation
|
|
Packit |
cdaae3 |
string is 'z', and ignores the rest of the string, if any.
|
|
Packit |
cdaae3 |
So in reality the test is for a _prefix_ of 'z'.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
If the CIE augmentation string neither starts with 'z' nor is ""
|
|
Packit |
cdaae3 |
nor is "mti v1" then libdwarf (incorrectly) assumes that the
|
|
Packit |
cdaae3 |
table defining instructions start next.
|
|
Packit |
cdaae3 |
Processing (in libdwarf) will be incorrect.
|
|
Packit |
cdaae3 |
.H 2 "Stack Pointer recovery from debug_frame"
|
|
Packit |
cdaae3 |
There is no identifiable means in
|
|
Packit |
cdaae3 |
DWARF2 to say that the stack register is
|
|
Packit |
cdaae3 |
recovered by any particular operation.
|
|
Packit |
cdaae3 |
A 'register rule' works if the caller's
|
|
Packit |
cdaae3 |
stack pointer was copied to another
|
|
Packit |
cdaae3 |
register.
|
|
Packit |
cdaae3 |
An 'offset(N)' rule works if the caller's
|
|
Packit |
cdaae3 |
stack pointer was stored on the stack.
|
|
Packit |
cdaae3 |
However if the stack pointer is
|
|
Packit |
cdaae3 |
some register value plus/minus some offset,
|
|
Packit |
cdaae3 |
there is no means to say this in an FDE.
|
|
Packit |
cdaae3 |
For MIPS/IRIX, the recovered stack pointer
|
|
Packit |
cdaae3 |
of the next frame up the stack (towards main())
|
|
Packit |
cdaae3 |
is simply the CFA value of the current
|
|
Packit |
cdaae3 |
frame, and the CFA value is
|
|
Packit |
cdaae3 |
precisely a register (value of a register)
|
|
Packit |
cdaae3 |
or a register plus offset (value of a register
|
|
Packit |
cdaae3 |
plus offset). This is a software convention.
|
|
Packit |
cdaae3 |
.H 1 "egcs dwarf extensions (egcs-1.1.2 extensions)"
|
|
Packit |
cdaae3 |
This and following egcs sections describe
|
|
Packit |
cdaae3 |
the extensions currently shown in egcs dwarf2.
|
|
Packit |
cdaae3 |
Note that egcs has chosen to adopt tag and
|
|
Packit |
cdaae3 |
attribute naming as if their choices were
|
|
Packit |
cdaae3 |
standard dwarf, not as if they were extensions.
|
|
Packit |
cdaae3 |
However, they are properly numbered as extensions.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "DW_TAG_format_label 0x4101"
|
|
Packit |
cdaae3 |
For FORTRAN 77, Fortran 90.
|
|
Packit |
cdaae3 |
Details of use not defined in egcs source, so
|
|
Packit |
cdaae3 |
unclear if used.
|
|
Packit |
cdaae3 |
.H 2 "DW_TAG_function_template 0x4102"
|
|
Packit |
cdaae3 |
For C++.
|
|
Packit |
cdaae3 |
Details of use not defined in egcs source, so
|
|
Packit |
cdaae3 |
unclear if used.
|
|
Packit |
cdaae3 |
.H 2 "DW_TAG_class_template 0x4103"
|
|
Packit |
cdaae3 |
For C++.
|
|
Packit |
cdaae3 |
Details of use not defined in egcs source, so
|
|
Packit |
cdaae3 |
unclear if used.
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_sf_names 0x2101"
|
|
Packit |
cdaae3 |
Apparently only output in DWARF1, not DWARF2.
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_src_info 0x2102"
|
|
Packit |
cdaae3 |
Apparently only output in DWARF1, not DWARF2.
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_mac_info 0x2103"
|
|
Packit |
cdaae3 |
Apparently only output in DWARF1, not DWARF2.
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_src_coords 0x2104"
|
|
Packit |
cdaae3 |
Apparently only output in DWARF1, not DWARF2.
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_body_begin 0x2105"
|
|
Packit |
cdaae3 |
Apparently only output in DWARF1, not DWARF2.
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_body_end 0x2106"
|
|
Packit |
cdaae3 |
Apparently only output in DWARF1, not DWARF2.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 1 "egcs .eh_frame (non-sgi) (egcs-1.1.2 extensions)"
|
|
Packit |
cdaae3 |
egcs-1.1.2 (and earlier egcs)
|
|
Packit |
cdaae3 |
emits by default a section named .eh_frame
|
|
Packit |
cdaae3 |
for ia32 (and possibly other platforms) which
|
|
Packit |
cdaae3 |
is nearly identical to .debug_frame in format and content.
|
|
Packit |
cdaae3 |
This section is used for helping handle C++ exceptions.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
Because after linking there are sometimes zero-ed out bytes
|
|
Packit |
cdaae3 |
at the end of the eh_frame section, the reader code in
|
|
Packit |
cdaae3 |
dwarf_frame.c considers a zero cie/fde length as an indication
|
|
Packit |
cdaae3 |
that it is the end of the section.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
.H 2 "CIE_id 0"
|
|
Packit |
cdaae3 |
The section is an ALLOCATED section in an executable, and
|
|
Packit |
cdaae3 |
is therefore mapped into memory at run time.
|
|
Packit |
cdaae3 |
The CIE_pointer (aka CIE_id, section 6.4.1
|
|
Packit |
cdaae3 |
of the DWARF2 document) is the field that
|
|
Packit |
cdaae3 |
distinguishes a CIE from an FDE.
|
|
Packit |
cdaae3 |
The designers of the egcs .eh_frame section
|
|
Packit |
cdaae3 |
decided to make the CIE_id
|
|
Packit |
cdaae3 |
be 0 as the CIE_pointer definition is
|
|
Packit |
cdaae3 |
.in +2
|
|
Packit |
cdaae3 |
the number of bytes from the CIE-pointer in the FDE back to the
|
|
Packit |
cdaae3 |
applicable CIE.
|
|
Packit |
cdaae3 |
.in -2
|
|
Packit |
cdaae3 |
In a dwarf .debug_frame section, the CIE_pointer is the
|
|
Packit |
cdaae3 |
offset in .debug_frame of the CIE for this fde, and
|
|
Packit |
cdaae3 |
since an offset can be zero of some CIE, the CIE_id
|
|
Packit |
cdaae3 |
cannot be 0, but must be all 1 bits .
|
|
Packit |
cdaae3 |
Note that the dwarf2.0 spec does specify the value of CIE_id
|
|
Packit |
cdaae3 |
as 0xffffffff
|
|
Packit |
cdaae3 |
(see section 7.23 of v2.0.0),
|
|
Packit |
cdaae3 |
though earlier versions of this extensions document
|
|
Packit |
cdaae3 |
incorrectly said it was not specified in the dwarf
|
|
Packit |
cdaae3 |
document.
|
|
Packit |
cdaae3 |
.H 2 "augmentation eh"
|
|
Packit |
cdaae3 |
The augmentation string in each CIE is "eh"
|
|
Packit |
cdaae3 |
which, with its following NUL character, aligns
|
|
Packit |
cdaae3 |
the following word to a 32bit boundary.
|
|
Packit |
cdaae3 |
Following the augmentation string is a 32bit
|
|
Packit |
cdaae3 |
word with the address of the __EXCEPTION_TABLE__,
|
|
Packit |
cdaae3 |
part of the exception handling data for egcs.
|
|
Packit |
cdaae3 |
.H 2 "DW_CFA_GNU_window_save 0x2d"
|
|
Packit |
cdaae3 |
This is effectively a flag for architectures with
|
|
Packit |
cdaae3 |
register windows, and tells the unwinder code that
|
|
Packit |
cdaae3 |
it must look to a previous frame for the
|
|
Packit |
cdaae3 |
correct register window set.
|
|
Packit |
cdaae3 |
As of this writing, egcs gcc/frame.c
|
|
Packit |
cdaae3 |
indicates this is for SPARC register windows.
|
|
Packit |
cdaae3 |
.H 2 "DW_CFA_GNU_args_size 0x2e"
|
|
Packit |
cdaae3 |
DW_CFA_GNU_args_size has a single uleb128 argument
|
|
Packit |
cdaae3 |
which is the size, in bytes, of the function's stack
|
|
Packit |
cdaae3 |
at that point in the function.
|
|
Packit |
cdaae3 |
.H 2 "__EXCEPTION_TABLE__"
|
|
Packit |
cdaae3 |
A series of 3 32bit word entries by default:
|
|
Packit |
cdaae3 |
0 word: low pc address
|
|
Packit |
cdaae3 |
1 word: high pc address
|
|
Packit |
cdaae3 |
2 word: pointer to exception handler code
|
|
Packit |
cdaae3 |
The end of the table is
|
|
Packit |
cdaae3 |
signaled by 2 words of -1 (not 3 words!).
|
|
Packit |
cdaae3 |
.H 1 "Interpretations of the DWARF V2 spec"
|
|
Packit |
cdaae3 |
.H 2 "template TAG spellings"
|
|
Packit |
cdaae3 |
The DWARF V2 spec spells two attributes in two ways.
|
|
Packit |
cdaae3 |
DW_TAG_template_type_param
|
|
Packit |
cdaae3 |
(listed in Figure 1, page 7)
|
|
Packit |
cdaae3 |
is spelled DW_TAG_template_type_parameter
|
|
Packit |
cdaae3 |
in the body of the document (section 3.3.7, page 28).
|
|
Packit |
cdaae3 |
We have adopted the spelling
|
|
Packit |
cdaae3 |
DW_TAG_template_type_param.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
DW_TAG_template_value_param
|
|
Packit |
cdaae3 |
(listed in Figure 1, page 7)
|
|
Packit |
cdaae3 |
is spelled DW_TAG_template_value_parameter
|
|
Packit |
cdaae3 |
in the body of the document (section 3.3.7, page 28).
|
|
Packit |
cdaae3 |
We have adopted the spelling
|
|
Packit |
cdaae3 |
DW_TAG_template_value_parameter.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
We recognize that the choices adopted are neither consistently
|
|
Packit |
cdaae3 |
the longer nor the shorter name.
|
|
Packit |
cdaae3 |
This inconsistency was an accident.
|
|
Packit |
cdaae3 |
.H 2 DW_FORM_ref_addr confusing
|
|
Packit |
cdaae3 |
Section 7.5.4, Attribute Encodings, describes
|
|
Packit |
cdaae3 |
DW_FORM_ref_addr.
|
|
Packit |
cdaae3 |
The description says the reference is the size of an address
|
|
Packit |
cdaae3 |
on the target architecture.
|
|
Packit |
cdaae3 |
This is surely a mistake, because on a 16bit-pointer-architecture
|
|
Packit |
cdaae3 |
it would mean that the reference could not exceed
|
|
Packit |
cdaae3 |
16 bits, which makes only
|
|
Packit |
cdaae3 |
a limited amount of sense as the reference is from one
|
|
Packit |
cdaae3 |
part of the dwarf to another, and could (in theory)
|
|
Packit |
cdaae3 |
be *on the disk* and not limited to what fits in memory.
|
|
Packit |
cdaae3 |
Since MIPS is 32 bit pointers (at the smallest)
|
|
Packit |
cdaae3 |
the restriction is not a problem for MIPS/SGI.
|
|
Packit |
cdaae3 |
The 32bit pointer ABIs are limited to 32 bit section sizes
|
|
Packit |
cdaae3 |
anyway (as a result of implementation details).
|
|
Packit |
cdaae3 |
And the 64bit pointer ABIs currently have the same limit
|
|
Packit |
cdaae3 |
as a result of how the compilers and tools are built
|
|
Packit |
cdaae3 |
(this has not proven to be a limit in practice, so far).
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
This has been clarified in the DWARF3 spec and the IRIX use
|
|
Packit |
cdaae3 |
of DW_FORM_ref_addr being an offset is correct.
|
|
Packit |
cdaae3 |
.H 2 "Section .debug_macinfo in a debugger"
|
|
Packit |
cdaae3 |
It seems quite difficult, in general, to
|
|
Packit |
cdaae3 |
tie specific text(code) addresses to points in the
|
|
Packit |
cdaae3 |
stream of macro information for a particular compilation unit.
|
|
Packit |
cdaae3 |
So it's been difficult to see how to design a consumer
|
|
Packit |
cdaae3 |
interface to libdwarf for macro information.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
The best (simple to implement, easy for a debugger user to
|
|
Packit |
cdaae3 |
understand) candidate seems to be that
|
|
Packit |
cdaae3 |
the debugger asks for macros of a given name in a compilation
|
|
Packit |
cdaae3 |
unit, and the debugger responds with *all* the macros of that name.
|
|
Packit |
cdaae3 |
.H 3 "only a single choice exists"
|
|
Packit |
cdaae3 |
If there is exactly one, that is usable in expressions, if the
|
|
Packit |
cdaae3 |
debugger is able to evaluate such.
|
|
Packit |
cdaae3 |
.H 3 "multiple macros with same name".
|
|
Packit |
cdaae3 |
If there are multiple macros with the same name
|
|
Packit |
cdaae3 |
in a compilation unit,
|
|
Packit |
cdaae3 |
the debugger (and the debugger user and the application
|
|
Packit |
cdaae3 |
programmer) have
|
|
Packit |
cdaae3 |
a problem: confusion is quite possible.
|
|
Packit |
cdaae3 |
If the macros are simple the
|
|
Packit |
cdaae3 |
debugger user can simply substitute by hand in an expression.
|
|
Packit |
cdaae3 |
If the macros are complicated hand substitution will be
|
|
Packit |
cdaae3 |
impractical, and the debugger will have to identify the
|
|
Packit |
cdaae3 |
choices and let the debugger user choose an interpretation.
|
|
Packit |
cdaae3 |
.H 2 "Section 6.1.2 Lookup by address problem"
|
|
Packit |
cdaae3 |
Each entry is a beginning-address followed by a length.
|
|
Packit |
cdaae3 |
And the distinguished entry 0,0 is used to denote
|
|
Packit |
cdaae3 |
the end of a range of entries.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
This means that one must be careful not to emit a zero length,
|
|
Packit |
cdaae3 |
as in a .o (object file) the beginning address of
|
|
Packit |
cdaae3 |
a normal entry might be 0 (it is a section offset after all),
|
|
Packit |
cdaae3 |
and the resulting 0,0 would be taken as end-of-range, not
|
|
Packit |
cdaae3 |
as a valid entry.
|
|
Packit |
cdaae3 |
A dwarf dumper would have trouble with such data
|
|
Packit |
cdaae3 |
in an object file.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
In an a.out or shared object (dynamic shared object, DSO)
|
|
Packit |
cdaae3 |
no text will be at address zero so in such this problem does
|
|
Packit |
cdaae3 |
not arise.
|
|
Packit |
cdaae3 |
.H 2 "Section 5.10 Subrange Type Entries problem"
|
|
Packit |
cdaae3 |
It is specified that DW_AT_upper_bound (and lower bound)
|
|
Packit |
cdaae3 |
must be signed entries if there is no object type
|
|
Packit |
cdaae3 |
info to specify the bound type (Sec 5.10, end of section).
|
|
Packit |
cdaae3 |
One cannot tell (with some
|
|
Packit |
cdaae3 |
dwarf constant types) what the signedness is from the
|
|
Packit |
cdaae3 |
form itself (like DW_FORM_data1), so it is necessary
|
|
Packit |
cdaae3 |
to determine the object and type according to the rules
|
|
Packit |
cdaae3 |
in 5.10 and then if all that fails, the type is signed.
|
|
Packit |
cdaae3 |
It's a bit complicated and earlier versions of mips_extensions
|
|
Packit |
cdaae3 |
incorrectly said signedness was not defined.
|
|
Packit |
cdaae3 |
.H 2 "Section 5.5.6 Class Template Instantiations problem"
|
|
Packit |
cdaae3 |
Lots of room for implementor to canonicalize
|
|
Packit |
cdaae3 |
template declarations. Ie various folks won't agree.
|
|
Packit |
cdaae3 |
This is not serious since a given compiler
|
|
Packit |
cdaae3 |
will be consistent with itself and debuggers
|
|
Packit |
cdaae3 |
will have to cope!
|
|
Packit |
cdaae3 |
.H 2 "Section 2.4.3.4 # 11. operator spelling"
|
|
Packit |
cdaae3 |
DW_OP_add should be DW_OP_plus (page 14)
|
|
Packit |
cdaae3 |
(this mistake just one place on the page).
|
|
Packit |
cdaae3 |
.H 2 "No clear specification of C++ static funcs"
|
|
Packit |
cdaae3 |
There is no clear way to tell if a C++ member function
|
|
Packit |
cdaae3 |
is a static member or a non-static member function.
|
|
Packit |
cdaae3 |
(dwarf2read.c in gdb 4.18, for example, has this observation)
|
|
Packit |
cdaae3 |
.H 2 "Misspelling of DW_AT_const_value"
|
|
Packit |
cdaae3 |
Twice in appendix 1, DW_AT_const_value is misspelled
|
|
Packit |
cdaae3 |
as DW_AT_constant_value.
|
|
Packit |
cdaae3 |
.H 2 "Mistake in Atribute Encodings"
|
|
Packit |
cdaae3 |
Section 7.5.4, "Attribute Encodings"
|
|
Packit |
cdaae3 |
has a brief discussion of "constant"
|
|
Packit |
cdaae3 |
which says there are 6 forms of constants.
|
|
Packit |
cdaae3 |
It is incorrect in that it fails to mention (or count)
|
|
Packit |
cdaae3 |
the block forms, which are clearly allowed by
|
|
Packit |
cdaae3 |
section 4.1 "Data Object Entries" (see entry number 9 in
|
|
Packit |
cdaae3 |
the numbered list, on constants).
|
|
Packit |
cdaae3 |
.H 2 "DW_OP_bregx"
|
|
Packit |
cdaae3 |
The description of DW_OP_bregx in 2.4.3.2 (Register Based
|
|
Packit |
cdaae3 |
Addressing) is slightly misleading, in that it
|
|
Packit |
cdaae3 |
lists the offset first.
|
|
Packit |
cdaae3 |
As section 7.7.1 (Location Expression)
|
|
Packit |
cdaae3 |
makes clear, in the encoding the register number
|
|
Packit |
cdaae3 |
comes first.
|
|
Packit |
cdaae3 |
.H 1 "MIPS attributes"
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_MIPS_fde"
|
|
Packit |
cdaae3 |
This extension to Dwarf appears only on subprogram TAGs and has as
|
|
Packit |
cdaae3 |
its value the offset, in the .debug_frame section, of the fde which
|
|
Packit |
cdaae3 |
describes the frame of this function. It is an optimization of
|
|
Packit |
cdaae3 |
sorts to have this present.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "DW_CFA_MIPS_advance_loc8 0x1d"
|
|
Packit |
cdaae3 |
This obvious extension to dwarf line tables enables encoding of 8 byte
|
|
Packit |
cdaae3 |
advance_loc values (for cases when such must be relocatable,
|
|
Packit |
cdaae3 |
and thus must be full length). Applicable only to 64-bit objects.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "DW_TAG_MIPS_loop 0x4081"
|
|
Packit |
cdaae3 |
For future use. Not currently emitted.
|
|
Packit |
cdaae3 |
Places to be emitted and attributes that this might own
|
|
Packit |
cdaae3 |
not finalized.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_MIPS_loop_begin 0x2002"
|
|
Packit |
cdaae3 |
For future use. Not currently emitted.
|
|
Packit |
cdaae3 |
Attribute form and content not finalized.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_MIPS_tail_loop_begin 0x2003"
|
|
Packit |
cdaae3 |
For future use. Not currently emitted.
|
|
Packit |
cdaae3 |
Attribute form and content not finalized.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_MIPS_epilog_begin 0x2004"
|
|
Packit |
cdaae3 |
For future use. Not currently emitted.
|
|
Packit |
cdaae3 |
Attribute form and content not finalized.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_MIPS_loop_unroll_factor 0x2005"
|
|
Packit |
cdaae3 |
For future use. Not currently emitted.
|
|
Packit |
cdaae3 |
Attribute form and content not finalized.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_MIPS_software_pipeline_depth 0x2006"
|
|
Packit |
cdaae3 |
For future use. Not currently emitted.
|
|
Packit |
cdaae3 |
Attribute form and content not finalized.
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_MIPS_linkage_name 0x2007"
|
|
Packit |
cdaae3 |
The rules for mangling C++ names are not part of the
|
|
Packit |
cdaae3 |
C++ standard and are different for different versions
|
|
Packit |
cdaae3 |
of C++. With this extension, the compiler emits
|
|
Packit |
cdaae3 |
both the DW_AT_name for things with mangled names
|
|
Packit |
cdaae3 |
(recall that DW_AT_name is NOT the mangled form)
|
|
Packit |
cdaae3 |
and also emits DW_AT_MIPS_linkage_name whose value
|
|
Packit |
cdaae3 |
is the mangled name.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
This makes looking for the mangled name in other linker
|
|
Packit |
cdaae3 |
information straightforward.
|
|
Packit |
cdaae3 |
It also is passed (by the debugger) to the
|
|
Packit |
cdaae3 |
libmangle routines to generate names to present to the
|
|
Packit |
cdaae3 |
debugger user.
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_MIPS_stride 0x2008"
|
|
Packit |
cdaae3 |
F90 allows assumed shape arguments and pointers to describe
|
|
Packit |
cdaae3 |
non-contiguous memory. A (runtime) descriptor contains address,
|
|
Packit |
cdaae3 |
bounds and stride information - rank and element size is known
|
|
Packit |
cdaae3 |
during compilation. The extent in each dimension is given by the
|
|
Packit |
cdaae3 |
bounds in a DW_TAG_subrange_type, but the stride cannot be
|
|
Packit |
cdaae3 |
represented in conventional dwarf. DW_AT_MIPS_stride was added as
|
|
Packit |
cdaae3 |
an attribute of a DW_TAG_subrange_type to describe the
|
|
Packit |
cdaae3 |
location of the stride.
|
|
Packit |
cdaae3 |
Used in the MIPSpro 7.2 (7.2.1 etc) compilers.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
If the stride is constant (ie: can be inferred from the type in the
|
|
Packit |
cdaae3 |
usual manner) DW_AT_MIPS_stride is absent.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
If DW_AT_MIPS_stride is present, the attribute contains a reference
|
|
Packit |
cdaae3 |
to a DIE which describes the location holding the stride, and the
|
|
Packit |
cdaae3 |
DW_AT_stride_size field of DW_TAG_array_type is ignored if
|
|
Packit |
cdaae3 |
present. The value of the stride is the number of
|
|
Packit |
cdaae3 |
4 byte words between
|
|
Packit |
cdaae3 |
elements along that axis.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
This applies to
|
|
Packit |
cdaae3 |
.nf
|
|
Packit |
cdaae3 |
a) Intrinsic types whose size is greater
|
|
Packit |
cdaae3 |
or equal to 4bytes ie: real*4,integer*8
|
|
Packit |
cdaae3 |
complex etc, but not character types.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
b) Derived types (ie: structs) of any size,
|
|
Packit |
cdaae3 |
unless all components are of type character.
|
|
Packit |
cdaae3 |
.fi
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_MIPS_abstract_name 0x2009"
|
|
Packit |
cdaae3 |
This attribute only appears in a DA_TAG_inlined_subroutine DIE.
|
|
Packit |
cdaae3 |
The value of this attribute is a string.
|
|
Packit |
cdaae3 |
When IPA inlines a routine and the abstract origin is
|
|
Packit |
cdaae3 |
in another compilation unit, there is a problem with putting
|
|
Packit |
cdaae3 |
in a reference, since the ordering and timing of the
|
|
Packit |
cdaae3 |
creation of references is unpredicatable with reference to
|
|
Packit |
cdaae3 |
the DIE and compilation unit the reference refers to.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
Since there may be NO ordering of the compilation units that
|
|
Packit |
cdaae3 |
allows a correct reference to be done without some kind of patching,
|
|
Packit |
cdaae3 |
and since even getting the information from one place to another
|
|
Packit |
cdaae3 |
is a problem, the compiler simply passes the problem on to the debugger.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
The debugger must match the DW_AT_MIPS_abstract_name
|
|
Packit |
cdaae3 |
in the concrete
|
|
Packit |
cdaae3 |
inlined instance DIE
|
|
Packit |
cdaae3 |
with the DW_AT_MIPS_abstract_name
|
|
Packit |
cdaae3 |
in the abstract inlined subroutine DIE.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
A dwarf-consumer-centric view of this and other inline
|
|
Packit |
cdaae3 |
issues could be expressed as follows:
|
|
Packit |
cdaae3 |
.nf
|
|
Packit |
cdaae3 |
If DW_TAG_subprogram
|
|
Packit |
cdaae3 |
If has DW_AT_inline is abstract instance root
|
|
Packit |
cdaae3 |
If has DW_AT_abstract_origin, is out-of-line instance
|
|
Packit |
cdaae3 |
of function (need abstract origin for some data)
|
|
Packit |
cdaae3 |
(abstract root in same CU (conceptually anywhere
|
|
Packit |
cdaae3 |
a ref can reach, but reaching outside of CU is
|
|
Packit |
cdaae3 |
a problem for ipa: see DW_AT_MIPS_abstract_name))
|
|
Packit |
cdaae3 |
If has DW_AT_MIPS_abstract_name is abstract instance
|
|
Packit |
cdaae3 |
root( must have DW_AT_inline) and this name is used to
|
|
Packit |
cdaae3 |
match with the abstract root
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
If DW_TAG_inline_subroutine
|
|
Packit |
cdaae3 |
Is concrete inlined subprogram instance.
|
|
Packit |
cdaae3 |
If has DW_AT_abstract_origin, it is a CU-local inline.
|
|
Packit |
cdaae3 |
If it has DW_AT_MIPS_abstract_name it is an
|
|
Packit |
cdaae3 |
inline whose abstract root is in another file (CU).
|
|
Packit |
cdaae3 |
.fi
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_MIPS_clone_origin 0x200a"
|
|
Packit |
cdaae3 |
This attribute appears only in a cloned subroutine.
|
|
Packit |
cdaae3 |
The procedure is cloned from the same compilation unit.
|
|
Packit |
cdaae3 |
The value of this attribute is a reference to
|
|
Packit |
cdaae3 |
the original routine in this compilation unit.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
The 'original' routine means the routine which has all the
|
|
Packit |
cdaae3 |
original code. The cloned routines will always have
|
|
Packit |
cdaae3 |
been 'specialized' by IPA.
|
|
Packit |
cdaae3 |
A routine with DW_AT_MIPS_clone_origin
|
|
Packit |
cdaae3 |
will also have the DW_CC_nocall value of the DW_AT_calling_convention
|
|
Packit |
cdaae3 |
attribute.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_MIPS_has_inlines 0x200b"
|
|
Packit |
cdaae3 |
This attribute may appear in a DW_TAG_subprogram DIE.
|
|
Packit |
cdaae3 |
If present and it has the value True, then the subprogram
|
|
Packit |
cdaae3 |
has inlined functions somewhere in the body.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
By default, at startup, the debugger may not look for
|
|
Packit |
cdaae3 |
inlined functions in scopes inside the outer function.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
This is a hint to the debugger to look for the inlined functions
|
|
Packit |
cdaae3 |
so the debugger can set breakpoints on these in case the user
|
|
Packit |
cdaae3 |
requests 'stop in foo' and foo is inlined.
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_MIPS_stride_byte 0x200c"
|
|
Packit |
cdaae3 |
Created for f90 pointer and assumed shape
|
|
Packit |
cdaae3 |
arrays.
|
|
Packit |
cdaae3 |
Used in the MIPSpro 7.2 (7.2.1 etc) compilers.
|
|
Packit |
cdaae3 |
A variant of DW_AT_MIPS_stride.
|
|
Packit |
cdaae3 |
This stride is interpreted as a byte count.
|
|
Packit |
cdaae3 |
Used for integer*1 and character arrays
|
|
Packit |
cdaae3 |
and arrays of derived type
|
|
Packit |
cdaae3 |
whose components are all character.
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_MIPS_stride_elem 0x200d"
|
|
Packit |
cdaae3 |
Created for f90 pointer and assumed shape
|
|
Packit |
cdaae3 |
arrays.
|
|
Packit |
cdaae3 |
Used in the MIPSpro 7.2 (7.2.1 etc) compilers.
|
|
Packit |
cdaae3 |
A variant of DW_AT_MIPS_stride.
|
|
Packit |
cdaae3 |
This stride is interpreted as a byte-pair (2 byte) count.
|
|
Packit |
cdaae3 |
Used for integer*2 arrays.
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_MIPS_ptr_dopetype 0x200e"
|
|
Packit |
cdaae3 |
See following.
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_MIPS_allocatable_dopetype 0x200f"
|
|
Packit |
cdaae3 |
See following.
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_MIPS_assumed_shape_dopetype 0x2010"
|
|
Packit |
cdaae3 |
DW_AT_MIPS_assumed_shape_dopetype, DW_AT_MIPS_allocatable_dopetype,
|
|
Packit |
cdaae3 |
and DW_AT_MIPS_ptr_dopetype have an attribute value
|
|
Packit |
cdaae3 |
which is a reference to a Fortran 90 Dope Vector.
|
|
Packit |
cdaae3 |
These attributes are introduced in MIPSpro7.3.
|
|
Packit |
cdaae3 |
They only apply to f90 arrays (where they are
|
|
Packit |
cdaae3 |
needed to describe arrays never properly described
|
|
Packit |
cdaae3 |
before in debug information).
|
|
Packit |
cdaae3 |
C, C++, f77, and most f90 arrays continue to be described
|
|
Packit |
cdaae3 |
in standard dwarf.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
The distinction between these three attributes is the f90 syntax
|
|
Packit |
cdaae3 |
distinction: keywords 'pointer' and 'allocatable' with the absence
|
|
Packit |
cdaae3 |
of these keywords on an assumed shape array being the third case.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
A "Dope Vector" is a struct (C struct) which describes
|
|
Packit |
cdaae3 |
a dynamically-allocatable array.
|
|
Packit |
cdaae3 |
In objects with full debugging the C struct will be
|
|
Packit |
cdaae3 |
in the dwarf information (of the f90 object, represented like C).
|
|
Packit |
cdaae3 |
A debugger will use the link to find the main struct DopeVector
|
|
Packit |
cdaae3 |
and will use that information to decode the dope vector.
|
|
Packit |
cdaae3 |
At the outer allocatable/assumed-shape/pointer
|
|
Packit |
cdaae3 |
the DW_AT_location points at the dope vector (so debugger
|
|
Packit |
cdaae3 |
calculations use that as a base).
|
|
Packit |
cdaae3 |
.H 2 "Overview of debugger use of dope vectors"
|
|
Packit |
cdaae3 |
Fundamentally, we build two distinct
|
|
Packit |
cdaae3 |
representations of the arrays and pointers.
|
|
Packit |
cdaae3 |
One, in dwarf, represents the statically-representable
|
|
Packit |
cdaae3 |
information (the types and
|
|
Packit |
cdaae3 |
variable/type-names, without type size information).
|
|
Packit |
cdaae3 |
The other, using dope vectors in memory, represents
|
|
Packit |
cdaae3 |
the run-time data of sizes.
|
|
Packit |
cdaae3 |
A debugger must process the two representations
|
|
Packit |
cdaae3 |
in parallel (and merge them) to deal with user expressions in
|
|
Packit |
cdaae3 |
a debugger.
|
|
Packit |
cdaae3 |
.H 2 "Example f90 code for use in explanation"
|
|
Packit |
cdaae3 |
[Note
|
|
Packit |
cdaae3 |
We want dwarf output with *exactly*
|
|
Packit |
cdaae3 |
this little (arbitrary) example.
|
|
Packit |
cdaae3 |
Not yet available.
|
|
Packit |
cdaae3 |
end Note]
|
|
Packit |
cdaae3 |
Consider the following code.
|
|
Packit |
cdaae3 |
.nf
|
|
Packit |
cdaae3 |
type array_ptr
|
|
Packit |
cdaae3 |
real :: myvar
|
|
Packit |
cdaae3 |
real, dimension (:), pointer :: ap
|
|
Packit |
cdaae3 |
end type array_ptr
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
type (array_ptr), allocatable, dimension (:) :: arrays
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
allocate (arrays(20))
|
|
Packit |
cdaae3 |
do i = 1,20
|
|
Packit |
cdaae3 |
allocate (arrays(i)%ap(i))
|
|
Packit |
cdaae3 |
end do
|
|
Packit |
cdaae3 |
.fi
|
|
Packit |
cdaae3 |
arrays is an allocatable array (1 dimension) whose size is
|
|
Packit |
cdaae3 |
not known at compile time (it has
|
|
Packit |
cdaae3 |
a Dope Vector). At run time, the
|
|
Packit |
cdaae3 |
allocate statement creats 20 array_ptr dope vectors
|
|
Packit |
cdaae3 |
and marks the base arrays dopevector as allocated.
|
|
Packit |
cdaae3 |
The myvar variable is just there to add complexity to
|
|
Packit |
cdaae3 |
the example :-)
|
|
Packit |
cdaae3 |
.nf
|
|
Packit |
cdaae3 |
In the loop, arrays(1)%ap(1)
|
|
Packit |
cdaae3 |
is allocated as a single element array of reals.
|
|
Packit |
cdaae3 |
In the loop, arrays(2)%ap(2)
|
|
Packit |
cdaae3 |
is allocated as an array of two reals.
|
|
Packit |
cdaae3 |
...
|
|
Packit |
cdaae3 |
In the loop, arrays(20)%ap(20)
|
|
Packit |
cdaae3 |
is allocated as an array of twenty reals.
|
|
Packit |
cdaae3 |
.fi
|
|
Packit |
cdaae3 |
.H 2 "the problem with standard dwarf and this example"
|
|
Packit |
cdaae3 |
.sp
|
|
Packit |
cdaae3 |
In dwarf, there is no way to find the array bounds of arrays(3)%ap,
|
|
Packit |
cdaae3 |
for example, (which are 1:3 in f90 syntax)
|
|
Packit |
cdaae3 |
since any location expression in an ap array lower bound
|
|
Packit |
cdaae3 |
attribute cannot involve the 3 (the 3 is known at debug time and
|
|
Packit |
cdaae3 |
does not appear in the running binary, so no way for the
|
|
Packit |
cdaae3 |
location expression to get to it).
|
|
Packit |
cdaae3 |
And of course the 3 must actually index across the array of
|
|
Packit |
cdaae3 |
dope vectors in 'arrays' in our implementation, but that is less of
|
|
Packit |
cdaae3 |
a problem than the problem with the '3'.
|
|
Packit |
cdaae3 |
.sp
|
|
Packit |
cdaae3 |
Plus dwarf has no way to find the 'allocated' flag in the
|
|
Packit |
cdaae3 |
dope vector (so the debugger can know when the allocate is done
|
|
Packit |
cdaae3 |
for a particular arrays(j)%ap).
|
|
Packit |
cdaae3 |
.sp
|
|
Packit |
cdaae3 |
Consequently, the calculation of array bounds and indices
|
|
Packit |
cdaae3 |
for these dynamically created f90 arrays
|
|
Packit |
cdaae3 |
is now pushed of into the debugger, which must know the
|
|
Packit |
cdaae3 |
field names and usages of the dope vector C structure and
|
|
Packit |
cdaae3 |
use the field offsets etc to find data arrays.
|
|
Packit |
cdaae3 |
C, C++, f77, and most f90 arrays continue to be described
|
|
Packit |
cdaae3 |
in standard dwarf.
|
|
Packit |
cdaae3 |
At the outer allocatable/assumed-shape/pointer
|
|
Packit |
cdaae3 |
the DW_AT_location points at the dope vector (so debugger
|
|
Packit |
cdaae3 |
calculations use that as a base).
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
It would have been nice to design a dwarf extension
|
|
Packit |
cdaae3 |
to handle the above problems, but
|
|
Packit |
cdaae3 |
the methods considered to date were not
|
|
Packit |
cdaae3 |
any more consistent with standard dwarf than
|
|
Packit |
cdaae3 |
this dope vector centric approach: essentially just
|
|
Packit |
cdaae3 |
as much work in the debugger appeared necessary either way.
|
|
Packit |
cdaae3 |
A better (more dwarf-ish)
|
|
Packit |
cdaae3 |
design would be welcome information.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "A simplified sketch of the dwarf information"
|
|
Packit |
cdaae3 |
[Note:
|
|
Packit |
cdaae3 |
Needs to be written.
|
|
Packit |
cdaae3 |
end Note]
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "A simplified sketch of the dope vector information"
|
|
Packit |
cdaae3 |
[Note:
|
|
Packit |
cdaae3 |
This one is simplified.
|
|
Packit |
cdaae3 |
Details left out that should be here. Amplify.
|
|
Packit |
cdaae3 |
end Note]
|
|
Packit |
cdaae3 |
This is an overly simplified version of a dope vector,
|
|
Packit |
cdaae3 |
presented as an initial hint.
|
|
Packit |
cdaae3 |
Full details presented later.
|
|
Packit |
cdaae3 |
.nf
|
|
Packit |
cdaae3 |
struct simplified{
|
|
Packit |
cdaae3 |
void *base; // pointer to the data this describes
|
|
Packit |
cdaae3 |
long el_len;
|
|
Packit |
cdaae3 |
int assoc:1
|
|
Packit |
cdaae3 |
int ptr_alloc:1
|
|
Packit |
cdaae3 |
int num_dims:3;
|
|
Packit |
cdaae3 |
struct dims_s {
|
|
Packit |
cdaae3 |
long lb;
|
|
Packit |
cdaae3 |
long ext;
|
|
Packit |
cdaae3 |
long str_m;
|
|
Packit |
cdaae3 |
} dims[7];
|
|
Packit |
cdaae3 |
};
|
|
Packit |
cdaae3 |
.fi
|
|
Packit |
cdaae3 |
Only 'num_dims' elements of dims[] are actually used.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "The dwarf information"
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
Here is dwarf information from the compiler for
|
|
Packit |
cdaae3 |
the example above, as printed by dwarfdump(1)
|
|
Packit |
cdaae3 |
.nf
|
|
Packit |
cdaae3 |
[Note:
|
|
Packit |
cdaae3 |
The following may not be the test.
|
|
Packit |
cdaae3 |
Having field names with '.' in the name is
|
|
Packit |
cdaae3 |
not such a good idea, as it conflicts with the
|
|
Packit |
cdaae3 |
use of '.' in dbx extended naming.
|
|
Packit |
cdaae3 |
Something else, like _$, would be much easier
|
|
Packit |
cdaae3 |
to work with in dbx (customers won't care about this,
|
|
Packit |
cdaae3 |
for the most part,
|
|
Packit |
cdaae3 |
but folks working on dbx will, and in those
|
|
Packit |
cdaae3 |
rare circumstances when a customer cares,
|
|
Packit |
cdaae3 |
the '.' will be a real problem in dbx.).
|
|
Packit |
cdaae3 |
Note that to print something about .base., in dbx one
|
|
Packit |
cdaae3 |
would have to do
|
|
Packit |
cdaae3 |
whatis `.base.`
|
|
Packit |
cdaae3 |
where that is the grave accent, or back-quote I am using.
|
|
Packit |
cdaae3 |
With extended naming one do
|
|
Packit |
cdaae3 |
whatis `.dope.`.`.base.`
|
|
Packit |
cdaae3 |
which is hard to type and hard to read.
|
|
Packit |
cdaae3 |
end Note]
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
<2>< 388> DW_TAG_array_type
|
|
Packit |
cdaae3 |
DW_AT_name .base.
|
|
Packit |
cdaae3 |
DW_AT_type <815>
|
|
Packit |
cdaae3 |
DW_AT_declaration yes(1)
|
|
Packit |
cdaae3 |
<3>< 401> DW_TAG_subrange_type
|
|
Packit |
cdaae3 |
DW_AT_lower_bound 0
|
|
Packit |
cdaae3 |
DW_AT_upper_bound 0
|
|
Packit |
cdaae3 |
<2>< 405> DW_TAG_pointer_type
|
|
Packit |
cdaae3 |
DW_AT_type <388>
|
|
Packit |
cdaae3 |
DW_AT_byte_size 4
|
|
Packit |
cdaae3 |
DW_AT_address_class 0
|
|
Packit |
cdaae3 |
<2>< 412> DW_TAG_structure_type
|
|
Packit |
cdaae3 |
DW_AT_name .flds.
|
|
Packit |
cdaae3 |
DW_AT_byte_size 28
|
|
Packit |
cdaae3 |
<3>< 421> DW_TAG_member
|
|
Packit |
cdaae3 |
DW_AT_name el_len
|
|
Packit |
cdaae3 |
DW_AT_type <815>
|
|
Packit |
cdaae3 |
DW_AT_data_member_location DW_OP_consts 0
|
|
Packit |
cdaae3 |
<3>< 436> DW_TAG_member
|
|
Packit |
cdaae3 |
DW_AT_name assoc
|
|
Packit |
cdaae3 |
DW_AT_type <841>
|
|
Packit |
cdaae3 |
DW_AT_byte_size 0
|
|
Packit |
cdaae3 |
DW_AT_bit_offset 0
|
|
Packit |
cdaae3 |
DW_AT_bit_size 1
|
|
Packit |
cdaae3 |
DW_AT_data_member_location DW_OP_consts 4
|
|
Packit |
cdaae3 |
<3>< 453> DW_TAG_member
|
|
Packit |
cdaae3 |
DW_AT_name ptr_alloc
|
|
Packit |
cdaae3 |
DW_AT_type <841>
|
|
Packit |
cdaae3 |
DW_AT_byte_size 0
|
|
Packit |
cdaae3 |
DW_AT_bit_offset 1
|
|
Packit |
cdaae3 |
DW_AT_bit_size 1
|
|
Packit |
cdaae3 |
DW_AT_data_member_location DW_OP_consts 4
|
|
Packit |
cdaae3 |
<3>< 474> DW_TAG_member
|
|
Packit |
cdaae3 |
DW_AT_name p_or_a
|
|
Packit |
cdaae3 |
DW_AT_type <841>
|
|
Packit |
cdaae3 |
DW_AT_byte_size 0
|
|
Packit |
cdaae3 |
DW_AT_bit_offset 2
|
|
Packit |
cdaae3 |
DW_AT_bit_size 2
|
|
Packit |
cdaae3 |
DW_AT_data_member_location DW_OP_consts 4
|
|
Packit |
cdaae3 |
<3>< 492> DW_TAG_member
|
|
Packit |
cdaae3 |
DW_AT_name a_contig
|
|
Packit |
cdaae3 |
DW_AT_type <841>
|
|
Packit |
cdaae3 |
DW_AT_byte_size 0
|
|
Packit |
cdaae3 |
DW_AT_bit_offset 4
|
|
Packit |
cdaae3 |
DW_AT_bit_size 1
|
|
Packit |
cdaae3 |
DW_AT_data_member_location DW_OP_consts 4
|
|
Packit |
cdaae3 |
<3>< 532> DW_TAG_member
|
|
Packit |
cdaae3 |
DW_AT_name num_dims
|
|
Packit |
cdaae3 |
DW_AT_type <841>
|
|
Packit |
cdaae3 |
DW_AT_byte_size 0
|
|
Packit |
cdaae3 |
DW_AT_bit_offset 29
|
|
Packit |
cdaae3 |
DW_AT_bit_size 3
|
|
Packit |
cdaae3 |
DW_AT_data_member_location DW_OP_consts 8
|
|
Packit |
cdaae3 |
<3>< 572> DW_TAG_member
|
|
Packit |
cdaae3 |
DW_AT_name type_code
|
|
Packit |
cdaae3 |
DW_AT_type <841>
|
|
Packit |
cdaae3 |
DW_AT_byte_size 0
|
|
Packit |
cdaae3 |
DW_AT_bit_offset 0
|
|
Packit |
cdaae3 |
DW_AT_bit_size 32
|
|
Packit |
cdaae3 |
DW_AT_data_member_location DW_OP_consts 16
|
|
Packit |
cdaae3 |
<3>< 593> DW_TAG_member
|
|
Packit |
cdaae3 |
DW_AT_name orig_base
|
|
Packit |
cdaae3 |
DW_AT_type <841>
|
|
Packit |
cdaae3 |
DW_AT_data_member_location DW_OP_consts 20
|
|
Packit |
cdaae3 |
<3>< 611> DW_TAG_member
|
|
Packit |
cdaae3 |
DW_AT_name orig_size
|
|
Packit |
cdaae3 |
DW_AT_type <815>
|
|
Packit |
cdaae3 |
DW_AT_data_member_location DW_OP_consts 24
|
|
Packit |
cdaae3 |
<2>< 630> DW_TAG_structure_type
|
|
Packit |
cdaae3 |
DW_AT_name .dope_bnd.
|
|
Packit |
cdaae3 |
DW_AT_byte_size 12
|
|
Packit |
cdaae3 |
<3>< 643> DW_TAG_member
|
|
Packit |
cdaae3 |
DW_AT_name lb
|
|
Packit |
cdaae3 |
DW_AT_type <815>
|
|
Packit |
cdaae3 |
DW_AT_data_member_location DW_OP_consts 0
|
|
Packit |
cdaae3 |
<3>< 654> DW_TAG_member
|
|
Packit |
cdaae3 |
DW_AT_name ext
|
|
Packit |
cdaae3 |
DW_AT_type <815>
|
|
Packit |
cdaae3 |
DW_AT_data_member_location DW_OP_consts 4
|
|
Packit |
cdaae3 |
<3>< 666> DW_TAG_member
|
|
Packit |
cdaae3 |
DW_AT_name str_m
|
|
Packit |
cdaae3 |
DW_AT_type <815>
|
|
Packit |
cdaae3 |
DW_AT_data_member_location DW_OP_consts 8
|
|
Packit |
cdaae3 |
<2>< 681> DW_TAG_array_type
|
|
Packit |
cdaae3 |
DW_AT_name .dims.
|
|
Packit |
cdaae3 |
DW_AT_type <630>
|
|
Packit |
cdaae3 |
DW_AT_declaration yes(1)
|
|
Packit |
cdaae3 |
<3>< 694> DW_TAG_subrange_type
|
|
Packit |
cdaae3 |
DW_AT_lower_bound 0
|
|
Packit |
cdaae3 |
DW_AT_upper_bound 0
|
|
Packit |
cdaae3 |
<2>< 698> DW_TAG_structure_type
|
|
Packit |
cdaae3 |
DW_AT_name .dope.
|
|
Packit |
cdaae3 |
DW_AT_byte_size 44
|
|
Packit |
cdaae3 |
<3>< 707> DW_TAG_member
|
|
Packit |
cdaae3 |
DW_AT_name base
|
|
Packit |
cdaae3 |
DW_AT_type <405>
|
|
Packit |
cdaae3 |
DW_AT_data_member_location DW_OP_consts 0
|
|
Packit |
cdaae3 |
<3>< 720> DW_TAG_member
|
|
Packit |
cdaae3 |
DW_AT_name .flds
|
|
Packit |
cdaae3 |
DW_AT_type <412>
|
|
Packit |
cdaae3 |
DW_AT_data_member_location DW_OP_consts 4
|
|
Packit |
cdaae3 |
<3>< 734> DW_TAG_member
|
|
Packit |
cdaae3 |
DW_AT_name .dims.
|
|
Packit |
cdaae3 |
DW_AT_type <681>
|
|
Packit |
cdaae3 |
DW_AT_data_member_location DW_OP_consts 32
|
|
Packit |
cdaae3 |
<2>< 750> DW_TAG_variable
|
|
Packit |
cdaae3 |
DW_AT_type <815>
|
|
Packit |
cdaae3 |
DW_AT_location DW_OP_fbreg -32
|
|
Packit |
cdaae3 |
DW_AT_artificial yes(1)
|
|
Packit |
cdaae3 |
<2>< 759> DW_TAG_variable
|
|
Packit |
cdaae3 |
DW_AT_type <815>
|
|
Packit |
cdaae3 |
DW_AT_location DW_OP_fbreg -28
|
|
Packit |
cdaae3 |
DW_AT_artificial yes(1)
|
|
Packit |
cdaae3 |
<2>< 768> DW_TAG_variable
|
|
Packit |
cdaae3 |
DW_AT_type <815>
|
|
Packit |
cdaae3 |
DW_AT_location DW_OP_fbreg -24
|
|
Packit |
cdaae3 |
DW_AT_artificial yes(1)
|
|
Packit |
cdaae3 |
<2>< 777> DW_TAG_array_type
|
|
Packit |
cdaae3 |
DW_AT_type <815>
|
|
Packit |
cdaae3 |
DW_AT_declaration yes(1)
|
|
Packit |
cdaae3 |
<3>< 783> DW_TAG_subrange_type
|
|
Packit |
cdaae3 |
DW_AT_lower_bound <750>
|
|
Packit |
cdaae3 |
DW_AT_count <759>
|
|
Packit |
cdaae3 |
DW_AT_MIPS_stride <768>
|
|
Packit |
cdaae3 |
<2>< 797> DW_TAG_variable
|
|
Packit |
cdaae3 |
DW_AT_decl_file 1
|
|
Packit |
cdaae3 |
DW_AT_decl_line 1
|
|
Packit |
cdaae3 |
DW_AT_name ARRAY
|
|
Packit |
cdaae3 |
DW_AT_type <698>
|
|
Packit |
cdaae3 |
DW_AT_location DW_OP_fbreg -64 DW_OP_deref
|
|
Packit |
cdaae3 |
<1>< 815> DW_TAG_base_type
|
|
Packit |
cdaae3 |
DW_AT_name INTEGER_4
|
|
Packit |
cdaae3 |
DW_AT_encoding DW_ATE_signed
|
|
Packit |
cdaae3 |
DW_AT_byte_size 4
|
|
Packit |
cdaae3 |
<1>< 828> DW_TAG_base_type
|
|
Packit |
cdaae3 |
DW_AT_name INTEGER_8
|
|
Packit |
cdaae3 |
DW_AT_encoding DW_ATE_signed
|
|
Packit |
cdaae3 |
DW_AT_byte_size 8
|
|
Packit |
cdaae3 |
<1>< 841> DW_TAG_base_type
|
|
Packit |
cdaae3 |
DW_AT_name INTEGER*4
|
|
Packit |
cdaae3 |
DW_AT_encoding DW_ATE_unsigned
|
|
Packit |
cdaae3 |
DW_AT_byte_size 4
|
|
Packit |
cdaae3 |
<1>< 854> DW_TAG_base_type
|
|
Packit |
cdaae3 |
DW_AT_name INTEGER*8
|
|
Packit |
cdaae3 |
DW_AT_encoding DW_ATE_unsigned
|
|
Packit |
cdaae3 |
DW_AT_byte_size 8
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.fi
|
|
Packit |
cdaae3 |
.H 2 "The dope vector structure details"
|
|
Packit |
cdaae3 |
A dope vector is the following C struct, "dopevec.h".
|
|
Packit |
cdaae3 |
Not all the fields are of use to a debugger.
|
|
Packit |
cdaae3 |
It may be that not all fields will show up
|
|
Packit |
cdaae3 |
in the f90 dwarf (since not all are of interest to debuggers).
|
|
Packit |
cdaae3 |
.nf
|
|
Packit |
cdaae3 |
[Note:
|
|
Packit |
cdaae3 |
Need details on the use of each field.
|
|
Packit |
cdaae3 |
And need to know which are really 32 bits and which
|
|
Packit |
cdaae3 |
are 32 or 64.
|
|
Packit |
cdaae3 |
end Note]
|
|
Packit |
cdaae3 |
The following
|
|
Packit |
cdaae3 |
struct
|
|
Packit |
cdaae3 |
is a representation of all the dope vector fields.
|
|
Packit |
cdaae3 |
It suppresses irrelevant detail and may not
|
|
Packit |
cdaae3 |
exactly match the layout in memory (a debugger must
|
|
Packit |
cdaae3 |
examine the dwarf to find the fields, not
|
|
Packit |
cdaae3 |
compile this structure into the debugger!).
|
|
Packit |
cdaae3 |
.nf
|
|
Packit |
cdaae3 |
struct .dope. {
|
|
Packit |
cdaae3 |
void *base; // pointer to data
|
|
Packit |
cdaae3 |
struct .flds. {
|
|
Packit |
cdaae3 |
long el_len; // length of element in bytes?
|
|
Packit |
cdaae3 |
unsigned int assoc:1; //means?
|
|
Packit |
cdaae3 |
unsigned int ptr_alloc:1; //means?
|
|
Packit |
cdaae3 |
unsigned int p_or_a:2; //means?
|
|
Packit |
cdaae3 |
unsigned int a_contig:1; // means?
|
|
Packit |
cdaae3 |
unsigned int num_dims: 3; // 0 thru 7
|
|
Packit |
cdaae3 |
unsigned int type_code:32; //values?
|
|
Packit |
cdaae3 |
unsigned int orig_base; //void *? means?
|
|
Packit |
cdaae3 |
long orig_size; // means?
|
|
Packit |
cdaae3 |
} .flds;
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
struct .dope_bnd. {
|
|
Packit |
cdaae3 |
long lb ; // lower bound
|
|
Packit |
cdaae3 |
long ext ; // means?
|
|
Packit |
cdaae3 |
long str_m; // means?
|
|
Packit |
cdaae3 |
} .dims[7];
|
|
Packit |
cdaae3 |
}
|
|
Packit |
cdaae3 |
.fi
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "DW_AT_MIPS_assumed_size 0x2011"
|
|
Packit |
cdaae3 |
This flag was invented to deal with f90 arrays.
|
|
Packit |
cdaae3 |
For example:
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.nf
|
|
Packit |
cdaae3 |
pointer (rptr, axx(1))
|
|
Packit |
cdaae3 |
pointer (iptr, ita(*))
|
|
Packit |
cdaae3 |
rptr = malloc (100*8)
|
|
Packit |
cdaae3 |
iptr = malloc (100*4)
|
|
Packit |
cdaae3 |
.fi
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
This flag attribute has the value 'yes' (true, on) if and only if
|
|
Packit |
cdaae3 |
the size is unbounded, as iptr is.
|
|
Packit |
cdaae3 |
Both may show an explicit upper bound of 1 in the dwarf,
|
|
Packit |
cdaae3 |
but this flag notifies the debugger that there is explicitly
|
|
Packit |
cdaae3 |
no user-provided size.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
So if a user asks for a printout of the rptr allocated
|
|
Packit |
cdaae3 |
array, the default will be of a single entry (as
|
|
Packit |
cdaae3 |
there is a user slice bound in the source).
|
|
Packit |
cdaae3 |
In contrast, there is no explicit upper bound on the iptr
|
|
Packit |
cdaae3 |
(ita) array so the default slice will use the current bound
|
|
Packit |
cdaae3 |
(a value calculated from the malloc size, see the dope vector).
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
Given explicit requests, more of rptr(axx) can me shown
|
|
Packit |
cdaae3 |
than the default.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 1 "Line information and Source Position"
|
|
Packit |
cdaae3 |
DWARF does not define the meaning of the term 'source statement'.
|
|
Packit |
cdaae3 |
Nor does it define any way to find the first user-written
|
|
Packit |
cdaae3 |
executable code in a function.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
It does define that a source statement has a file name,
|
|
Packit |
cdaae3 |
a line number, and a column position (see Sec 6.2, Line Number
|
|
Packit |
cdaae3 |
Information of the Dwarf Version 2 document).
|
|
Packit |
cdaae3 |
We will call those 3 source coordinates a 'source position'
|
|
Packit |
cdaae3 |
in this document. We'll try not to accidentally call the
|
|
Packit |
cdaae3 |
source position a 'line number' since that is ambiguous
|
|
Packit |
cdaae3 |
as to what it means.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "Definition of Statement"
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
A function prolog is a statement.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
A C, C++, Pascal, or Fortran statement is a statement.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
Each initialized local variable in C,C++ is a statement
|
|
Packit |
cdaae3 |
in that its initialization generates a source position.
|
|
Packit |
cdaae3 |
This means that
|
|
Packit |
cdaae3 |
x =3, y=4;
|
|
Packit |
cdaae3 |
is two statements.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
For C, C++:
|
|
Packit |
cdaae3 |
The 3 parts a,b,c in for(a;b;c) {d;} are individual statements.
|
|
Packit |
cdaae3 |
The condition portion of a while() and do {} while() is
|
|
Packit |
cdaae3 |
a statement. (of course d; can be any number of statements)
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
For Fortran, the controlling expression of a DO loop is a statement.
|
|
Packit |
cdaae3 |
Is a 'continue' statement in Fortran a DWARF statement?
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
Each function return, whether user coded or generated by the
|
|
Packit |
cdaae3 |
compiler, is a statement. This is so one can step over (in
|
|
Packit |
cdaae3 |
a debugger) the final user-coded statement
|
|
Packit |
cdaae3 |
(exclusive of the return statement if any) in a function
|
|
Packit |
cdaae3 |
wile not leaving the function scope.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "Finding The First User Code in a Function"
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.nf
|
|
Packit |
cdaae3 |
Consider:
|
|
Packit |
cdaae3 |
int func(int a)
|
|
Packit |
cdaae3 |
{ /* source position 1 */
|
|
Packit |
cdaae3 |
float b = a; /* source position 2 */
|
|
Packit |
cdaae3 |
int x;
|
|
Packit |
cdaae3 |
x = b + 2; /* source position 3 */
|
|
Packit |
cdaae3 |
} /* source position 4 */
|
|
Packit |
cdaae3 |
.fi
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
The DIE for a function gives the address range of the function,
|
|
Packit |
cdaae3 |
including function prolog(s) and epilog(s)
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
Since there is no scope block for the outer user scope of a
|
|
Packit |
cdaae3 |
function (and thus no beginning address range for the outer
|
|
Packit |
cdaae3 |
user scope: the DWARF committee explicitly rejected the idea
|
|
Packit |
cdaae3 |
of having a user scope block)
|
|
Packit |
cdaae3 |
it is necessary to use the source position information to find
|
|
Packit |
cdaae3 |
the first user-executable statement.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
This means that the user code for a function must be presumed
|
|
Packit |
cdaae3 |
to begin at the code location of the second source position in
|
|
Packit |
cdaae3 |
the function address range.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
If a function has exactly one source position, the function
|
|
Packit |
cdaae3 |
presumably consists solely of a return.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
If a function has exactly two source positions, the function
|
|
Packit |
cdaae3 |
may consist of a function prolog and a return or a single user
|
|
Packit |
cdaae3 |
statement and a return (there may be no prolog code needed in a
|
|
Packit |
cdaae3 |
leaf function). In this case, there is no way to be sure which
|
|
Packit |
cdaae3 |
is the first source position of user code, so the rule is to
|
|
Packit |
cdaae3 |
presume that the first address is user code.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
If a function consists of 3 or more source positions, one
|
|
Packit |
cdaae3 |
should assume that the first source position is function prolog and
|
|
Packit |
cdaae3 |
the second is the first user executable code.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "Using debug_frame Information to find first user statement"
|
|
Packit |
cdaae3 |
In addition to the line information, the debug_frame information
|
|
Packit |
cdaae3 |
can be
|
|
Packit |
cdaae3 |
useful in determining the first user source line.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
Given that a function has more than 1 source position,
|
|
Packit |
cdaae3 |
Find the code location of the second source position, then
|
|
Packit |
cdaae3 |
examine the debug_frame information to determine if the Canonical
|
|
Packit |
cdaae3 |
Frame Address (cfa) is updated before the second source position
|
|
Packit |
cdaae3 |
code location.
|
|
Packit |
cdaae3 |
If the cfa is updated, then one can be pretty sure that the
|
|
Packit |
cdaae3 |
code for the first source position is function prolog code.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
Similarly, if the cfa is restored in the code for
|
|
Packit |
cdaae3 |
a source position, the source position is likely to
|
|
Packit |
cdaae3 |
represent a function exit block.
|
|
Packit |
cdaae3 |
|
|
Packit |
cdaae3 |
.H 2 "Debugger Use Of Source Position"
|
|
Packit |
cdaae3 |
Command line debuggers, such as dbx and gdb, will ordinarily
|
|
Packit |
cdaae3 |
want to consider multiple statements on one line to be a single
|
|
Packit |
cdaae3 |
statement: doing otherwise is distressing to users since it
|
|
Packit |
cdaae3 |
causes a 'step' command to appear to have no effect.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
An exception for command line debuggers is in determining the
|
|
Packit |
cdaae3 |
first user statement: as detailed above, there one wants to
|
|
Packit |
cdaae3 |
consider the full source position and will want to consider
|
|
Packit |
cdaae3 |
the function return a separate statement. It is difficult to
|
|
Packit |
cdaae3 |
make the function return a separate statement 'step' reliably
|
|
Packit |
cdaae3 |
however if a function is coded all on one line or if the last
|
|
Packit |
cdaae3 |
line of user code before the return is on the same line as the
|
|
Packit |
cdaae3 |
return.
|
|
Packit |
cdaae3 |
.P
|
|
Packit |
cdaae3 |
A graphical debugger has none of these problems if it simply
|
|
Packit |
cdaae3 |
highlights the portion of the line being executed. In that
|
|
Packit |
cdaae3 |
case, stepping will appear natural even stepping within a
|
|
Packit |
cdaae3 |
line.
|
|
Packit |
cdaae3 |
.H 1 "Known Bugs"
|
|
Packit |
cdaae3 |
Up through at least MIPSpro7.2.1
|
|
Packit |
cdaae3 |
the compiler has been emitting form DW_FORM_DATA1,2, or 4
|
|
Packit |
cdaae3 |
for DW_AT_const_value in DW_TAG_enumerator.
|
|
Packit |
cdaae3 |
And dwarfdump and debuggers have read this with dwarf_formudata()
|
|
Packit |
cdaae3 |
or form_sdata() and gotten some values incorrect.
|
|
Packit |
cdaae3 |
For example, a value of 128 was printed by debuggers as a negative value.
|
|
Packit |
cdaae3 |
Since dwarfdump and the compilers were not written to use the
|
|
Packit |
cdaae3 |
value the same way, their output differed.
|
|
Packit |
cdaae3 |
For negative enumerator values the compiler has been emitting 32bit values
|
|
Packit |
cdaae3 |
in a DW_FORM_DATA4.
|
|
Packit |
cdaae3 |
The compiler should probably be emitting a DW_FORM_sdata for
|
|
Packit |
cdaae3 |
enumerator values.
|
|
Packit |
cdaae3 |
And consumers of enumerator values should then call form_sdata().
|
|
Packit |
cdaae3 |
However, right now, debuggers should call form_udata() and only if
|
|
Packit |
cdaae3 |
it fails, call form_sdata().
|
|
Packit |
cdaae3 |
Anything else will break backward compatibility with
|
|
Packit |
cdaae3 |
the objects produced earlier.
|
|
Packit |
cdaae3 |
.SK
|
|
Packit |
cdaae3 |
.S
|
|
Packit |
cdaae3 |
.TC 1 1 4
|
|
Packit |
cdaae3 |
.CS
|