* dwarf2read.c: Whitespace fixes for DWP file format documentation,

	and fix header docs.

2 files changed, 47 insertions, 37 deletions

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 5fdb1f8..102054b 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,8 @@
+2013-06-06  Doug Evans  <dje@google.com>
+
+	* dwarf2read.c: Whitespace fixes for DWP file format documentation,
+	and fix header docs.
+
 2013-06-05  Doug Evans  <dje@google.com>
 	    Keith Seitz  <keiths@redhat.com>
 
diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index 092a801..55b1b17 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -8867,62 +8867,67 @@ create_dwo_cu (struct dwo_file *dwo_file)
 /* DWP file .debug_{cu,tu}_index section format:
    [ref: http://gcc.gnu.org/wiki/DebugFissionDWP]
 
+   DWP Version 1:
+
    Both index sections have the same format, and serve to map a 64-bit
    signature to a set of section numbers.  Each section begins with a header,
    followed by a hash table of 64-bit signatures, a parallel table of 32-bit
    indexes, and a pool of 32-bit section numbers.  The index sections will be
    aligned at 8-byte boundaries in the file.
 
-   The index section header contains two unsigned 32-bit values (using the
-   byte order of the application binary):
+   The index section header consists of:
+
+    V, 32 bit version number
+    -, 32 bits unused
+    N, 32 bit number of compilation units or type units in the index
+    M, 32 bit number of slots in the hash table
 
-    N, the number of compilation units or type units in the index
-    M, the number of slots in the hash table
+   Numbers are recorded using the byte order of the application binary.
 
-  (We assume that N and M will not exceed 2^32 - 1.)
+   We assume that N and M will not exceed 2^32 - 1.
 
-  The size of the hash table, M, must be 2^k such that 2^k > 3*N/2.
+   The size of the hash table, M, must be 2^k such that 2^k > 3*N/2.
 
-  The hash table begins at offset 8 in the section, and consists of an array
-  of M 64-bit slots.  Each slot contains a 64-bit signature (using the byte
-  order of the application binary).  Unused slots in the hash table are 0.
-  (We rely on the extreme unlikeliness of a signature being exactly 0.)
+   The hash table begins at offset 16 in the section, and consists of an array
+   of M 64-bit slots.  Each slot contains a 64-bit signature (using the byte
+   order of the application binary).  Unused slots in the hash table are 0.
+   (We rely on the extreme unlikeliness of a signature being exactly 0.)
 
-  The parallel table begins immediately after the hash table
-  (at offset 8 + 8 * M from the beginning of the section), and consists of an
-  array of 32-bit indexes (using the byte order of the application binary),
-  corresponding 1-1 with slots in the hash table.  Each entry in the parallel
-  table contains a 32-bit index into the pool of section numbers.  For unused
-  hash table slots, the corresponding entry in the parallel table will be 0.
+   The parallel table begins immediately after the hash table
+   (at offset 16 + 8 * M from the beginning of the section), and consists of an
+   array of 32-bit indexes (using the byte order of the application binary),
+   corresponding 1-1 with slots in the hash table.  Each entry in the parallel
+   table contains a 32-bit index into the pool of section numbers.  For unused
+   hash table slots, the corresponding entry in the parallel table will be 0.
 
-  Given a 64-bit compilation unit signature or a type signature S, an entry
-  in the hash table is located as follows:
+   Given a 64-bit compilation unit signature or a type signature S, an entry
+   in the hash table is located as follows:
 
-  1) Calculate a primary hash H = S & MASK(k), where MASK(k) is a mask with
-     the low-order k bits all set to 1.
+   1) Calculate a primary hash H = S & MASK(k), where MASK(k) is a mask with
+      the low-order k bits all set to 1.
 
-  2) Calculate a secondary hash H' = (((S >> 32) & MASK(k)) | 1).
+   2) Calculate a secondary hash H' = (((S >> 32) & MASK(k)) | 1).
 
-  3) If the hash table entry at index H matches the signature, use that
-     entry.  If the hash table entry at index H is unused (all zeroes),
-     terminate the search: the signature is not present in the table.
+   3) If the hash table entry at index H matches the signature, use that
+      entry.  If the hash table entry at index H is unused (all zeroes),
+      terminate the search: the signature is not present in the table.
 
-  4) Let H = (H + H') modulo M. Repeat at Step 3.
+   4) Let H = (H + H') modulo M. Repeat at Step 3.
 
-  Because M > N and H' and M are relatively prime, the search is guaranteed
-  to stop at an unused slot or find the match.
+   Because M > N and H' and M are relatively prime, the search is guaranteed
+   to stop at an unused slot or find the match.
 
-  The pool of section numbers begins immediately following the hash table
-  (at offset 8 + 12 * M from the beginning of the section).  The pool of
-  section numbers consists of an array of 32-bit words (using the byte order
-  of the application binary).  Each item in the array is indexed starting
-  from 0.  The hash table entry provides the index of the first section
-  number in the set.  Additional section numbers in the set follow, and the
-  set is terminated by a 0 entry (section number 0 is not used in ELF).
+   The pool of section numbers begins immediately following the hash table
+   (at offset 16 + 12 * M from the beginning of the section).  The pool of
+   section numbers consists of an array of 32-bit words (using the byte order
+   of the application binary).  Each item in the array is indexed starting
+   from 0.  The hash table entry provides the index of the first section
+   number in the set.  Additional section numbers in the set follow, and the
+   set is terminated by a 0 entry (section number 0 is not used in ELF).
 
-  In each set of section numbers, the .debug_info.dwo or .debug_types.dwo
-  section must be the first entry in the set, and the .debug_abbrev.dwo must
-  be the second entry. Other members of the set may follow in any order.  */
+   In each set of section numbers, the .debug_info.dwo or .debug_types.dwo
+   section must be the first entry in the set, and the .debug_abbrev.dwo must
+   be the second entry. Other members of the set may follow in any order.  */
 
 /* Create a hash table to map DWO IDs to their CU/TU entry in
    .debug_{info,types}.dwo in DWP_FILE.