docs: clean up markdown

docs/symbol_files.md

 # Introduction
 
 Given a minidump file, the Breakpad processor produces stack traces that include
 function names and source locations. However, minidump files contain only the
 byte-by-byte contents of threads' registers and stacks, without function names
 or machine-code-to-source mapping data. The processor consults Breakpad symbol
 files for the information it needs to produce human-readable stack traces from
 the binary-only minidump file.
 
 The platform-specific symbol dumping tools parse the debugging information the
@@ skipping 44 matching lines @@
 from which this symbol file was generated. A symbol supplier might use this
 information to find the correct symbol files to use to interpret a given
 minidump, or to perform other sorts of validation. If present, a `MODULE` record
 should be the first line in the file.
 
 The fields are separated by spaces, and cannot contain spaces themselves, except
 for _name_.
 
 *   The _operatingsystem_ field names the operating system on which the
     executable or shared library was intended to run. This field should have one
-    of the following values: | **Value** | **Meaning** |
-    |:----------|:--------------------| | Linux | Linux | | mac | Macintosh OSX
-    | | windows | Microsoft Windows |
+    of the following values:
+
+    | **Value** | **Meaning** |
+    |:----------|:--------------------|
+    | Linux | Linux |
+    | mac | Macintosh OSX |
+    | windows | Microsoft Windows |
 
 *   The _architecture_ field indicates what processor architecture the
     executable or shared library contains machine code for. This field should
-    have one of the following values: | **Value** | **Instruction Set
-    Architecture** | |:----------|:---------------------------------| | x86 |
-    Intel IA-32 | | x86\_64 | AMD64/Intel 64 | | ppc | 32-bit PowerPC | | ppc64
-    | 64-bit PowerPC | | unknown | unknown |
+    have one of the following values:
+
+    | **Value** | **Instruction Set Architecture** |
+    |:----------|:---------------------------------|
+    | x86 | Intel IA-32 |
+    | x86\_64 | AMD64/Intel 64 |
+    | ppc | 32-bit PowerPC |
+    | ppc64 | 64-bit PowerPC |
+    | unknown | unknown |
 
 *   The _id_ field is a sequence of hexadecimal digits that identifies the exact
     executable or library whose contents the symbol file describes. The way in
     which it is computed varies from platform to platform.
 
 *   The _name_ field contains the base name (the final component of the
     directory path) of the executable or library. It may contain spaces, and
     extends to the end of the line.
 
 # `FILE` records
@@ skipping 105 matching lines @@
 > _has\_program\_string_ _program\_string\_OR\_allocates\_base\_pointer_
 
 For example: `STACK WIN 4 2170 14 1 0 0 0 0 0 1 $eip 4 + ^ = $esp $ebp 8 + =
 $ebp $ebp ^ =
 `
 
 All fields of a `STACK WIN` record, except for the last, are hexadecimal
 numbers.
 
 The _type_ field indicates what sort of stack frame data this record holds. Its
