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>

6 files changed, 61 insertions, 86 deletions

diff --git a/docs/client_design.md b/docs/client_design.md
index 30ffb2fb..9f85655d 100644
--- a/docs/client_design.md
+++ b/docs/client_design.md
@@ -69,8 +69,8 @@ amount of work from a crashed process.
 
 The mechanisms for installing an exception handler vary between operating
 systems. On Windows, it’s a relatively simple matter of making one call to
-register a [top-level exception filter]
-(http://msdn.microsoft.com/library/en-us/debug/base/setunhandledexceptionfilter.asp)
+register a [top-level exception
+filter](http://msdn.microsoft.com/library/en-us/debug/base/setunhandledexceptionfilter.asp)
 callback function. On most Unix-like systems such as Linux, processes are
 informed of exceptions by the delivery of a signal, so an exception handler
 takes the form of a signal handler. The native mechanism to catch exceptions on
@@ -178,9 +178,8 @@ didn’t actually handle an exception. This function may be useful for developer
 who want to test their applications with Breakpad enabled but still retain the
 ability to use traditional debugging techniques. It also allows a
 Breakpad-enabled application to coexist with a platform’s native crash reporting
-system, such as Mac OS X’ [CrashReporter]
-(http://developer.apple.com/technotes/tn2004/tn2123.html) and [Windows Error
-Reporting](http://msdn.microsoft.com/isv/resources/wer/).
+system, such as Mac OS X’ [CrashReporter](http://developer.apple.com/technotes/tn2004/tn2123.html)
+and [Windows Error Reporting](http://msdn.microsoft.com/isv/resources/wer/).
 
 Typically, when Breakpad handles an exception fully and no debuggers are
 involved, the crashed process will terminate.
diff --git a/docs/getting_started_with_breakpad.md b/docs/getting_started_with_breakpad.md
index a41b5406..b827d401 100644
--- a/docs/getting_started_with_breakpad.md
+++ b/docs/getting_started_with_breakpad.md
@@ -9,8 +9,7 @@ minidumps on request for programs that have not crashed.
 Breakpad is currently used by Google Chrome, Firefox, Google Picasa, Camino,
 Google Earth, and other projects.
 
-![http://google-breakpad.googlecode.com/svn/wiki/breakpad.png]
-(http://google-breakpad.googlecode.com/svn/wiki/breakpad.png)
+![Workflow](breakpad.png)
 
 Breakpad has three main components:
 
@@ -90,7 +89,7 @@ known as "out-of-process" exception handling.
 ## Breakpad Code Overview
 
 All the client-side code is found by visiting the Google Project at
-http://code.google.com/p/google-breakpad. The following directory structure is
+https://chromium.googlesource.com/breakpad/breakpad. The following directory structure is
 present in the `src` directory:
 
 *   `processor` Contains minidump-processing code that is used on the server
@@ -101,14 +100,9 @@ present in the `src` directory:
 
 (Among other directories)
 
-*   <a
-    href='http://code.google.com/p/google-breakpad/wiki/WindowsClientIntegration'>Windows
-    Integration Guide</a>
-*   <a
-    href='http://code.google.com/p/google-breakpad/wiki/MacBreakpadStarterGuide'>Mac
-    Integration Guide</a>
-*   <a href='http://code.google.com/p/google-breakpad/wiki/LinuxStarterGuide'>
-    Linux Integration Guide</a>
+*   [Windows Integration Guide](windows_client_integration.md)
+*   [Mac Integration Guide](mac_breakpad_starter_guide.md)
+*   [Linux Integration Guide](linux_starter_guide.md)
 
 ## Build process specifics(symbol generation)
 
diff --git a/docs/mozilla_brown_bag_talk.md b/docs/mozilla_brown_bag_talk.md
index 8322d244..82461b3d 100644
--- a/docs/mozilla_brown_bag_talk.md
+++ b/docs/mozilla_brown_bag_talk.md
@@ -75,10 +75,8 @@
 
 ## More Information
 
-*   Project home: http://code.google.com/p/google-breakpad/
+*   Project home: https://chromium.googlesource.com/breakpad/breakpad
 *   Mailing lists
-    *   [google-breakpad-dev@googlegroups.com]
-        (http://groups.google.com/group/google-breakpad-dev/)
-    *   [google-breakpad-discuss@googlegroups.com]
-        (http://groups.google.com/group/google-breakpad-discuss/)
+    *   [google-breakpad-dev@googlegroups.com](http://groups.google.com/group/google-breakpad-dev/)
+    *   [google-breakpad-discuss@googlegroups.com](http://groups.google.com/group/google-breakpad-discuss/)
 *   Ask me (irc.mozilla.org: mento)
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
diff --git a/docs/stack_walking.md b/docs/stack_walking.md
index c74f22d4..94111594 100644
--- a/docs/stack_walking.md
+++ b/docs/stack_walking.md
@@ -8,16 +8,12 @@ traces from the information contained within a minidump file.
 ## Starting the Process
 
 Typically the stack walking process is initiated by instantiating the
-[MinidumpProcessor]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/processor/minidump_processor.cc)
-class and calling the [MinidumpProcessor::Process]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/processor/minidump_processor.cc#61)
+[MinidumpProcessor](../src/processor/minidump_processor.cc)
+class and calling the [MinidumpProcessor::Process](../src/processor/minidump_processor.cc#61)
 method, providing it a minidump file to process. To produce a useful stack
 trace, the MinidumpProcessor requires two other objects which are passed in its
-constructor: a [SymbolSupplier]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/symbol_supplier.h)
-and a [SourceLineResolverInterface]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/source_line_resolver_interface.h).
+constructor: a [SymbolSupplier](../src/google_breakpad/processor/symbol_supplier.h)
+and a [SourceLineResolverInterface](../src/google_breakpad/processor/source_line_resolver_interface.h).
 The SymbolSupplier object is responsible for locating and providing SymbolFiles
 that match modules from the minidump. The SourceLineResolverInterface is
 responsible for loading the symbol files and using the information contained
@@ -26,29 +22,26 @@ information on how to unwind from a stack frame to its caller. More detail will
 be provided on these interactions later.
 
 A number of data streams are extracted from the minidump to begin stack walking:
-the list of threads from the process ([MinidumpThreadList]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/minidump.h#335)),
-the list of modules loaded in the process ([MinidumpModuleList]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/minidump.h#501)),
+the list of threads from the process
+([MinidumpThreadList](../src/google_breakpad/processor/minidump.h#335)),
+the list of modules loaded in the process
+([MinidumpModuleList](../src/google_breakpad/processor/minidump.h#501)),
 and information about the exception that caused the process to crash
-([MinidumpException]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/minidump.h#615)).
+([MinidumpException](../src/google_breakpad/processor/minidump.h#615)).
 
 ## Enumerating Threads
 
-For each thread in the thread list ([MinidumpThread]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/minidump.h#299)),
-the thread memory containing the stack for the thread ([MinidumpMemoryRegion]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/minidump.h#236))
+For each thread in the thread list
+([MinidumpThread](../src/google_breakpad/processor/minidump.h#299)),
+the thread memory containing the stack for the thread
+([MinidumpMemoryRegion](../src/google_breakpad/processor/minidump.h#236))
 and the CPU context representing the CPU state of the thread at the time the
-dump was written ([MinidumpContext]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/minidump.h#171))
+dump was written ([MinidumpContext](../src/google_breakpad/processor/minidump.h#171))
 are extracted from the minidump. If the thread being processed is the thread
 that produced the exception then a CPU context is obtained from the
 MinidumpException object instead, which represents the CPU state of the thread
 at the point of the exception. A stack walker is then instantiated by calling
-the [Stackwalker::StackwalkerForCPU]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/stackwalker.h#77)
+the [Stackwalker::StackwalkerForCPU](../src/google_breakpad/processor/stackwalker.h#77)
 method and passing it the CPU context, the thread memory, the module list, as
 well as the SymbolSupplier and SourceLineResolverInterface. This method selects
 the specific !Stackwalker subclass based on the CPU architecture of the provided
@@ -57,8 +50,7 @@ CPU context and returns an instance of that subclass.
 ## Walking a thread's stack
 
 Once a !Stackwalker instance has been obtained, the processor calls the
-[Stackwalker::Walk]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/source_line_resolver_interface.h)
+[Stackwalker::Walk](../src/google_breakpad/processor/source_line_resolver_interface.h)
 method to obtain a list of frames representing the stack of this thread. The
 !Stackwalker starts by calling the GetContextFrame method which returns a
 StackFrame representing the top of the stack, with CPU state provided by the
@@ -69,28 +61,24 @@ for each frame in turn:
 
 The address of the instruction pointer of the current frame is used to determine
 which module contains the current frame by calling the module list's
-[GetModuleForAddress]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/code_modules.h#56)
-method.
+[GetModuleForAddress](../src/google_breakpad/processor/code_modules.h#56) method.
 
 ### Locating Symbols
 
 If a module is located, the SymbolSupplier is asked to locate symbols
-corresponding to the module by calling its [GetCStringSymbolData]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/symbol_supplier.h#87)
+corresponding to the module by calling its
+[GetCStringSymbolData](../src/google_breakpad/processor/symbol_supplier.h#87)
 method. Typically this is implemented by using the module's debug filename (the
 PDB filename for Windows dumps) and debug identifier (a GUID plus one extra
-digit) as a lookup key. The [SimpleSymbolSupplier]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/processor/simple_symbol_supplier.cc)
+digit) as a lookup key. The [SimpleSymbolSupplier](../src/processor/simple_symbol_supplier.cc)
 class simply uses these as parts of a file path to locate a flat file on disk.
 
 ### Loading Symbols
 
 If a symbol file is located, the SourceLineResolverInterface is then asked to
-load the symbol file by calling its [LoadModuleUsingMemoryBuffer]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/source_line_resolver_interface.h#71)
-method. The [BasicSourceLineResolver]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/processor/basic_source_line_resolver.cc)
+load the symbol file by calling its
+[LoadModuleUsingMemoryBuffer](../src/google_breakpad/processor/source_line_resolver_interface.h#71)
+method. The [BasicSourceLineResolver](../src/processor/basic_source_line_resolver.cc)
 implementation parses the text-format [symbol file](symbol_files.md) into
 in-memory data structures to make lookups by address of function names, source
 line information, and unwind information easy.
@@ -98,8 +86,7 @@ line information, and unwind information easy.
 ### Getting source line information
 
 If a symbol file has been successfully loaded, the SourceLineResolverInterface's
-[FillSourceLineInfo]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/source_line_resolver_interface.h#89)
+[FillSourceLineInfo](../src/google_breakpad/processor/source_line_resolver_interface.h#89)
 method is called to provide a function name and source line information for the
 current frame. This is done by subtracting the base address of the module
 containing the current frame from the instruction pointer of the current frame
@@ -119,17 +106,15 @@ nearest symbol that is less than the provided RVA.
 
 ### Finding the caller frame
 
-To find the next frame in the stack, the !Stackwalker calls its [GetCallerFrame]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/stackwalker.h#186)
+To find the next frame in the stack, the !Stackwalker calls its
+[GetCallerFrame](../src/google_breakpad/processor/stackwalker.h#186)
 method, passing in the current frame. Each !Stackwalker subclass implements
 GetCallerFrame differently, but there are common patterns.
 
 Typically the first step is to query the SourceLineResolverInterface for the
 presence of detailed unwind information. This is done using its
-[FindWindowsFrameInfo]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/source_line_resolver_interface.h#96)
-and [FindCFIFrameInfo]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/source_line_resolver_interface.h#102)
+[FindWindowsFrameInfo](../src/google_breakpad/processor/source_line_resolver_interface.h#96)
+and [FindCFIFrameInfo](../src/google_breakpad/processor/source_line_resolver_interface.h#102)
 methods. These methods look for Windows unwind info extracted from a PDB file
 ([STACK WIN](SymbolFiles#STACK_WIN_records.md) lines from the symbol file), or
 DWARF CFI extracted from a binary ([STACK CFI](SymbolFiles#STACK_CFI_records.md)
@@ -148,12 +133,11 @@ to produce the caller frame.
 
 If no caller frame was found by any other method most !Stackwalker
 implementations resort to stack scanning by looking at each word on the stack
-down to a fixed depth (implemented in the [Stackwalker::ScanForReturnAddress]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/stackwalker.h#131)
+down to a fixed depth (implemented in the
+[Stackwalker::ScanForReturnAddress](../src/google_breakpad/processor/stackwalker.h#131)
 method) and using a heuristic to attempt to find a reasonable return address
-(implemented in the [Stackwalker::InstructionAddressSeemsValid]
-(http://code.google.com/p/google-breakpad/source/browse/trunk/src/google_breakpad/processor/stackwalker.h#111)
-method).
+(implemented in the
+[Stackwalker::InstructionAddressSeemsValid](../src/google_breakpad/processor/stackwalker.h#111) method).
 
 If no caller frame is found or the caller frame seems invalid, stack walking
 stops. If a caller frame was found then these steps repeat using the new frame
diff --git a/docs/symbol_files.md b/docs/symbol_files.md
index 2fc157fc..90782016 100644
--- a/docs/symbol_files.md
+++ b/docs/symbol_files.md
@@ -197,10 +197,10 @@ 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.
+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
 (`FrameTypeFPO`); it ignores others. These types differ only in whether the last
 field is an _allocates\_base\_pointer_ flag (`FrameTypeFPO`) or a program string
@@ -274,8 +274,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: