further small edits

Author: JimRadigan

docs/cpp/ASAN/asan-building.md

@@ -52,19 +52,31 @@ You can customize address sanitizer functionality compiled into the binaries use
 
 There are smaller tweaks that can be made by setting the environment variable `ASAN_OPTIONS`
 
-## Address Sanitizer Runtimes
+## Address Sanitizer Binaries
 
-This implementation of AddressSanitizer makes use of the Clang ASan runtime libraries. The runtime library version packaged with Visual Studio may contain features that are not yet available in the version packaged with Clang.
+
+This implementation of AddressSanitizer makes use of the Clang ASan runtime libraries. The runtime library version packaged with Visual Studio may contain features that are not yet available in the version packaged with Clang on Windows10.
 
 An overview of the features in this ported version of the Address Sanitizer runtime  runtime is available here: [AddressSanitizer runtime overview](address-sanitizer-runtime.md)
 
-### Static (x86,AMD64)
 
-These would appear on the raw link lines 
+### Linking – With static CRT 
+
+Link the EXE with  
+
+- set _LINK_= /debug -incremental:no /wholearchive:%MyVS%\lib\{arch}\clang_rt.asan-{arch}.lib 
+/wholearchive:%MyVS%\lib\{arch}\clang_rt.asan_cxx-{arch}.lib 
+
+Link the DLL with 
+
+- set _LINK_= /debug -incremental:no /wholearchive:%MyVS%\lib\{arch}\clang_rt.asan_dll_thunk-{arch}.lib
+
+### Linking – With dynamic CRT 
+
+Link both the EXE and DLL with: 
 
-### Dynamic (x86,AMD64)
+- set _LINK_= /debug -incremental:no /wholearchive:%MyVS%\lib\{arch}\clang_rt.asan_dynamic-{arch}.lib      /wholearchive:%MyVS%\lib\{arch}\clang_rt.asan_dynamic_runtime_thunk-{arch}.lib 
 
-These would appear on the raw link lines
 
 ## Visual Studio
 

docs/cpp/ASAN/asan-shadowbytes.md

@@ -1,7 +1,7 @@
 # Shadow bytes
 
-We summarize the runtime implementation of `-fsanitize=address`. For futher details we refer you to the [seminal paper](
-https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf).
+We briefly summarize the concept of shadow bytes and how they can be used by the runtime implementation of `-fsanitize=address`. For further details we refer you to the [seminal paper](
+https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf). 
 
 ## Core concept
 
@@ -11,7 +11,7 @@ The shadow-byte describes how many bytes in the 8-byte user address are currentl
 
  - 0  means all 8 bytes
  - 1-7 means 1 to seven bytes
- - Negtive numbers encode context for the runtime to diagnose
+ - Negtive numbers encode context for the runtime to use for reporting diagnostics. 
 
 Consider this shadow byte legend:
 
@@ -20,7 +20,7 @@ Consider this shadow byte legend:
 
 ## Mapping
 
-Every 8-byte address that is 0 mod 8 aligned, can be mapped to the shadow byte that describes that slot in the virtual address space.  This mapping can be accomplished with a simple shift and add.
+Every 8-byte address that is 0 mod 8 aligned, can be mapped to the shadow byte that describes that slot in the virtual address space.  This mapping can be accomplished with a **simple shift and add**.
 
 On x86:
 
@@ -30,8 +30,7 @@ On amd64:
 
             char shadow_byte_value = *((Your_Address >> 3) + _asan_runtime_assigned_offset)
 
-
-## Code generation 
+## Code generation - tests 
 
 Assume that specific shadow bytes will have been written, either by the compiler generated code, static data, or the runtime.  Then the following pseudo code shows how it would be simple to generate a check which would precede any load or store.
 
@@ -53,8 +52,12 @@ When instrumenting 1-, 2-, or 4- byte accesses, the instrumentation is slightly
 
 The runtime and the compiler generated code, will write shadow bytes to allow or revoke access when scopes end or storage is freed. Thus the checks above, are reading shadow bytes describing 8-byte slots in your application space, **at a certain time in the programs execution**.
 
-## See Also
+In addition to these explicitly generated checks the runtime will check shadow bytes after it "intercepts or hooks" many functions in the CRT.  See [the list of intercepted functions](#address-sanitizer-intercepted-functions.md)
 
-The Address Sanitizer [algorithm](https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm) for further details.
+## Setting shadow bytes
 
+Both the code the compiler generates and and the Address Sanitizer runtime can write shadow bytes. For example the compiler can set shadow bytes to allow fixed sized access to stack locals defined in an inner scope.  The runtime can surround global variables in the data section with shadow bytes.
 
+## See Also
+
+The Address Sanitizer [algorithm](https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm) for further details.

docs/cpp/ASAN/asan-top-level.md

@@ -44,7 +44,8 @@ Microsoft recommends using the Address Sanitizer in these **three standard workf
 
 This MSDN article will cover all the information needed to enable your builds for any of the three workflows listed above. The information will be specific to the Microsoft Windows 10 platform and supplement existing documentation from [Google, Apple and GCC](#Google,-Apple-and-GCC-documentation). We start with a simple command line use of the compiler and linker.
 
-> [!NOTE] Current support is limited to x86 and AMD64 on Windows10. **Customer feedback** would help us prioritize shipping these sanitizers in the future: -fsanitize=thread, -fsanitize=leak, -fsanitize=memory, -fsanitize=hwaddress or -fsanitize=undefined.
+> [!NOTE] Current support is limited to x86 and AMD64 on Windows 10. **Customer feedback** would help us prioritize shipping these sanitizers in the future: -fsanitize=thread, -fsanitize=leak, -fsanitize=memory, -fsanitize=hwaddress or -fsanitize=undefined.
+
 
 ## Simple command line interface
 
@@ -121,7 +122,7 @@ From top to bottom
 
 4.) The [**shadow bytes**](.\asan-shadowbytes.md) that correspond to the address used in the overflowing store, indicate 13 bytes (8 + 5) were explicitly allocated for the alloca.
 
-**Note:**  The call stack is converted to function names through the [LLVM symbolizer](https://llvm.org/docs/CommandGuide/llvm-symbolizer.html). The Address Sanitizer creates the resto of the report based on its context, the shadow bytes, and meta-data the compiler produces.
+**Note:**  The call stack is converted to function names through the [LLVM symbolizer](https://llvm.org/docs/CommandGuide/llvm-symbolizer.html). The Address Sanitizer creates the rest of of the report based on its context, the shadow bytes, and meta-data the compiler produces.
 
 ### IDE