-value should be one of the values of the [StackFrameTypeEnum]
-(http://msdn.microsoft.com/en-us/library/bc5207xw%28VS.100%29.aspx) type in
-Microsoft's [Debug Interface Access (DIA)]
-(http://msdn.microsoft.com/en-us/library/x93ctkx8%28VS.100%29.aspx) API.
-Breakpad uses only records of type 4 (`FrameTypeFrameData`) and 0
+value should be one of the values of the
+[StackFrameTypeEnum](https://msdn.microsoft.com/en-us/library/bc5207xw%28VS.100%29.aspx)
+type in Microsoft's
+[Debug Interface Access (DIA)](https://msdn.microsoft.com/en-us/library/x93ctkx8%28VS.100%29.aspx)
+API. Breakpad uses only records of type 4 (`FrameTypeFrameData`) and 0
 (`FrameTypeFPO`); it ignores others. These types differ only in whether the last
 field is an _allocates\_base\_pointer_ flag (`FrameTypeFPO`) or a program string
 (`FrameTypeFrameData`). If more than one record covers a given address, Breakpad
 prefers `FrameTypeFrameData` records over `FrameTypeFPO` records.
 
 The _rva_ and _code\_size_ fields give the starting address and length in bytes
 of the machine code covered by this record. The starting address is relative to
 the module's load address.
 
 The _prologue\_size_ and _epilogue\_size_ fields give the length, in bytes, of
@@ skipping 52 matching lines @@
             (given by the debugging info for B) along with the size of A's
             register save area and local variable area (given by the debugging
             info for A) when computing the overall size of A's frame.)
     *   If _allocates\_base\_pointer_ is false, then F's function doesn't use
         `%ebp` at all. You may recover the calling frame as above, except that
         the caller's value of `%ebp` is the same as F's value for `%ebp`, so no
         steps are necessary to recover it.
 *   If the _has\_program\_string_ field of a `STACK WIN` record is not zero,
     then the record's final field is a string containing a program to be
     interpreted to recover the caller's frame. The comments in the
-    [postfix\_evaluator.h]
-    (http://code.google.com/p/google-breakpad/source/browse/trunk/src/processor/postfix_evaluator.h#40)
+    [postfix\_evaluator.h](/src/processor/postfix_evaluator.h#40)
     header file explain the language in which the program is written. You should
     place the following variables in the dictionary before interpreting the
     program:
     *   `$ebp` and `$esp` should be the values of the `%ebp` and `%esp`
         registers in F.
     *   `.cbParams`, `.cbSavedRegs`, and `.cbLocals`, should be the values of
         the `STACK WIN` record's _parameter\_size_, _saved\_register\_size_, and
         _local\_size_ fields.
     *   `.raSearchStart` should be set to the address on the stack to begin
         scanning for a return address, if necessary. The Breakpad processor sets
@@ skipping 91 matching lines @@
              ...                     ; stuff that doesn't affect stack
 func+10:     sp -= 4; *sp = x        ; push some 4-byte x on the stack
              ...                     ; stuff that doesn't affect stack
 func+20:     r0 = sp[16]             ; restore saved r0
 func+21:     sp += 20                ; pop whole stack frame
 func+22:     pc = *sp; sp += 4       ; pop return address and jump to it
 ```
 
 The following table would describe the function above:
 
-**code address** | **.cfa** | **r0 (on Google Code)** | **r1 (on Google Code)** | ... | **.ra**
-:--------------- | :------- | :---------------------- | :---------------------- | :-- | :-------
-func+0           | sp       |                         |                         |     | `cfa[0]`
-func+1           | sp+16    |                         |                         |     | `cfa[0]`
-func+2           | sp+16    | `cfa[-4]`               |                         |     | `cfa[0]`
-func+11          | sp+20    | `cfa[-4]`               |                         |     | `cfa[0]`
-func+21          | sp+20    |                         |                         |     | `cfa[0]`
-func+22          | sp       |                         |                         |     | `cfa[0]`
+| **code address** | **.cfa** | **r0 (on Google Code)** | **r1 (on Google Code)** | ... | **.ra**  |
+|:-----------------|:---------|:------------------------|:------------------------|:----|:---------|
+| func+0           | sp       |                         |                         |     | `cfa[0]` |
+| func+1           | sp+16    |                         |                         |     | `cfa[0]` |
+| func+2           | sp+16    | `cfa[-4]`               |                         |     | `cfa[0]` |
+| func+11          | sp+20    | `cfa[-4]`               |                         |     | `cfa[0]` |
+| func+21          | sp+20    |                         |                         |     | `cfa[0]` |
+| func+22          | sp       |                         |                         |     | `cfa[0]` |
 
 Some things to note here:
 
 *   Each row describes the state of affairs **before** executing the instruction
     at the given address. Thus, the row for func+0 describes the state before we
     execute the first instruction, which allocates the stack frame. In the next
     row, the formula for computing the CFA has changed, reflecting the
     allocation.
 
 *   The other entries are written in terms of the CFA; this allows them to
@@ skipping 14 matching lines @@
     it? At some fixed point within the frame? --- is a question of definition
     that depends on the architecture and ABI in use. But by definition, the CFA
     remains constant throughout the lifetime of the frame. It's up to
     architecture- specific code to know what significance to assign the CFA, if
     any.
 
 To save space, the most common type of CFI record only mentions the table
 entries at which changes take place. So for the above, the CFI data would only
 actually mention the non-blank entries here:
 
-**insn** | **cfa** | **r0 (on Google Code)** | **r1 (on Google Code)** | ... | **ra**
-:------- | :------ | :---------------------- | :---------------------- | :-- | :-------
-func+0   | sp      |                         |                         |     | `cfa[0]`
-func+1   | sp+16   |                         |                         |     |
-func+2   |         | `cfa[-4]`               |                         |     |
-func+11  | sp+20   |                         |                         |     |
-func+21  |         | r0 (on Google Code)     |                         |     |
-func+22  | sp      |                         |                         |     |
+| **insn** | **cfa** | **r0 (on Google Code)** | **r1 (on Google Code)** | ... | **ra**   |
+|:---------|:--------|:------------------------|:------------------------|:----|:---------|
+| func+0   | sp      |                         |                         |     | `cfa[0]` |
+| func+1   | sp+16   |                         |                         |     | |
+| func+2   |         | `cfa[-4]`               |                         |     | |
+| func+11  | sp+20   |                         |                         |     | |
+| func+21  |         | r0 (on Google Code)     |                         |     | |
+| func+22  | sp      |                         |                         |     | |
 
 A `STACK CFI INIT` record indicates that, at the machine instruction at
 _address_, belonging to some function, the value that _register<sub>n</sub>_ had
 in that function's caller can be recovered by evaluating
 _expression<sub>n</sub>_. The values of any callee-saves registers not mentioned
 are assumed to be unchanged. (`STACK CFI` records never mention caller-saves
 registers.) These rules apply starting at _address_ and continue up to, but not
 including, the address given in the next `STACK CFI` record. The _size_ field is
 the total number of bytes of machine code covered by this record and any
 subsequent `STACK CFI` records (until the next `STACK CFI INIT` record). The
@@ skipping 38 matching lines @@
 address 0x1000 (relative to the module's load address):
 
 ```
 STACK CFI INIT 1000 .cfa: $sp .ra: .cfa ^
 STACK CFI      1001 .cfa: $sp 16 +
 STACK CFI      1002 $r0: .cfa 4 - ^
 STACK CFI      100b .cfa: $sp 20 +
 STACK CFI      1015 $r0: $r0
 STACK CFI      1016 .cfa: $sp
 ```