00001 \." $Revision: 1.1.1.1 $
00002 \." $Date: 2005/10/21 19:00:00 $
00003 \."
00004 \."
00005 \." the following line may be removed if the ff ligature works on your machine
00006 .lg 0
00007 \." set up heading formats
00008 .ds HF 3 3 3 3 3 2 2
00009 .ds HP +2 +2 +1 +0 +0
00010 \." ==============================================
00011 \." Put current date in the following at each rev
00012 .ds vE rev 1.17, 29 Aug 2001
00013 \." ==============================================
00014 \." ==============================================
00015 .nr Hs 5
00016 .nr Hb 5
00017 .ds | |
00018 .ds ~ ~
00019 .ds ' '
00020 .if t .ds Cw \&\f(CW
00021 .if n .ds Cw \fB
00022 .de Cf \" Place every other arg in Cw font, beginning with first
00023 .if \\n(.$=1 \&\*(Cw\\$1\fP
00024 .if \\n(.$=2 \&\*(Cw\\$1\fP\\$2
00025 .if \\n(.$=3 \&\*(Cw\\$1\fP\\$2\*(Cw\\$3\fP
00026 .if \\n(.$=4 \&\*(Cw\\$1\fP\\$2\*(Cw\\$3\fP\\$4
00027 .if \\n(.$=5 \&\*(Cw\\$1\fP\\$2\*(Cw\\$3\fP\\$4\*(Cw\\$5\fP
00028 .if \\n(.$=6 \&\*(Cw\\$1\fP\\$2\*(Cw\\$3\fP\\$4\*(Cw\\$5\fP\\$6
00029 .if \\n(.$=7 \&\*(Cw\\$1\fP\\$2\*(Cw\\$3\fP\\$4\*(Cw\\$5\fP\\$6\*(Cw\\$7\fP
00030 .if \\n(.$=8 \&\*(Cw\\$1\fP\\$2\*(Cw\\$3\fP\\$4\*(Cw\\$5\fP\\$6\*(Cw\\$7\fP\\$8
00031 .if \\n(.$=9 \&\*(Cw\\$1\fP\\$2\*(Cw\\$3\fP\\$4\*(Cw\\$5\fP\\$6\*(Cw\\$7\fP\\$8\
00032 *(Cw
00033 ..
00034 .SA 1
00035 .TL
00036 MIPS Extensions to DWARF Version 2.0
00037 .AF ""
00038 .AU "Silicon Graphics Computer Systems
00039 .PF "'\*(vE '- \\\\nP -''"
00040 .PM ""
00041 .AS 1
00042 This document describes the MIPS/Silicon Graphics extensions to the "DWARF
00043 Information Format" (version 2.0.0 dated July 27, 1993).
00044 .P
00045 Rather than alter the base documents to describe the extensions
00046 we provide this separate document.
00047 .P
00048 The extensions documented here are subject to change.
00049 .P
00050 It also describes known bugs resulting in incorrect dwarf usage.
00051 .P
00052 \*(vE
00053 .AE
00054 .MT 4
00055 .H 1 "INTRODUCTION"
00056 This document describes MIPS extensions to the DWARF
00057 debugging information format.
00058 The extensions documented here are subject to change at
00059 any time.
00060 .H 1 "How much symbol information is emitted"
00061 The following standard DWARF V2 sections may be emitted:
00062 .AL
00063 .LI
00064 .debug_abbrev
00065 contains
00066 abbreviations supporting the .debug_info section.
00067 .LI
00068 .debug_info
00069 contains
00070 Debug Information Entries (DIEs).
00071 .LI
00072 .debug_frame
00073 contains
00074 stack frame descriptions.
00075 .LI
00076 .debug_line
00077 contains
00078 line number information.
00079 .LI
00080 .debug_aranges
00081 contains
00082 address range descriptions.
00083 .LI
00084 .debug_pubnames
00085 contains
00086 names of global functions and data.
00087 .P
00088 The following
00089 are MIPS extensions.
00090 Theses were created to allow debuggers to
00091 know names without having to look at
00092 the .debug_info section.
00093 .LI
00094 .debug_weaknames
00095 is a MIPS extension
00096 containing .debug_pubnames-like entries describing weak
00097 symbols.
00098 .LI
00099 .debug_funcnames
00100 is a MIPS extension
00101 containing .debug_pubnames-like entries describing file-static
00102 functions (C static functions).
00103 .LI
00104 .debug_varnames
00105 is a MIPS extension
00106 containing .debug_pubnames-like entries describing file-static
00107 data symbols (C static variables).
00108 .LI
00109 .debug_typenames
00110 is a MIPS extension
00111 containing .debug_pubnames-like entries describing file-level
00112 types.
00113 .P
00114 The following are not currently emitted.
00115 .LI
00116 .debug_macinfo
00117 Macro information is not currently emitted.
00118 .LI
00119 .debug_loc
00120 Location lists are not currently emitted.
00121 .LI
00122 .debug_str
00123 The string section is not currently emitted.
00124 .LE
00125 .H 2 "Overview of information emitted"
00126 We emit debug information in 3 flavors.
00127 We mention C here.
00128 The situation is essentially identical for f77, f90, and C++.
00129 .AL
00130 .LI
00131 "default C"
00132 We emit line information and DIEs for each subprogram.
00133 But no local symbols and no type information.
00134 Frame information is output.
00135 The DW_AT_producer string has the optimization level: for example
00136 "-O2".
00137 We put so much in the DW_AT_producer that the string
00138 is a significant user of space in .debug_info --
00139 this is perhaps a poor use of space.
00140 Debuggers only currently use the lack of -g
00141 of DW_AT_producer
00142 as a hint as to how a 'step' command should be interpreted, and
00143 the rest of the string is not used for anything (unless
00144 a human looks at it for some reason).
00145 .LI
00146 "C with full symbols"
00147 All possible info is emitted.
00148 DW_AT_producer string has all options that might be of interest,
00149 which includes -D's, -U's, and the -g option.
00150 These options look like they came from the command line.
00151 We put so much in the DW_AT_producer that the string
00152 is a significant user of space in .debug_info.
00153 this is perhaps a poor use of space.
00154 Debuggers only currently use the -g
00155 of DW_AT_producer
00156 as a hint as to how a 'step' command should be interpreted, and
00157 the rest of the string is not used for anything (unless
00158 a human looks at it for some reason).
00159 .LI
00160 "Assembler (-g, non -g are the same)"
00161 Frame information is output.
00162 No type information is emitted, but DIEs are prepared
00163 for globals.
00164 .LE
00165 .H 2 "Detecting 'full symbols' (-g)"
00166 The debugger depends on the existence of
00167 the DW_AT_producer string to determine if the
00168 compilation unit has full symbols or not.
00169 It looks for -g or -g[123] and accepts these as
00170 full symbols but an absent -g or a present -g0
00171 is taken to mean that only basic symbols are defined and there
00172 are no local symbols and no type information.
00173 .P
00174 In various contexts the debugger will think the program is
00175 stripped or 'was not compiled with -g' unless the -g
00176 is in the DW_AT_producer string.
00177 .H 2 "DWARF and strip(1)"
00178 The DWARF section ".debug_frame" is marked SHF_MIPS_NOSTRIP
00179 and is not stripped by the strip(1) program.
00180 This is because the section is needed for doing
00181 stack back traces (essential for C++
00182 and Ada exception handling).
00183 .P
00184 All .debug_* sections are marked with elf type
00185 SHT_MIPS_DWARF.
00186 Applications needing to access the various DWARF sections
00187 must use the section name to discriminate between them.
00188
00189 .H 2 "Evaluating location expressions"
00190 When the debugger evaluates location expressions, it does so
00191 in 2 stages. In stage one it simply looks for the trivial
00192 location expressions and treats those as special cases.
00193 .P
00194 If the location expression is not trivial, it enters stage two.
00195 In this case it uses a stack to evaluate the expression.
00196 .P
00197 If the application is a 32-bit application, it does the operations
00198 on 32-bit values (address size values). Even though registers
00199 can be 64 bits in a 32-bit program all evaluations are done in
00200 32-bit quantities, so an attempt to calculate a 32-bit quantity
00201 by taking the difference of 2 64-bit register values will not
00202 work. The notion is that the stack machine is, by the dwarf
00203 definition, working in address size units.
00204 .P
00205 These values are then expanded to 64-bit values (addresses or
00206 offsets). This extension does not involve sign-extension.
00207 .P
00208 If the application is a 64-bit application, then the stack
00209 values are all 64 bits and all operations are done on 64 bits.
00210 .H 3 "The fbreg location op"
00211 Compilers shipped with IRIX 6.0 and 6.1
00212 do not emit the fbreg location expression
00213 and never emit the DW_AT_frame_base attribute that it
00214 depends on.
00215 However, this changes
00216 with release 6.2 and these are now emitted routinely.
00217
00218 .H 1 "Frame Information"
00219 .H 2 "Initial Instructions"
00220 The DWARF V2 spec
00221 provides for "initial instructions" in each CIE (page 61,
00222 section 6.4.1).
00223 However, it does not say whether there are default
00224 values for each column (register).
00225 .P
00226 Rather than force every CIE to have a long list
00227 of bytes to initialize all 32 integer registers,
00228 we define that the default values of all registers
00229 (as returned by libdwarf in the frame interface)
00230 are 'same value'.
00231 This is a good choice for many non-register-windows
00232 implementations.
00233 .H 2 "Augmentation string in debug_frame"
00234 The augmentation string we use in shipped compilers (up thru
00235 irix6.2) is the empty string.
00236 IRIX6.2 and later has an augmentation string
00237 the empty string ("")
00238 or "z" or "mti v1"
00239 where the "v1" is a version number (version 1).
00240 .P
00241 We do not believe that "mti v1" was emitted as the
00242 augmentation string in any shipped compiler.
00243 .P
00244 .H 3 "CIE processing based on augmentation string:"
00245 If the augmentation string begins with 'z', then it is followed
00246 immediately by a unsigned_leb_128 number giving the code alignment factor.
00247 Next is a signed_leb_128 number giving the data alignment factor.
00248 Next is a unsigned byte giving the number of the return address register.
00249 Next is an unsigned_leb_128 number giving the length of the 'augmentation'
00250 fields (the length of augmentation bytes, not
00251 including the unsigned_leb_128 length itself).
00252 As of release 6.2, the length of the CIE augmentation fields is 0.
00253 What this means is that it is possible to add new
00254 augmentations, z1, z2, etc and yet an old consumer to
00255 understand the entire CIE as it can bypass the
00256 augmentation it does not understand because the
00257 length of the augmentation fields is present.
00258 Presuming of course that all augmentation fields are
00259 simply additional information,
00260 not some 'changing of the meaning of
00261 an existing field'.
00262 Currently there is no CIE data in the augmentation for things
00263 beginning with 'z'.
00264 .P
00265 If the augmentation string is "mti v1" or "" then it is followed
00266 immediately by a unsigned_leb_128 number giving the code alignment factor.
00267 Next is a signed_leb_128 number giving the data alignment factor.
00268 Next is a unsigned byte giving the number of the return address register.
00269 .P
00270 If the augmentation string is something else, then the
00271 code alignment factor is assumed to be 4 and the data alignment
00272 factor is assumed to be -1 and the return
00273 address register is assumed to be 31. Arbitrarily.
00274 The library (libdwarf) assumes it does not understand the rest of the CIE.
00275 .P
00276 .H 3 "FDE processing based on augmentation"
00277 If the CIE augmentation string
00278 for an fde begins with 'z'
00279 then the next FDE field after the address_range field
00280 is an
00281 unsigned_leb_128 number giving the length of the 'augmentation'
00282 fields, and those fields follow immediately.
00283
00284 .H 4 "FDE augmentation fields"
00285 .P
00286 If the CIE augmentation string is "mti v1" or ""
00287 then the FDE is exactly as described in the Dwarf Document section 6.4.1.
00288 .P
00289 Else, if the CIE augmentation string begins with "z"
00290 then the next field after the FDE augmentation length field
00291 is a Dwarf_Sword size offset into
00292 exception tables.
00293 If the CIE augmentation string does not begin with "z"
00294 (and is neither "mti v1" nor "")
00295 the FDE augmentation fields are skipped (not understood).
00296 Note that libdwarf actually (as of MIPSpro7.3 and earlier)
00297 only tests that the initial character of the augmentation
00298 string is 'z', and ignores the rest of the string, if any.
00299 So in reality the test is for a _prefix_ of 'z'.
00300 .P
00301 If the CIE augmentation string neither starts with 'z' nor is ""
00302 nor is "mti v1" then libdwarf (incorrectly) assumes that the
00303 table defining instructions start next.
00304 Processing (in libdwarf) will be incorrect.
00305 .H 2 "Stack Pointer recovery from debug_frame"
00306 There is no identifiable means in
00307 DWARF2 to say that the stack register is
00308 recovered by any particular operation.
00309 A 'register rule' works if the caller's
00310 stack pointer was copied to another
00311 register.
00312 An 'offset(N)' rule works if the caller's
00313 stack pointer was stored on the stack.
00314 However if the stack pointer is
00315 some register value plus/minus some offset,
00316 there is no means to say this in an FDE.
00317 For MIPS/IRIX, the recovered stack pointer
00318 of the next frame up the stack (towards main())
00319 is simply the CFA value of the current
00320 frame, and the CFA value is
00321 precisely a register (value of a register)
00322 or a register plus offset (value of a register
00323 plus offset). This is a software convention.
00324 .H 1 "egcs dwarf extensions (egcs-1.1.2 extensions)"
00325 This and following egcs sections describe
00326 the extensions currently shown in egcs dwarf2.
00327 Note that egcs has chosen to adopt tag and
00328 attribute naming as if their choices were
00329 standard dwarf, not as if they were extensions.
00330 However, they are properly numbered as extensions.
00331
00332 .H 2 "DW_TAG_format_label 0x4101"
00333 For FORTRAN 77, Fortran 90.
00334 Details of use not defined in egcs source, so
00335 unclear if used.
00336 .H 2 "DW_TAG_function_template 0x4102"
00337 For C++.
00338 Details of use not defined in egcs source, so
00339 unclear if used.
00340 .H 2 "DW_TAG_class_template 0x4103"
00341 For C++.
00342 Details of use not defined in egcs source, so
00343 unclear if used.
00344 .H 2 "DW_AT_sf_names 0x2101"
00345 Apparently only output in DWARF1, not DWARF2.
00346 .H 2 "DW_AT_src_info 0x2102"
00347 Apparently only output in DWARF1, not DWARF2.
00348 .H 2 "DW_AT_mac_info 0x2103"
00349 Apparently only output in DWARF1, not DWARF2.
00350 .H 2 "DW_AT_src_coords 0x2104"
00351 Apparently only output in DWARF1, not DWARF2.
00352 .H 2 "DW_AT_body_begin 0x2105"
00353 Apparently only output in DWARF1, not DWARF2.
00354 .H 2 "DW_AT_body_end 0x2106"
00355 Apparently only output in DWARF1, not DWARF2.
00356
00357 .H 1 "egcs .eh_frame (non-sgi) (egcs-1.1.2 extensions)"
00358 egcs-1.1.2 (and earlier egcs)
00359 emits by default a section named .eh_frame
00360 for ia32 (and possibly other platforms) which
00361 is nearly identical to .debug_frame in format and content.
00362 This section is used for helping handle C++ exceptions.
00363 .P
00364 Because after linking there are sometimes zero-ed out bytes
00365 at the end of the eh_frame section, the reader code in
00366 dwarf_frame.c considers a zero cie/fde length as an indication
00367 that it is the end of the section.
00368 .P
00369 .H 2 "CIE_id 0"
00370 The section is an ALLOCATED section in an executable, and
00371 is therefore mapped into memory at run time.
00372 The CIE_pointer (aka CIE_id, section 6.4.1
00373 of the DWARF2 document) is the field that
00374 distinguishes a CIE from an FDE.
00375 The designers of the egcs .eh_frame section
00376 decided to make the CIE_id
00377 be 0 as the CIE_pointer definition is
00378 .in +2
00379 the number of bytes from the CIE-pointer in the FDE back to the
00380 applicable CIE.
00381 .in -2
00382 In a dwarf .debug_frame section, the CIE_pointer is the
00383 offset in .debug_frame of the CIE for this fde, and
00384 since an offset can be zero of some CIE, the CIE_id
00385 cannot be 0, but must be all 1 bits .
00386 Note that the dwarf2.0 spec does specify the value of CIE_id
00387 as 0xffffffff
00388 (see section 7.23 of v2.0.0),
00389 though earlier versions of this extensions document
00390 incorrectly said it was not specified in the dwarf
00391 document.
00392 .H 2 "augmentation eh"
00393 The augmentation string in each CIE is "eh"
00394 which, with its following NUL character, aligns
00395 the following word to a 32bit boundary.
00396 Following the augmentation string is a 32bit
00397 word with the address of the __EXCEPTION_TABLE__,
00398 part of the exception handling data for egcs.
00399 .H 2 "DW_CFA_GNU_window_save 0x2d"
00400 This is effectively a flag for architectures with
00401 register windows, and tells the unwinder code that
00402 it must look to a previous frame for the
00403 correct register window set.
00404 As of this writing, egcs gcc/frame.c
00405 indicates this is for SPARC register windows.
00406 .H 2 "DW_CFA_GNU_args_size 0x2e"
00407 DW_CFA_GNU_args_size has a single uleb128 argument
00408 which is the size, in bytes, of the function's stack
00409 at that point in the function.
00410 .H 2 "__EXCEPTION_TABLE__"
00411 A series of 3 32bit word entries by default:
00412 0 word: low pc address
00413 1 word: high pc address
00414 2 word: pointer to exception handler code
00415 The end of the table is
00416 signaled by 2 words of -1 (not 3 words!).
00417 .H 1 "Interpretations of the DWARF V2 spec"
00418 .H 2 "template TAG spellings"
00419 The DWARF V2 spec spells two attributes in two ways.
00420 DW_TAG_template_type_param
00421 (listed in Figure 1, page 7)
00422 is spelled DW_TAG_template_type_parameter
00423 in the body of the document (section 3.3.7, page 28).
00424 We have adopted the spelling
00425 DW_TAG_template_type_param.
00426 .P
00427 DW_TAG_template_value_param
00428 (listed in Figure 1, page 7)
00429 is spelled DW_TAG_template_value_parameter
00430 in the body of the document (section 3.3.7, page 28).
00431 We have adopted the spelling
00432 DW_TAG_template_value_parameter.
00433 .P
00434 We recognize that the choices adopted are neither consistently
00435 the longer nor the shorter name.
00436 This inconsistency was an accident.
00437 .H 2 DW_FORM_ref_addr confusing
00438 Section 7.5.4, Attribute Encodings, describes
00439 DW_FORM_ref_addr.
00440 The description says the reference is the size of an address
00441 on the target architecture.
00442 This is surely a mistake, because on a 16bit-pointer-architecture
00443 it would mean that the reference could not exceed
00444 16 bits, which makes only
00445 a limited amount of sense as the reference is from one
00446 part of the dwarf to another, and could (in theory)
00447 be *on the disk* and not limited to what fits in memory.
00448 Since MIPS is 32 bit pointers (at the smallest)
00449 the restriction is not a problem for MIPS/SGI.
00450 The 32bit pointer ABIs are limited to 32 bit section sizes
00451 anyway (as a result of implementation details).
00452 And the 64bit pointer ABIs currently have the same limit
00453 as a result of how the compilers and tools are built
00454 (this has not proven to be a limit in practice, so far).
00455 .H 2 ".debug_macinfo in a debugger"
00456 It seems quite difficult, in general, to
00457 tie specific text(code) addresses to points in the
00458 stream of macro information for a particular compilation unit.
00459 So it's been difficult to see how to design a consumer
00460 interface to libdwarf for macro information.
00461 .P
00462 The best (simple to implement, easy for a debugger user to
00463 understand) candidate seems to be that
00464 the debugger asks for macros of a given name in a compilation
00465 unit, and the debugger responds with *all* the macros of that name.
00466 .H 3 "only a single choice exists"
00467 If there is exactly one, that is usable in expressions, if the
00468 debugger is able to evaluate such.
00469 .H 3 "multiple macros with same name".
00470 If there are multiple macros with the same name
00471 in a compilation unit,
00472 the debugger (and the debugger user and the application
00473 programmer) have
00474 a problem: confusion is quite possible.
00475 If the macros are simple the
00476 debugger user can simply substitute by hand in an expression.
00477 If the macros are complicated hand substitution will be
00478 impractical, and the debugger will have to identify the
00479 choices and let the debugger user choose an interpretation.
00480 .H 2 "Section 6.1.2 Lookup by address problem"
00481 Each entry is a beginning-address followed by a length.
00482 And the distinguished entry 0,0 is used to denote
00483 the end of a range of entries.
00484 .P
00485 This means that one must be careful not to emit a zero length,
00486 as in a .o (object file) the beginning address of
00487 a normal entry might be 0 (it is a section offset after all),
00488 and the resulting 0,0 would be taken as end-of-range, not
00489 as a valid entry.
00490 A dwarf dumper would have trouble with such data
00491 in an object file.
00492 .P
00493 In an a.out or shared object (dynamic shared object, DSO)
00494 no text will be at address zero so in such this problem does
00495 not arise.
00496 .H 2 "Section 5.10 Subrange Type Entries problem"
00497 It is specified that DW_AT_upper_bound (and lower bound)
00498 must be signed entries if there is no object type
00499 info to specify the bound type (Sec 5.10, end of section).
00500 One cannot tell (with some
00501 dwarf constant types) what the signedness is from the
00502 form itself (like DW_FORM_data1), so it is necessary
00503 to determine the object and type according to the rules
00504 in 5.10 and then if all that fails, the type is signed.
00505 It's a bit complicated and earlier versions of mips_extensions
00506 incorrectly said signedness was not defined.
00507 .H 2 "Section 5.5.6 Class Template Instantiations problem"
00508 Lots of room for implementor to canonicalize
00509 template declarations. Ie various folks won't agree.
00510 This is not serious since a given compiler
00511 will be consistent with itself and debuggers
00512 will have to cope!
00513 .H 2 "Section 2.4.3.4 # 11. operator spelling"
00514 DW_OP_add should be DW_OP_plus (page 14)
00515 (this mistake just one place on the page).
00516 .H 2 "No clear specification of C++ static funcs"
00517 There is no clear way to tell if a C++ member function
00518 is a static member or a non-static member function.
00519 (dwarf2read.c in gdb 4.18, for example, has this observation)
00520 .H 2 "Misspelling of DW_AT_const_value"
00521 Twice in appendix 1, DW_AT_const_value is misspelled
00522 as DW_AT_constant_value.
00523 .H 2 "Mistake in Atribute Encodings"
00524 Section 7.5.4, "Attribute Encodings"
00525 has a brief discussion of "constant"
00526 which says there are 6 forms of constants.
00527 It is incorrect in that it fails to mention (or count)
00528 the block forms, which are clearly allowed by
00529 section 4.1 "Data Object Entries" (see entry number 9 in
00530 the numbered list, on constants).
00531 .H 2 "DW_OP_bregx"
00532 The description of DW_OP_bregx in 2.4.3.2 (Register Based
00533 Addressing) is slightly misleading, in that it
00534 lists the offset first.
00535 As section 7.7.1 (Location Expression)
00536 makes clear, in the encoding the register number
00537 comes first.
00538 .H 1 "MIPS attributes"
00539 .H 2 "DW_AT_MIPS_fde"
00540 This extension to Dwarf appears only on subprogram TAGs and has as
00541 its value the offset, in the .debug_frame section, of the fde which
00542 describes the frame of this function. It is an optimization of
00543 sorts to have this present.
00544
00545 .H 2 "DW_CFA_MIPS_advance_loc8 0x1d"
00546 This obvious extension to dwarf line tables enables encoding of 8 byte
00547 advance_loc values (for cases when such must be relocatable,
00548 and thus must be full length). Applicable only to 64-bit objects.
00549
00550 .H 2 "DW_TAG_MIPS_loop 0x4081"
00551 For future use. Not currently emitted.
00552 Places to be emitted and attributes that this might own
00553 not finalized.
00554
00555 .H 2 "DW_AT_MIPS_loop_begin 0x2002"
00556 For future use. Not currently emitted.
00557 Attribute form and content not finalized.
00558
00559 .H 2 "DW_AT_MIPS_tail_loop_begin 0x2003"
00560 For future use. Not currently emitted.
00561 Attribute form and content not finalized.
00562
00563 .H 2 "DW_AT_MIPS_epilog_begin 0x2004"
00564 For future use. Not currently emitted.
00565 Attribute form and content not finalized.
00566
00567 .H 2 "DW_AT_MIPS_loop_unroll_factor 0x2005"
00568 For future use. Not currently emitted.
00569 Attribute form and content not finalized.
00570
00571 .H 2 "DW_AT_MIPS_software_pipeline_depth 0x2006"
00572 For future use. Not currently emitted.
00573 Attribute form and content not finalized.
00574 .H 2 "DW_AT_MIPS_linkage_name 0x2007"
00575 The rules for mangling C++ names are not part of the
00576 C++ standard and are different for different versions
00577 of C++. With this extension, the compiler emits
00578 both the DW_AT_name for things with mangled names
00579 (recall that DW_AT_name is NOT the mangled form)
00580 and also emits DW_AT_MIPS_linkage_name whose value
00581 is the mangled name.
00582 .P
00583 This makes looking for the mangled name in other linker
00584 information straightforward.
00585 It also is passed (by the debugger) to the
00586 libmangle routines to generate names to present to the
00587 debugger user.
00588 .H 2 "DW_AT_MIPS_stride 0x2008"
00589 F90 allows assumed shape arguments and pointers to describe
00590 non-contiguous memory. A (runtime) descriptor contains address,
00591 bounds and stride information - rank and element size is known
00592 during compilation. The extent in each dimension is given by the
00593 bounds in a DW_TAG_subrange_type, but the stride cannot be
00594 represented in conventional dwarf. DW_AT_MIPS_stride was added as
00595 an attribute of a DW_TAG_subrange_type to describe the
00596 location of the stride.
00597 Used in the MIPSpro 7.2 (7.2.1 etc) compilers.
00598 .P
00599 If the stride is constant (ie: can be inferred from the type in the
00600 usual manner) DW_AT_MIPS_stride is absent.
00601 .P
00602 If DW_AT_MIPS_stride is present, the attribute contains a reference
00603 to a DIE which describes the location holding the stride, and the
00604 DW_AT_stride_size field of DW_TAG_array_type is ignored if
00605 present. The value of the stride is the number of
00606 4 byte words between
00607 elements along that axis.
00608 .P
00609 This applies to
00610 .nf
00611 a) Intrinsic types whose size is greater
00612 or equal to 4bytes ie: real*4,integer*8
00613 complex etc, but not character types.
00614
00615 b) Derived types (ie: structs) of any size,
00616 unless all components are of type character.
00617 .fi
00618
00619 .H 2 "DW_AT_MIPS_abstract_name 0x2009"
00620 This attribute only appears in a DA_TAG_inlined_subroutine DIE.
00621 The value of this attribute is a string.
00622 When IPA inlines a routine and the abstract origin is
00623 in another compilation unit, there is a problem with putting
00624 in a reference, since the ordering and timing of the
00625 creation of references is unpredicatable with reference to
00626 the DIE and compilation unit the reference refers to.
00627 .P
00628 Since there may be NO ordering of the compilation units that
00629 allows a correct reference to be done without some kind of patching,
00630 and since even getting the information from one place to another
00631 is a problem, the compiler simply passes the problem on to the debugger.
00632 .P
00633 The debugger must match the DW_AT_MIPS_abstract_name
00634 in the concrete
00635 inlined instance DIE
00636 with the DW_AT_MIPS_abstract_name
00637 in the abstract inlined subroutine DIE.
00638 .P
00639 A dwarf-consumer-centric view of this and other inline
00640 issues could be expressed as follows:
00641 .nf
00642 If DW_TAG_subprogram
00643 If has DW_AT_inline is abstract instance root
00644 If has DW_AT_abstract_origin, is out-of-line instance
00645 of function (need abstract origin for some data)
00646 (abstract root in same CU (conceptually anywhere
00647 a ref can reach, but reaching outside of CU is
00648 a problem for ipa: see DW_AT_MIPS_abstract_name))
00649 If has DW_AT_MIPS_abstract_name is abstract instance
00650 root( must have DW_AT_inline) and this name is used to
00651 match with the abstract root
00652
00653 If DW_TAG_inline_subroutine
00654 Is concrete inlined subprogram instance.
00655 If has DW_AT_abstract_origin, it is a CU-local inline.
00656 If it has DW_AT_MIPS_abstract_name it is an
00657 inline whose abstract root is in another file (CU).
00658 .fi
00659
00660 .H 2 "DW_AT_MIPS_clone_origin 0x200a"
00661 This attribute appears only in a cloned subroutine.
00662 The procedure is cloned from the same compilation unit.
00663 The value of this attribute is a reference to
00664 the original routine in this compilation unit.
00665 .P
00666 The 'original' routine means the routine which has all the
00667 original code. The cloned routines will always have
00668 been 'specialized' by IPA.
00669 A routine with DW_AT_MIPS_clone_origin
00670 will also have the DW_CC_nocall value of the DW_AT_calling_convention
00671 attribute.
00672
00673 .H 2 "DW_AT_MIPS_has_inlines 0x200b"
00674 This attribute may appear in a DW_TAG_subprogram DIE.
00675 If present and it has the value True, then the subprogram
00676 has inlined functions somewhere in the body.
00677 .P
00678 By default, at startup, the debugger may not look for
00679 inlined functions in scopes inside the outer function.
00680 .P
00681 This is a hint to the debugger to look for the inlined functions
00682 so the debugger can set breakpoints on these in case the user
00683 requests 'stop in foo' and foo is inlined.
00684 .H 2 "DW_AT_MIPS_stride_byte 0x200c"
00685 Created for f90 pointer and assumed shape
00686 arrays.
00687 Used in the MIPSpro 7.2 (7.2.1 etc) compilers.
00688 A variant of DW_AT_MIPS_stride.
00689 This stride is interpreted as a byte count.
00690 Used for integer*1 and character arrays
00691 and arrays of derived type
00692 whose components are all character.
00693 .H 2 "DW_AT_MIPS_stride_elem 0x200d"
00694 Created for f90 pointer and assumed shape
00695 arrays.
00696 Used in the MIPSpro 7.2 (7.2.1 etc) compilers.
00697 A variant of DW_AT_MIPS_stride.
00698 This stride is interpreted as a byte-pair (2 byte) count.
00699 Used for integer*2 arrays.
00700 .H 2 "DW_AT_MIPS_ptr_dopetype 0x200e"
00701 See following.
00702 .H 2 "DW_AT_MIPS_allocatable_dopetype 0x200f"
00703 See following.
00704 .H 2 "DW_AT_MIPS_assumed_shape_dopetype 0x2010"
00705 DW_AT_MIPS_assumed_shape_dopetype, DW_AT_MIPS_allocatable_dopetype,
00706 and DW_AT_MIPS_ptr_dopetype have an attribute value
00707 which is a reference to a Fortran 90 Dope Vector.
00708 These attributes are introduced in MIPSpro7.3.
00709 They only apply to f90 arrays (where they are
00710 needed to describe arrays never properly described
00711 before in debug information).
00712 C, C++, f77, and most f90 arrays continue to be described
00713 in standard dwarf.
00714 .P
00715 The distinction between these three attributes is the f90 syntax
00716 distinction: keywords 'pointer' and 'allocatable' with the absence
00717 of these keywords on an assumed shape array being the third case.
00718 .P
00719 A "Dope Vector" is a struct (C struct) which describes
00720 a dynamically-allocatable array.
00721 In objects with full debugging the C struct will be
00722 in the dwarf information (of the f90 object, represented like C).
00723 A debugger will use the link to find the main struct DopeVector
00724 and will use that information to decode the dope vector.
00725 At the outer allocatable/assumed-shape/pointer
00726 the DW_AT_location points at the dope vector (so debugger
00727 calculations use that as a base).
00728 .H 2 "Overview of debugger use of dope vectors"
00729 Fundamentally, we build two distinct
00730 representations of the arrays and pointers.
00731 One, in dwarf, represents the statically-representable
00732 information (the types and
00733 variable/type-names, without type size information).
00734 The other, using dope vectors in memory, represents
00735 the run-time data of sizes.
00736 A debugger must process the two representations
00737 in parallel (and merge them) to deal with user expressions in
00738 a debugger.
00739 .H 2 "Example f90 code for use in explanation"
00740 [Note
00741 We want dwarf output with *exactly*
00742 this little (arbitrary) example.
00743 Not yet available.
00744 end Note]
00745 Consider the following code.
00746 .nf
00747 type array_ptr
00748 real :: myvar
00749 real, dimension (:), pointer :: ap
00750 end type array_ptr
00751
00752 type (array_ptr), allocatable, dimension (:) :: arrays
00753
00754 allocate (arrays(20))
00755 do i = 1,20
00756 allocate (arrays(i)%ap(i))
00757 end do
00758 .fi
00759 arrays is an allocatable array (1 dimension) whose size is
00760 not known at compile time (it has
00761 a Dope Vector). At run time, the
00762 allocate statement creats 20 array_ptr dope vectors
00763 and marks the base arrays dopevector as allocated.
00764 The myvar variable is just there to add complexity to
00765 the example :-)
00766 .nf
00767 In the loop, arrays(1)%ap(1)
00768 is allocated as a single element array of reals.
00769 In the loop, arrays(2)%ap(2)
00770 is allocated as an array of two reals.
00771 ...
00772 In the loop, arrays(20)%ap(20)
00773 is allocated as an array of twenty reals.
00774 .fi
00775 .H 2 "the problem with standard dwarf and this example"
00776 .sp
00777 In dwarf, there is no way to find the array bounds of arrays(3)%ap,
00778 for example, (which are 1:3 in f90 syntax)
00779 since any location expression in an ap array lower bound
00780 attribute cannot involve the 3 (the 3 is known at debug time and
00781 does not appear in the running binary, so no way for the
00782 location expression to get to it).
00783 And of course the 3 must actually index across the array of
00784 dope vectors in 'arrays' in our implementation, but that is less of
00785 a problem than the problem with the '3'.
00786 .sp
00787 Plus dwarf has no way to find the 'allocated' flag in the
00788 dope vector (so the debugger can know when the allocate is done
00789 for a particular arrays(j)%ap).
00790 .sp
00791 Consequently, the calculation of array bounds and indices
00792 for these dynamically created f90 arrays
00793 is now pushed of into the debugger, which must know the
00794 field names and usages of the dope vector C structure and
00795 use the field offsets etc to find data arrays.
00796 C, C++, f77, and most f90 arrays continue to be described
00797 in standard dwarf.
00798 At the outer allocatable/assumed-shape/pointer
00799 the DW_AT_location points at the dope vector (so debugger
00800 calculations use that as a base).
00801 .P
00802 It would have been nice to design a dwarf extension
00803 to handle the above problems, but
00804 the methods considered to date were not
00805 any more consistent with standard dwarf than
00806 this dope vector centric approach: essentially just
00807 as much work in the debugger appeared necessary either way.
00808 A better (more dwarf-ish)
00809 design would be welcome information.
00810
00811 .H 2 "A simplified sketch of the dwarf information"
00812 [Note:
00813 Needs to be written.
00814 end Note]
00815
00816 .H 2 "A simplified sketch of the dope vector information"
00817 [Note:
00818 This one is simplified.
00819 Details left out that should be here. Amplify.
00820 end Note]
00821 This is an overly simplified version of a dope vector,
00822 presented as an initial hint.
00823 Full details presented later.
00824 .nf
00825 struct simplified{
00826 void *base;
00827 long el_len;
00828 int assoc:1
00829 int ptr_alloc:1
00830 int num_dims:3;
00831 struct dims_s {
00832 long lb;
00833 long ext;
00834 long str_m;
00835 } dims;
00836 };
00837 .fi
00838 Only 'num_dims' elements of dims are actually used.
00839
00840 .H 2 "The dwarf information"
00841
00842 Here is dwarf information from the compiler for
00843 the example above, as printed by dwarfdump(1)
00844 .nf
00845 [Note:
00846 The following may not be the test.
00847 Having field names with '.' in the name is
00848 not such a good idea, as it conflicts with the
00849 use of '.' in dbx extended naming.
00850 Something else, like _$, would be much easier
00851 to work with in dbx (customers won't care about this,
00852 for the most part,
00853 but folks working on dbx will, and in those
00854 rare circumstances when a customer cares,
00855 the '.' will be a real problem in dbx.).
00856 Note that to print something about .base., in dbx one
00857 would have to do
00858 whatis `.base.`
00859 where that is the grave accent, or back-quote I am using.
00860 With extended naming one do
00861 whatis `.dope.`.`.base.`
00862 which is hard to type and hard to read.
00863 end Note]
00864
00865 <2>< 388> DW_TAG_array_type
00866 DW_AT_name .base.
00867 DW_AT_type <815>
00868 DW_AT_declaration yes(1)
00869 <3>< 401> DW_TAG_subrange_type
00870 DW_AT_lower_bound 0
00871 DW_AT_upper_bound 0
00872 <2>< 405> DW_TAG_pointer_type
00873 DW_AT_type <388>
00874 DW_AT_byte_size 4
00875 DW_AT_address_class 0
00876 <2>< 412> DW_TAG_structure_type
00877 DW_AT_name .flds.
00878 DW_AT_byte_size 28
00879 <3>< 421> DW_TAG_member
00880 DW_AT_name el_len
00881 DW_AT_type <815>
00882 DW_AT_data_member_location DW_OP_consts 0
00883 <3>< 436> DW_TAG_member
00884 DW_AT_name assoc
00885 DW_AT_type <841>
00886 DW_AT_byte_size 0
00887 DW_AT_bit_offset 0
00888 DW_AT_bit_size 1
00889 DW_AT_data_member_location DW_OP_consts 4
00890 <3>< 453> DW_TAG_member
00891 DW_AT_name ptr_alloc
00892 DW_AT_type <841>
00893 DW_AT_byte_size 0
00894 DW_AT_bit_offset 1
00895 DW_AT_bit_size 1
00896 DW_AT_data_member_location DW_OP_consts 4
00897 <3>< 474> DW_TAG_member
00898 DW_AT_name p_or_a
00899 DW_AT_type <841>
00900 DW_AT_byte_size 0
00901 DW_AT_bit_offset 2
00902 DW_AT_bit_size 2
00903 DW_AT_data_member_location DW_OP_consts 4
00904 <3>< 492> DW_TAG_member
00905 DW_AT_name a_contig
00906 DW_AT_type <841>
00907 DW_AT_byte_size 0
00908 DW_AT_bit_offset 4
00909 DW_AT_bit_size 1
00910 DW_AT_data_member_location DW_OP_consts 4
00911 <3>< 532> DW_TAG_member
00912 DW_AT_name num_dims
00913 DW_AT_type <841>
00914 DW_AT_byte_size 0
00915 DW_AT_bit_offset 29
00916 DW_AT_bit_size 3
00917 DW_AT_data_member_location DW_OP_consts 8
00918 <3>< 572> DW_TAG_member
00919 DW_AT_name type_code
00920 DW_AT_type <841>
00921 DW_AT_byte_size 0
00922 DW_AT_bit_offset 0
00923 DW_AT_bit_size 32
00924 DW_AT_data_member_location DW_OP_consts 16
00925 <3>< 593> DW_TAG_member
00926 DW_AT_name orig_base
00927 DW_AT_type <841>
00928 DW_AT_data_member_location DW_OP_consts 20
00929 <3>< 611> DW_TAG_member
00930 DW_AT_name orig_size
00931 DW_AT_type <815>
00932 DW_AT_data_member_location DW_OP_consts 24
00933 <2>< 630> DW_TAG_structure_type
00934 DW_AT_name .dope_bnd.
00935 DW_AT_byte_size 12
00936 <3>< 643> DW_TAG_member
00937 DW_AT_name lb
00938 DW_AT_type <815>
00939 DW_AT_data_member_location DW_OP_consts 0
00940 <3>< 654> DW_TAG_member
00941 DW_AT_name ext
00942 DW_AT_type <815>
00943 DW_AT_data_member_location DW_OP_consts 4
00944 <3>< 666> DW_TAG_member
00945 DW_AT_name str_m
00946 DW_AT_type <815>
00947 DW_AT_data_member_location DW_OP_consts 8
00948 <2>< 681> DW_TAG_array_type
00949 DW_AT_name .dims.
00950 DW_AT_type <630>
00951 DW_AT_declaration yes(1)
00952 <3>< 694> DW_TAG_subrange_type
00953 DW_AT_lower_bound 0
00954 DW_AT_upper_bound 0
00955 <2>< 698> DW_TAG_structure_type
00956 DW_AT_name .dope.
00957 DW_AT_byte_size 44
00958 <3>< 707> DW_TAG_member
00959 DW_AT_name base
00960 DW_AT_type <405>
00961 DW_AT_data_member_location DW_OP_consts 0
00962 <3>< 720> DW_TAG_member
00963 DW_AT_name .flds
00964 DW_AT_type <412>
00965 DW_AT_data_member_location DW_OP_consts 4
00966 <3>< 734> DW_TAG_member
00967 DW_AT_name .dims.
00968 DW_AT_type <681>
00969 DW_AT_data_member_location DW_OP_consts 32
00970 <2>< 750> DW_TAG_variable
00971 DW_AT_type <815>
00972 DW_AT_location DW_OP_fbreg -32
00973 DW_AT_artificial yes(1)
00974 <2>< 759> DW_TAG_variable
00975 DW_AT_type <815>
00976 DW_AT_location DW_OP_fbreg -28
00977 DW_AT_artificial yes(1)
00978 <2>< 768> DW_TAG_variable
00979 DW_AT_type <815>
00980 DW_AT_location DW_OP_fbreg -24
00981 DW_AT_artificial yes(1)
00982 <2>< 777> DW_TAG_array_type
00983 DW_AT_type <815>
00984 DW_AT_declaration yes(1)
00985 <3>< 783> DW_TAG_subrange_type
00986 DW_AT_lower_bound <750>
00987 DW_AT_count <759>
00988 DW_AT_MIPS_stride <768>
00989 <2>< 797> DW_TAG_variable
00990 DW_AT_decl_file 1
00991 DW_AT_decl_line 1
00992 DW_AT_name ARRAY
00993 DW_AT_type <698>
00994 DW_AT_location DW_OP_fbreg -64 DW_OP_deref
00995 <1>< 815> DW_TAG_base_type
00996 DW_AT_name INTEGER_4
00997 DW_AT_encoding DW_ATE_signed
00998 DW_AT_byte_size 4
00999 <1>< 828> DW_TAG_base_type
01000 DW_AT_name INTEGER_8
01001 DW_AT_encoding DW_ATE_signed
01002 DW_AT_byte_size 8
01003 <1>< 841> DW_TAG_base_type
01004 DW_AT_name INTEGER*4
01005 DW_AT_encoding DW_ATE_unsigned
01006 DW_AT_byte_size 4
01007 <1>< 854> DW_TAG_base_type
01008 DW_AT_name INTEGER*8
01009 DW_AT_encoding DW_ATE_unsigned
01010 DW_AT_byte_size 8
01011
01012 .fi
01013 .H 2 "The dope vector structure details"
01014 A dope vector is the following C struct, "dopevec.h".
01015 Not all the fields are of use to a debugger.
01016 It may be that not all fields will show up
01017 in the f90 dwarf (since not all are of interest to debuggers).
01018 .nf
01019 [Note:
01020 Need details on the use of each field.
01021 And need to know which are really 32 bits and which
01022 are 32 or 64.
01023 end Note]
01024 The following
01025 struct
01026 is a representation of all the dope vector fields.
01027 It suppresses irrelevant detail and may not
01028 exactly match the layout in memory (a debugger must
01029 examine the dwarf to find the fields, not
01030 compile this structure into the debugger!).
01031 .nf
01032 struct .dope. {
01033 void *base;
01034 struct .flds. {
01035 long el_len;
01036 unsigned int assoc:1;
01037 unsigned int ptr_alloc:1;
01038 unsigned int p_or_a:2;
01039 unsigned int a_contig:1;
01040 unsigned int num_dims: 3;
01041 unsigned int type_code:32;
01042 unsigned int orig_base;
01043 long orig_size;
01044 } .flds;
01045
01046 struct .dope_bnd. {
01047 long lb ;
01048 long ext ;
01049 long str_m;
01050 } .dims;
01051 }
01052 .fi
01053
01054 .H 2 "DW_AT_MIPS_assumed_size 0x2011"
01055 This flag was invented to deal with f90 arrays.
01056 For example:
01057
01058 .nf
01059 pointer (rptr, axx(1))
01060 pointer (iptr, ita(*))
01061 rptr = malloc (100*8)
01062 iptr = malloc (100*4)
01063 .fi
01064
01065 This flag attribute has the value 'yes' (true, on) if and only if
01066 the size is unbounded, as iptr is.
01067 Both may show an explicit upper bound of 1 in the dwarf,
01068 but this flag notifies the debugger that there is explicitly
01069 no user-provided size.
01070
01071 So if a user asks for a printout of the rptr allocated
01072 array, the default will be of a single entry (as
01073 there is a user slice bound in the source).
01074 In contrast, there is no explicit upper bound on the iptr
01075 (ita) array so the default slice will use the current bound
01076 (a value calculated from the malloc size, see the dope vector).
01077
01078 Given explicit requests, more of rptr(axx) can me shown
01079 than the default.
01080
01081 .H 1 "Line information and Source Position"
01082 DWARF does not define the meaning of the term 'source statement'.
01083 Nor does it define any way to find the first user-written
01084 executable code in a function.
01085 .P
01086 It does define that a source statement has a file name,
01087 a line number, and a column position (see Sec 6.2, Line Number
01088 Information of the Dwarf Version 2 document).
01089 We will call those 3 source coordinates a 'source position'
01090 in this document. We'll try not to accidentally call the
01091 source position a 'line number' since that is ambiguous
01092 as to what it means.
01093
01094 .H 2 "Definition of Statement"
01095 .P
01096 A function prolog is a statement.
01097 .P
01098 A C, C++, Pascal, or Fortran statement is a statement.
01099 .P
01100 Each initialized local variable in C,C++ is a statement
01101 in that its initialization generates a source position.
01102 This means that
01103 x =3, y=4;
01104 is two statements.
01105 .P
01106 For C, C++:
01107 The 3 parts a,b,c in for(a;b;c) {d;} are individual statements.
01108 The condition portion of a while() and do {} while() is
01109 a statement. (of course d; can be any number of statements)
01110 .P
01111 For Fortran, the controlling expression of a DO loop is a statement.
01112 Is a 'continue' statement in Fortran a DWARF statement?
01113 .P
01114 Each function return, whether user coded or generated by the
01115 compiler, is a statement. This is so one can step over (in
01116 a debugger) the final user-coded statement
01117 (exclusive of the return statement if any) in a function
01118 wile not leaving the function scope.
01119 .P
01120
01121 .H 2 "Finding The First User Code in a Function"
01122
01123 .nf
01124 Consider:
01125 int func(int a)
01126 {
01127 float b = a;
01128 int x;
01129 x = b + 2;
01130 }
01131 .fi
01132 .P
01133 The DIE for a function gives the address range of the function,
01134 including function prolog(s) and epilog(s)
01135 .P
01136 Since there is no scope block for the outer user scope of a
01137 function (and thus no beginning address range for the outer
01138 user scope: the DWARF committee explicitly rejected the idea
01139 of having a user scope block)
01140 it is necessary to use the source position information to find
01141 the first user-executable statement.
01142 .P
01143 This means that the user code for a function must be presumed
01144 to begin at the code location of the second source position in
01145 the function address range.
01146 .P
01147 If a function has exactly one source position, the function
01148 presumably consists solely of a return.
01149 .P
01150 If a function has exactly two source positions, the function
01151 may consist of a function prolog and a return or a single user
01152 statement and a return (there may be no prolog code needed in a
01153 leaf function). In this case, there is no way to be sure which
01154 is the first source position of user code, so the rule is to
01155 presume that the first address is user code.
01156 .P
01157 If a function consists of 3 or more source positions, one
01158 should assume that the first source position is function prolog and
01159 the second is the first user executable code.
01160
01161 .H 2 "Using debug_frame Information to find first user statement"
01162 In addition to the line information, the debug_frame information
01163 can be
01164 useful in determining the first user source line.
01165 .P
01166 Given that a function has more than 1 source position,
01167 Find the code location of the second source position, then
01168 examine the debug_frame information to determine if the Canonical
01169 Frame Address (cfa) is updated before the second source position
01170 code location.
01171 If the cfa is updated, then one can be pretty sure that the
01172 code for the first source position is function prolog code.
01173 .P
01174 Similarly, if the cfa is restored in the code for
01175 a source position, the source position is likely to
01176 represent a function exit block.
01177
01178 .H 2 "Debugger Use Of Source Position"
01179 Command line debuggers, such as dbx and gdb, will ordinarily
01180 want to consider multiple statements on one line to be a single
01181 statement: doing otherwise is distressing to users since it
01182 causes a 'step' command to appear to have no effect.
01183 .P
01184 An exception for command line debuggers is in determining the
01185 first user statement: as detailed above, there one wants to
01186 consider the full source position and will want to consider
01187 the function return a separate statement. It is difficult to
01188 make the function return a separate statement 'step' reliably
01189 however if a function is coded all on one line or if the last
01190 line of user code before the return is on the same line as the
01191 return.
01192 .P
01193 A graphical debugger has none of these problems if it simply
01194 highlights the portion of the line being executed. In that
01195 case, stepping will appear natural even stepping within a
01196 line.
01197 .H 1 "Known Bugs"
01198 Up through at least MIPSpro7.2.1
01199 the compiler has been emitting form DW_FORM_DATA1,2, or 4
01200 for DW_AT_const_value in DW_TAG_enumerator.
01201 And dwarfdump and debuggers have read this with dwarf_formudata()
01202 or form_sdata() and gotten some values incorrect.
01203 For example, a value of 128 was printed by debuggers as a negative value.
01204 Since dwarfdump and the compilers were not written to use the
01205 value the same way, their output differed.
01206 For negative enumerator values the compiler has been emitting 32bit values
01207 in a DW_FORM_DATA4.
01208 The compiler should probably be emitting a DW_FORM_sdata for
01209 enumerator values.
01210 And consumers of enumerator values should then call form_sdata().
01211 However, right now, debuggers should call form_udata() and only if
01212 it fails, call form_sdata().
01213 Anything else will break backward compatibility with
01214 the objects produced earlier.
01215 .SK
01216 .S
01217 .TC
01218 .CS
