Implement a disassembler service.

It is inspired by the idea of Godbolt but with the difference of having
a capability to be used on the actual projects (e.g. on a whole bunch of
different source-code files) and not only on the excerpts of your code
that you have copy-pasted into the Godbolt editor.

This means that this disassembler service does not operate on chunks of
an exemplary code but it operates on an actual binaries your code is
going to produce. What it will do is that it will try to match the symbol
you expressed the interest in on a source-code level, e.g. some function,
against the actual symbols that are present in the resulting binary. It
will do so by disassembling the binary and jumping to the symbol of
interest in the resulting disassembly.

Sometimes a symbol of interest won't even be present in the resulting
binary because it was either optimized out or inlined or sometimes even
merged with some other symbol. This normally happens because of the
compiler and/or linker optimizations and it is inevitable. What can also
happen is that the symbol of interest is not an actual symbol but rather
a meta-symbol such as function template or a class template, and therefore
cannot be present in such a form in a resulting binary.

In both of these cases, disassembly service will instead offer a list
which contains all of the similar symbols that we can jump to. In case
of function/class templates this approach works quite well. But in case
when the symbol is completely missing, we will need to fallback onto
manual heuristics of finding the interesting part of the disassembly.

Not having all the code isolated into a single translation-unit, like we
do in a Godbolt, this service gives us an ability to examine the codegen
on a project level rather than on a single source-code file level. This
is a much tougher challenge for your compiler and linker to solve, and
hence it may/will impact the resulting codegen. Service also provides
flexibility to pick any target (binary) available to your project you
might be interested in (e.g. unit-tests, google-benchmarks, etc.).

Whole service is implemented natively through nm + objdump + libclang
combination, and has no dependencies or whatsoever on Godbolt. It runs
completely locally within the cxxd server.

It also provides the convenience not having to c/p the excerpts into a
Godbolt editor, which may or may not be a sensitive content, or cutting
loose the project-specific dependencies so that you can successfully
compile the excerpt. This is sometimes time-consuming, especially in
large codebases.

To understand the disassembly better, service also provides a documentation
of x86-64 assembly instructions and which can be retrieved by the client
application (e.g. on hovering the mouse over some assembly instruction).
This part is implemented with the help of the script which Godbolt uses
to scrape the documentation from https://www.felixcloutier.com/x86/index.html.
I have tweaked the script to fit the purposes of cxxd better.

There're some disassembly-related knobs that can be tweaked through the
.cxxd_config.json configuration file. These include:
  (1) "targets-filter" - to filter out the uninteresting targets from
      your build directory. E.g. "targets-filter" : [".so", ".a", "CMake"]
  (2) "intermix-with-src-code" - to mix the disassembly with the source
      code. By default it is turned off.
  (3) "syntax" - to select the disassembly syntax. By default it is set
      to intel syntax but can be changed to AT&T if someone wants to.
  (4) "visualize-jumps" - to visualize the branches in disassembled code.
      By default this setting is turned on.
  (5) "binary" - Both nm and objdump custom binaries can be provided
      should there be a reason for it.

E.g.
 "disassembly" : {
        "objdump" : {
            "binary" : "",
            "intermix-with-src-code" : false,
            "visualize-jumps" : true,
            "syntax" : "intel"
        },
        "nm" : {
            "binary" : ""
        },
        "targets-filter" : [".so", ".a", "CMake"]
    }

Author: JBakamovic

README.md

@@ -34,6 +34,7 @@ JSON-compilation-database integration | :heavy_check_mark: | :heavy_check_mark:
 Plain-text-compilation-database integration | :heavy_check_mark: | :heavy_check_mark:
 Arbitrary build targets integration | :heavy_check_mark: | :heavy_check_mark:
 Per-repository cxxd custom configuration (JSON) | :heavy_check_mark: | :heavy_check_mark:
+Godbolt-like disassembler | :heavy_check_mark: | :heavy_check_mark:
 
 In essence, the main idea behind it is very much alike to what [`LSP`](https://microsoft.github.io/language-server-protocol/) offers 
 and its implementations like [`clangd`](https://clang.llvm.org/extra/clangd.html).
@@ -58,8 +59,8 @@ Optional: `clang-format`, `clang-tidy`
 
 Platform | Install
 ------------ | -------------
-`Fedora` | `sudo dnf install python3 clang-devel clang-libs clang-tools-extra && pip install --user clang`
-`Debian` | `sudo apt-get install python3 libclang-dev clang-tidy clang-format && pip install --user clang`
+`Fedora` | `sudo dnf install python3 clang-devel clang-libs clang-tools-extra && pip install --user clang cxxfilt`
+`Debian` | `sudo apt-get install python3 libclang-dev clang-tidy clang-format && pip install --user clang cxxfilt`
 
 # Configuration
 
@@ -87,6 +88,15 @@ Category | Type | Value | Description
  . | `args` | `clang-tidy` specific cmd-line args | Here we can provide a list of any arguments that we want to pass over to `clang-tidy` invocation. For example, to enable bugprone, cppcoreguidelines and readability `clang-tidy` checks we would do `'args' : { '-checks' : "'-*,bugprone-*,cppcoreguidelines-*,readability-*'", "-extra-arg" : "'-Wno-unknown-warning-option'", '-header-filter' : '.*' }`. We can use this list to basically pass any argument that given version of `clang-tidy` can recognize and tweak it according to the project-specific needs.
  `clang` | | | Here we can optionally set some of the `clang`-specific settings. Should be needed very rarely.
  . | `library-file` | path-to-specific-libclang-so-library | When updating your system, sometimes a new version of `libclang` can introduce bugs or changes in behavior which will result with glitches in the usage experience. Same can happen with the python bindings of `libclang`. Because `cxxd` does not have a capacity to be tested against every version of `libclang` and its python bindings, `library-file` serves the purpose to tell `cxxd` to use a certain version of `libclang`. If not provided, `cxxd` will by default use the system-wide one, which in most cases should be enough. However, if you suddenly start to experience the issues, which you have not before, this should be a first thing to check. And possibly revert the `libclang` version to an earlier one. E.g. `'library-file': '/usr/lib64/libclang.so.14.0.5'`.
+ `disassembly` | | | Godbolt-like utility which allows you to examine the disassembly in selected executable target for a given symbol you requested it for at the source code level.
+ . | `objdump` | |
+ . | `binary` | path-to-specific-objdump-binary | Usually system-wide installed `objdump` will match the needs but if not, this field can be used to pin to particular version of `objdump`. E.g. `'binary': '/opt/clang+llvm-8.0.0-x86_64-linux-gnu/bin/objdump'`
+ . | `intermix-with-src-code` | true or false | Default is false. If you want to see source-code mixed within the disassembled binary set this field to true.
+ . | `visualize-jumps` | true or false | Default is true. If you want to disable ASCII art which visualizes jumps within the disassembled binary set this field to false.
+ . | `syntax` | `intel` or `att` | Default is `intel`. Syntax used for instructions in a disassembled binary.
+ . | `nm` | |
+ . | `binary` | path-to-specific-nm-binary | Usually system-wide installed `nm` will match the needs but if not, this field can be used to pin to particular version of `nm`. E.g. `'binary': '/opt/clang+llvm-8.0.0-x86_64-linux-gnu/bin/nm'`
+ . | `targets-filter` | A list of extensions or directories | Prior to disassembly, a target binary needs to be selected. This filter can be used to remove targets that are not interesting. E.g. `[".so", ".a", "CMake"]`
 
 ## Compilation database
 
@@ -189,6 +199,16 @@ Some parts of the MySQL used non-standard file extensions for the source code su
                 "cmd" : "cmake ../../../5.x -GNinja -DCMAKE_BUILD_TYPE=RelWithDebInfo -DDOWNLOAD_BOOST=ON -DWITH_BOOST=../ -DWITH_UNIT_TESTS=ON -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_CXX_COMPILER_LAUNCHER=ccache && ninja"
             },
         }
+    },
+    "disassembly" : {
+        "objdump" : {
+            "intermix-with-src-code" : false,
+            "visualize-jumps" : true,
+            "syntax" : "intel"
+        },
+        "nm" : {
+        },
+        "targets-filter" : [".so", ".a", "CMake"]
     }
 }
 ```

api.py

@@ -4,6 +4,7 @@
 from . services.code_completion.code_completion import CodeCompletionRequestId
 from . services.source_code_model.indexer.clang_indexer import SourceCodeModelIndexerRequestId
 from . services.project_builder_service import ProjectBuilderRequestId
+from . services.disassembly_service import DisassemblyRequestId
 
 #
 # Server API
@@ -180,6 +181,26 @@ def clang_tidy_stop(handle, subscribe_for_callback):
 def clang_tidy_request(handle, filename, apply_fixes):
     _server_request_service(handle, ServiceId.CLANG_TIDY, filename, apply_fixes)
 
+#
+# Disassembly service API
+#
+def disassembly_start(handle):
+    _server_start_service(handle, ServiceId.DISASSEMBLY)
+
+def disassembly_stop(handle, subscribe_for_callback):
+    _server_stop_service(handle, ServiceId.DISASSEMBLY, subscribe_for_callback)
+
+def disassembly_list_targets(handle):
+    _server_request_service(handle, ServiceId.DISASSEMBLY, DisassemblyRequestId.LIST_TARGETS)
+
+def disassembly_list_symbol_candidates(handle, target, filename, line, column):
+    _server_request_service(handle, ServiceId.DISASSEMBLY, DisassemblyRequestId.LIST_SYMBOL_CANDIDATES, target, filename, line, column)
+
+def disassembly_run(handle, target, list_symbol_candidate_index):
+    _server_request_service(handle, ServiceId.DISASSEMBLY, DisassemblyRequestId.DISASSEMBLE, target, list_symbol_candidate_index)
+
+def disassembly_asm_doc(handle, asm_instruction):
+    _server_request_service(handle, ServiceId.DISASSEMBLY, DisassemblyRequestId.ASM_INSTRUCTION_INFO, asm_instruction)
 
 #
 # Helper functions.