aboutsummaryrefslogtreecommitdiff
path: root/docs/processor_design.md
diff options
context:
space:
mode:
authorOrgad Shaneh <orgads@gmail.com>2016-11-15 15:06:22 +0200
committerMike Frysinger <vapier@chromium.org>2016-11-18 17:24:37 +0000
commit11d7510c0889aeff1eadbda1a9c83d9b493f69fe (patch)
tree999539944983c027d1174131eb03a2453b513b15 /docs/processor_design.md
parentGitIgnore: Add dump_syms_mac (diff)
downloadbreakpad-11d7510c0889aeff1eadbda1a9c83d9b493f69fe.tar.xz
Update links
code.google.com is obsolete. Fix all broken markdown links while at it. Change-Id: I6a337bf4b84eacd5f5c749a4ee61331553279009 Reviewed-on: https://chromium-review.googlesource.com/411800 Reviewed-by: Mike Frysinger <vapier@chromium.org>
Diffstat (limited to 'docs/processor_design.md')
-rw-r--r--docs/processor_design.md23
1 files changed, 12 insertions, 11 deletions
diff --git a/docs/processor_design.md b/docs/processor_design.md
index c2af41a1..7b9f244d 100644
--- a/docs/processor_design.md
+++ b/docs/processor_design.md
@@ -13,8 +13,9 @@ The Breakpad processor is intended to sit at the core of a comprehensive
crash-reporting system that does not require debugging information to be
provided to those running applications being monitored. Some existing
crash-reporting systems, such as [GNOME](http://www.gnome.org/)’s Bug-Buddy and
-[Apple](http://www.apple.com/)’s [CrashReporter]
-(http://developer.apple.com/technotes/tn2004/tn2123.html), require symbolic
+[Apple](http://www.apple.com/)’s
+[CrashReporter](http://developer.apple.com/technotes/tn2004/tn2123.html),
+require symbolic
information to be present on the end user’s computer; in the case of
CrashReporter, the reports are transmitted only to Apple, not to third-party
developers. Other systems, such as [Microsoft](http://www.microsoft.com/)’s
@@ -81,13 +82,12 @@ set to produce dumps at any time a developer deems appropriate. The Breakpad
processor can handle dumps in the minidump format, either generated by an
[Breakpad client “handler”](client_design.md) implementation, or by another
implementation that produces dumps in this format. The
-[DbgHelp.dll!MiniDumpWriteDump]
-(http://msdn2.microsoft.com/en-us/library/ms680360.aspx) function on Windows
+[DbgHelp.dll!MiniDumpWriteDump](http://msdn2.microsoft.com/en-us/library/ms680360.aspx)
+function on Windows
produces dumps in this format, and is the basis for the Breakpad handler
implementation on that platform.
-The [minidump format]
-(http://msdn.microsoft.com/en-us/library/ms679293%28VS.85%29.aspx) is
+The [minidump format](http://msdn.microsoft.com/en-us/library/ms679293%28VS.85%29.aspx) is
essentially a simple container format, organized as a series of streams. Each
stream contains some type of data relevant to the crash. A typical “normal”
minidump contains streams for the thread list, the module list, the CPU context
@@ -155,11 +155,12 @@ storage needs.
Breakpad’s symbol file format is text-based, and was defined to be fairly
human-readable and to encompass the needs of multiple platforms. The Breakpad
-processor itself does not operate directly with native symbol formats ([DWARF]
-(http://dwarf.freestandards.org/) and [STABS]
-(http://sourceware.org/gdb/current/onlinedocs/stabs.html) on most Unix-like
-systems, [.pdb files]
-(http://msdn2.microsoft.com/en-us/library/yd4f8bd1(VS.80).aspx) on Windows),
+processor itself does not operate directly with native symbol formats
+([DWARF](http://dwarf.freestandards.org/) and
+[STABS](http://sourceware.org/gdb/current/onlinedocs/stabs.html)
+on most Unix-like systems,
+[.pdb files](http://msdn2.microsoft.com/en-us/library/yd4f8bd1(VS.80).aspx)
+on Windows),
because of the complications in accessing potentially complex symbol formats
with slight variations between platforms, stored within different types of
binary formats. In the case of `.pdb` files, the debugging format is not even