[Docs] fixes

docs/linux_debugging.md

 # Tips for debugging on Linux
 
 This page is for Chromium-specific debugging tips; learning how to run gdb is
 out of scope.
 
 [TOC]
 
 ## Symbolized stack trace
 
 The sandbox can interfere with the internal symbolizer. Use `--no-sandbox` (but
 keep this temporary) or an external symbolizer (see
 `tools/valgrind/asan/asan_symbolize.py`).
 
 Generally, do not use `--no-sandbox` on waterfall bots, sandbox testing is
 needed. Talk to security@chromium.org.
 
 ## GDB
 
-**GDB-7.7 is required in order to debug Chrome on Linux.**
+*** promo
+GDB-7.7 is required in order to debug Chrome on Linux.
+***
 
 Any prior version will fail to resolve symbols or segfault.
 
 ### Basic browser process debugging
 
     gdb -tui -ex=r --args out/Debug/chrome --disable-seccomp-sandbox \
         http://google.com
 
 ### Allowing attaching to foreign processes
 
@@ skipping 22 matching lines @@
 ```
 
 The `--no-sandbox` flag is needed because otherwise the seccomp sandbox will
 kill the renderer process on startup, or the setuid sandbox will prevent xterm's
 execution.  The "xterm" is necessary or gdb will run in the current terminal,
 which can get particularly confusing since it's running in the background, and
 if you're also running the main process in gdb, won't work at all (the two
 instances will fight over the terminal). To auto-start the renderers in the
 debugger, send the "run" command to the debugger:
 
-    chrome --no-sandbox --renderer-cmd-prefix='xterm -title renderer -e gdb -ex \
-        run --args
+    chrome --no-sandbox --renderer-cmd-prefix='xterm -title renderer -e gdb \
+        -ex run --args
 
 If you're using Emacs and `M-x gdb`, you can do
 
     chrome "--renderer-cmd-prefix=gdb --args"
 
+*** note
 Note: using the `--renderer-cmd-prefix` option bypasses the zygote launcher, so
 the renderers won't be sandboxed. It is generally not an issue, except when you
 are trying to debug interactions with the sandbox. If that's what you are doing,
 you will need to attach your debugger to a running renderer process (see below).
+***
 
 You may also want to pass `--disable-hang-monitor` to suppress the hang monitor,
 which is rather annoying.
 
 You can also use `--renderer-startup-dialog` and attach to the process in order
 to debug the renderer code. Go to
 http://www.chromium.org/blink/getting-started-with-blink-debugging for more
 information on how this can be done.
 
 #### Choosing which renderers to debug
@@ skipping 87 matching lines @@
 BROWSER_WRAPPER='xterm -title renderer -e gdb --eval-command=run \
     --eval-command=quit --args' out/Debug/browser_tests --gtest_filter=Print
 ```
 
 #### Plugin Processes
 
 Same strategies as renderers above, but the flag is called `--plugin-launcher`:
 
     chrome --plugin-launcher='xterm -e gdb --args'
 
-_Note: For now, this does not currently apply to PPAPI plugins because they
-currently run in the renderer process._
+*** note
+Note: For now, this does not currently apply to PPAPI plugins because they
+currently run in the renderer process.
+***
 
 #### Single-Process mode
 
 Depending on whether it's relevant to the problem, it's often easier to just run
 in "single process" mode where the renderer threads are in-process. Then you can
 just run gdb on the main process.
 
     gdb --args chrome --single-process
 
 Currently, the `--disable-gpu` flag is also required, as there are known crashes
@@ skipping 58 matching lines @@
 The following link describes a tool that can be used on Linux, Windows and Mac under GDB.
 
 [graphical_debugging_aid_chromium_views](graphical_debugging_aid_chromium_views.md)
 
 ### Faster startup
 
 Use the `gdb-add-index` script (e.g.
 `build/gdb-add-index out/Debug/browser_tests`)
 
 Only makes sense if you run the binary multiple times or maybe if you use the
-component build since most .so files won't require reindexing on a rebuild.
+component build since most `.so` files won't require reindexing on a rebuild.
 
 See
 https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-dev/gdb-add-index/chromium-dev/ELRuj1BDCL4/5Ki4LGx41CcJ
 for more info.
 
 Alternatively, specify:
 
     linux_use_debug_fission=0
 
 in `GYP_DEFINES`. This improves load time of gdb significantly at the cost of
@@ skipping 86 matching lines @@
 
 You can look at a snapshot of the output by:
 
     xwd -display :6.0 -root | xwud
 
 Alternatively, you can use testing/xvfb.py to set up your environment for you:
 
     testing/xvfb.py out/Debug out/Debug/browser_tests \
         --gtest_filter="MyBrowserTest.MyActivateWindowTest"
 
