Merge pull request #15 from WebAssembly/tooling

Add a tooling section.

2 files changed, 50 insertions, 1 deletions

diff --git a/FutureFeatures.md b/FutureFeatures.md
index 0d2d9d6..30f2e30 100644
--- a/FutureFeatures.md
+++ b/FutureFeatures.md
@@ -7,6 +7,9 @@ of the [Minimum Viable Product](V1.md) or the
 to be standardized immediately after v.1. These will be prioritized based on
 developer feedback.
 
+## Great tooling support
+This is covered in the [tooling](Tooling.md) section.
+
 ## Dynamic linking
  * [Dynamic loading](V1.md#code-loading-and-imports) is in [v.1](V1.md), but all loaded modules have
    their own [separate heaps](V1.md#heap) and cannot share [function pointers](V1.md#function-pointers).
@@ -16,7 +19,7 @@ developer feedback.
 ## Finer-grained control over memory
  * `mmap` of File, `madvise(MADV_DONTNEED)`, ...
  * TODO
- 
+
 ## GC/DOM Integration
  * Access to certain kinds of GC things from variables/arguments/expressions
  * Ability to GC-allocate certain kinds of GC things
@@ -52,3 +55,8 @@ developer feedback.
 ## Platform-independent Just-in-Time compilation
 * TODO
 * Potentially through dynamic loading.
+
+## Multiprocess support
+ * `vfork`.
+ * Inter-process communication.
+ * Inter-process `mmap`.
diff --git a/Tooling.md b/Tooling.md
new file mode 100644
index 0000000..3547a0a
--- /dev/null
+++ b/Tooling.md
@@ -0,0 +1,41 @@
+# Tooling support
+
+Tooling for in-browser execution is often of uneven quality. WebAssembly aims at
+making it possible to support truly great tooling by exposing
+[low-level capabilities][] instead of prescribing which tooling should be
+built. This enables:
+* Porting of existing and familiar tooling to WebAssembly;
+* Building new tooling that's particularly well suited to WebAssembly.
+
+  [low-level capabilities]: https://extensiblewebmanifesto.org
+
+WebAssembly development should be self-hosting, and not just as a cute hack but
+as enjoyable platform that developers actively seek out because the tools they
+want and need *just work*. Developers have high expectations, and meeting these
+expectations on tooling means WebAssembly has the features required to build
+rich applications for non-developers.
+
+The tooling we expect to support includes:
+* Editors:
+  - Editors such as vim and emacs should *just work*.
+* Compilers and language virtual machines:
+  - Compilers for languages which can target WebAssembly (C/C++, Rust, Go, C#)
+    should be able to run in WebAssembly themselves, emit a WebAssembly module
+    that can then be executed.
+  - Virtual machines for languages such as bash, Python, Ruby should work.
+  - Virtual machines which use a just-in-time compiler (JavaScript VMs, luajit,
+    pypy) should be able to support a new just-in-time backend for WebAssembly.
+* Debuggers:
+  - Basic browser integration can be done through source map support.
+  - Full integration for languages like C++ require more standardization effort
+    on debugging information format as well as permissions for interrupting
+    programs, inspecting their state, modifying their state.
+  - Debug information is better delivered on-demand instead of built-in to a
+    WebAssembly module.
+* Sanitizers for non-memory-safe languages: asan, tsan, msan, ubsan.
+* Opt-in security enhancements for developers' own code: developers targeting
+  WebAssembly may want their own code to be sandboxed further than what
+  WebAssembly implementations require to protect users.
+* Profilers:
+  - Sample-based.
+  - Instrumentation-based.