From 5b7634fd747fdb5a19c71bc637d4f389bd6e7611 Mon Sep 17 00:00:00 2001
From: Eric Christopher <echristo@apple.com>
Date: Tue, 6 Mar 2012 02:25:41 +0000
Subject: [PATCH] Fix up link and a couple small edits.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152094 91177308-0d34-0410-b5e6-96231b3b80d8
---
 docs/SourceLevelDebugging.html | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/SourceLevelDebugging.html b/docs/SourceLevelDebugging.html
index 8c7ae530f4a..08ac4ee3a87 100644
--- a/docs/SourceLevelDebugging.html
+++ b/docs/SourceLevelDebugging.html
@@ -2131,7 +2131,7 @@ The DWARF for this would be:
 <!-- ======================================================================= -->
 <!-- ======================================================================= -->
 <h4>
-  <a name="acceltableintro">Introduction</a>
+  <a name="acceltableintroduction">Introduction</a>
 </h4>
 <!-- ======================================================================= -->
 <div>
@@ -2292,10 +2292,10 @@ bucket contents:
 `-------------'
 </pre>
 </div>
-<p>The BUCKETS in the Apple tables is an index into the HASHES array. By
+<p>The BUCKETS in the name tables are an index into the HASHES array. By
   making all of the full 32 bit hash values contiguous in memory, we allow
   ourselves to efficiently check for a match while touching as little
-  memory as possible. Most often, checking the 32 bit hash values is as far as
+  memory as possible. Most often checking the 32 bit hash values is as far as
   the lookup goes. If it does match, it usually is a match with no collisions.
   So for a table with "n_buckets" buckets, and "n_hashes" unique 32 bit hash
   values, we can clarify the contents of the BUCKETS, HASHES and OFFSETS as: