diff -r f0fbc6071d7e Doc/howto/instrumentation.rst
--- a/Doc/howto/instrumentation.rst	Sat Oct 29 10:50:00 2016 +0300
+++ b/Doc/howto/instrumentation.rst	Sat Oct 29 14:38:26 2016 +0200
@@ -20,9 +20,6 @@
 making it easier to monitor what the CPython processes on a system are
 doing.
 
-.. I'm using ".. code-block:: c" for SystemTap scripts, as "c" is syntactically
-   the closest match that Sphinx supports
-
 .. impl-detail::
 
    DTrace markers are implementation details of the CPython interpreter.
@@ -47,13 +44,17 @@
    sudo apt-get install systemtap-sdt-dev
 
 
-CPython must then be configured `--with-dtrace`::
+CPython must then be configured ``--with-dtrace``:
+
+.. code-block:: none
 
    checking for --with-dtrace... yes
 
 On macOS, you can list available DTrace probes by running a Python
 process in the background and listing all probes made available by the
-Python provider::
+Python provider:
+
+.. code-block:: shell-session
 
    $ python3.6 -q &
    $ sudo dtrace -l -P python$!  # or: dtrace -l -m python3.6
@@ -71,7 +72,7 @@
 On Linux, you can verify if the SystemTap static markers are present in
 the built binary by seeing if it contains a ".note.stapsdt" section.
 
-.. code-block:: bash
+.. code-block:: shell-session
 
    $ readelf -S ./python | grep .note.stapsdt
    [30] .note.stapsdt        NOTE         0000000000000000 00308d78
@@ -79,14 +80,14 @@
 If you've built Python as a shared library (with --enable-shared), you
 need to look instead within the shared library.  For example:
 
-.. code-block:: bash
+.. code-block:: shell-session
 
    $ readelf -S libpython3.3dm.so.1.0 | grep .note.stapsdt
    [29] .note.stapsdt        NOTE         0000000000000000 00365b68
 
 Sufficiently modern readelf can print the metadata:
 
-.. code-block:: bash
+.. code-block:: shell-session
 
     $ readelf -n ./python
 
@@ -136,7 +137,7 @@
 a function called "start". In other words, import-time function
 invocations are not going to be listed:
 
-.. code-block:: c
+.. code-block:: none
 
     self int indent;
 
@@ -172,11 +173,13 @@
 
 It can be invoked like this:
 
-.. code-block:: bash
+.. code-block:: shell-session
 
   $ sudo dtrace -q -s call_stack.d -c "python3.6 script.py"
 
-The output looks like this::
+The output looks like this:
+
+.. code-block:: none
 
     156641360502280  function-entry:call_stack.py:start:23
     156641360518804  function-entry: call_stack.py:function_1:1
@@ -208,7 +211,7 @@
 For example, this SystemTap script can be used to show the call/return
 hierarchy of a Python script:
 
-.. code-block:: c
+.. code-block:: none
 
    probe process("python").mark("function__entry") {
         filename = user_string($arg1);
@@ -230,13 +233,15 @@
 
 It can be invoked like this:
 
-.. code-block:: bash
+.. code-block:: shell-session
 
    $ stap \
      show-call-hierarchy.stp \
      -c "./python test.py"
 
-The output looks like this::
+The output looks like this:
+
+.. code-block:: none
 
    11408 python(8274):        => __contains__ in Lib/_abcoll.py:362
    11414 python(8274):         => __getitem__ in Lib/os.py:425
@@ -325,7 +330,7 @@
 
 Here is a tapset file, based on a non-shared build of CPython:
 
-.. code-block:: c
+.. code-block:: none
 
     /*
        Provide a higher-level wrapping around the function__entry and
@@ -369,7 +374,7 @@
 example given above of tracing the Python function-call hierarchy, without
 needing to directly name the static markers:
 
-.. code-block:: c
+.. code-block:: none
 
     probe python.function.entry
     {
@@ -388,7 +393,7 @@
 running CPython code, showing the top 20 most frequently-entered bytecode
 frames, each second, across the whole system:
 
-.. code-block:: c
+.. code-block:: none
 
     global fn_calls;