-### `BROWSER_WRAPPER`
+### BROWSER_WRAPPER
 
 You can also get the browser under a debugger by setting the `BROWSER_WRAPPER`
 environment variable.  (You can use this for `browser_tests` too, but see above
 for discussion of a simpler way.)
 
     BROWSER_WRAPPER='xterm -e gdb --args' out/Debug/browser_tests
 
 ### Replicating Trybot Slowness
 
 Trybots are pretty stressed, and can sometimes expose timing issues you can't
 normally reproduce locally.
 
 You can simulate this by shutting down all but one of the CPUs
 (http://www.cyberciti.biz/faq/debian-rhel-centos-redhat-suse-hotplug-cpu/) and
 running a CPU loading tool (e.g., http://www.devin.com/lookbusy/). Now run your
 test. It will run slowly, but any flakiness found by the trybot should replicate
 locally now - and often nearly 100% of the time.
 
 ## Logging
 
 ### Seeing all LOG(foo) messages
 
 Default log level hides `LOG(INFO)`. Run with `--log-level=0` and
 `--enable-logging=stderr` flags.
 
 Newer versions of chromium with VLOG may need --v=1 too. For more VLOG tips, see
-the chromium-dev thread:
-http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/dcd0cd7752b35de6?pli=1
+[the chromium-dev thread](http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/dcd0cd7752b35de6?pli=1).
 
 ### Seeing IPC debug messages
 
 Run with `CHROME_IPC_LOGGING=1` eg.
 
     CHROME_IPC_LOGGING=1 out/Debug/chrome
 
 or within gdb:
 
     set environment CHROME_IPC_LOGGING 1
 
 If some messages show as unknown, check if the list of IPC message headers in
-`chrome/common/logging_chrome.cc` is up-to-date. In case this file reference
-goes out of date, try looking for usage of macros like `IPC_MESSAGE_LOG_ENABLED`
-or `IPC_MESSAGE_MACROS_LOG_ENABLED`.
+[chrome/common/logging_chrome.cc](/chrome/common/logging_chrome.cc) is
+up-to-date. In case this file reference goes out of date, try looking for usage
+of macros like `IPC_MESSAGE_LOG_ENABLED` or `IPC_MESSAGE_MACROS_LOG_ENABLED`.
 
 ## Using valgrind
 
 To run valgrind on the browser and renderer processes, with our suppression file
 and flags:
 
     $ cd $CHROMIUM_ROOT/src
     $ tools/valgrind/valgrind.sh out/Debug/chrome
 
 You can use valgrind on chrome and/or on the renderers e.g
@@ skipping 41 matching lines @@
     sudo apt-get install language-pack-ar language-pack-he \
         language-pack-gnome-ar language-pack-gnome-he
 
 Note that the `--lang` flag does **not** work properly for this.
 
 On non-Debian systems, you need the `gtk20.mo` files. (Please update these docs
 with the appropriate instructions if you know what they are.)
 
 ## Breakpad
 
-See the last section of [linux_crash_dumping.md](linux_crash_dumping.md); you
+See the last section of [Linux Crash Dumping](linux_crash_dumping.md); you
 need to set a gyp variable and an environment variable for the crash dump tests
 to work.
 
 ## Drag and Drop
 
 If you break in a debugger during a drag, Chrome will have grabbed your mouse
 and keyboard so you won't be able to interact with the debugger!  To work around
 this, run via `Xephyr`. Instructions for how to use `Xephyr` are on the
-[layout_tests_linux.md](layout_tests_linux.md) page.
+[Running layout tests on Linux](layout_tests_linux.md) page.
 
 ## Tracking Down Bugs
 
 ### Isolating Regressions
 
 Old builds are archived here:
 http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/
+(TODO: does not exist).
 
 `tools/bisect-builds.py` in the tree automates bisecting through the archived
 builds. Despite a computer science education, I am still amazed how quickly
 binary search will find its target.
 
 ### Screen recording for bug reports
 
     sudo apt-get install gtk-recordmydesktop
 
 ## Version-specific issues
@@ skipping 27 matching lines @@
 Some strategies are:
 
 *   pass `--sync` on the command line to make all X calls synchronous
 *   run chrome via [xtrace](http://xtrace.alioth.debian.org/)
 *   turn on IPC debugging (see above section)
 
 ### Window Managers
 
 To test on various window managers, you can use a nested X server like `Xephyr`.
 Instructions for how to use `Xephyr` are on the
-[layout_tests_linux.md](layout_tests_linux.md) page.
+[Running layout tests on Linux](layout_tests_linux.md) page.
 
 If you need to test something with hardware accelerated compositing
 (e.g., compiz), you can use `Xgl` (`sudo apt-get install xserver-xgl`). E.g.:
 
     Xgl :1 -ac -accel glx:pbuffer -accel xv:pbuffer -screen 1024x768
 
 ## Mozilla Tips
 
 https://developer.mozilla.org/en/Debugging_Mozilla_on_Linux_FAQ