docs/symbol_files.md - Issue 2103273003: docs: clean up markdown

Unified Diff: docs/symbol_files.md

Issue 2103273003: docs: clean up markdown Base URL: https://chromium.googlesource.com/breakpad/breakpad.git@master

Patch Set: Created 4 years, 6 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View side-by-side diff with in-line comments

Index: docs/symbol_files.md

diff --git a/docs/symbol_files.md b/docs/symbol_files.md

index 2fc157fcaa81b80e445b4771a462d7e6847f7253..bdf8b1d07db6abce562eec1c2d9d43bf3c48ee41 100644

--- a/docs/symbol_files.md

+++ b/docs/symbol_files.md

@@ -62,16 +62,25 @@ 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

+ 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

@@ -197,11 +206,11 @@ 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

@@ -274,8 +283,7 @@ follows:

* 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:

@@ -387,14 +395,14 @@ 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:

@@ -429,14 +437,14 @@ 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+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+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

« docs/client_design.md ('K') | « docs/stack_walking.md ('k') | docs/windows_client_integration.md » ('j') | no next file with comments »