Support GDB source highlight

[stephanosio]

Support and enable GDB source code syntax highlighting feature, which is supported from GDB 8.3.

[stephanosio]

NOTE: This will add an additional dynamic library dependency (GNU Source Highlight).

In terms of #34, this would mean copying an additional DLL file to the release archive.
In terms of the rest, the distribution package dependencies will need to be updated.

See #37 (comment)

[stephanosio]

NOTE: GNU Source Highlight depends on the boost-regex library.

For Linux and MinGW host builds, the boost-regex library was static-linked, so there is no external action necessary.

For macOS, static linking of boost-regex turned out to be easier said than done (clang does not support -l:libxxx.a argument, so we are opting to dynamic-link for now. This means that we have to add boost dependency for the Homebrew package.

[stephanosio]

NOTE: It is, in fact, possible to statically link libgcc and libstdc++ when building with libsource-highlight (of course, with the GDB build script reworked to get rid of the static libstdc++ check), given that the libsource-highlight is statically built and it is linked with the static version of libboost-regex.

$ ldd gdb
        linux-vdso.so.1 (0x00007ffc672cb000)
        libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5 (0x00007f0fe6ab3000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f0fe6889000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0fe6685000)
        libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007f0fe6108000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0fe5ee9000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0fe5b4b000)
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f0fe5919000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0fe5528000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f0fe78e6000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f0fe530b000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f0fe5108000)

$ ls -lh gdb
-rwxr-xr-x 1 stephanos stephanos 10M Jun  1 20:01 gdb

[stephanosio]

NOTE: Even locally and manually built Windows GDB fails to take advantage of the source highlighting feature:

I suspect this might have something to do with the (ncurses) terminal type (maybe, it doesn't like #win32con?)

Also note that even MinGW-w64 GDB package disables/builds without source-highlight, so there might be something to it:
https://github.com/msys2/MINGW-packages/blob/b26afb5a71c3e0ab7d15741cfade93ade6fe03b6/mingw-w64-gdb/PKGBUILD#L103

RESOLVED: See #37 (comment)

[stephanosio]

GNU Source Highlight-related GDB source code reference:

• https://github.com/bminor/binutils-gdb/blob/3c83b08abfff01d45ce78cabd29e83923b270c3b/gdb/source-cache.c#L190
• https://github.com/bminor/binutils-gdb/blob/b1f1b4decbb40d441ad7a31f2831aee792767fa6/gdb/ui-file.c#L261-L267
• https://github.com/bminor/binutils-gdb/blob/b1f1b4decbb40d441ad7a31f2831aee792767fa6/gdb/ui-file.c#L95-L115
• https://github.com/bminor/binutils-gdb/blob/3c83b08abfff01d45ce78cabd29e83923b270c3b/gdb/source-cache.c#L207-L208

[stephanosio]

NOTE: On Windows, the ANSI (color) escape codes are not supported by default when directly launching standalone cmd.exe (the escape codes will be printed out without intended effect). In order to use these escape codes, one must launch cmd.exe inside the Windows Terminal (i.e. SetConsoleMode(handle, ENABLE_VIRTUAL_TERMINAL_PROCESSING) must be called).

[stephanosio]

PRELIMINARY ANALYSIS/HINTS:

• The fact that we are not seeing malformed ANSI escape codes implies that the GDB is self-inhibiting the use of GNU Source Highlight to generate the highlighted source code text (the source highlight output format is esc.outlang; i.e. ANSI escaped colors).
• Since source_styling is true (see show style), gdb_stdout->can_emit_style_escape () must be returning false.
• gdb_stdout should be stdio_file and its can_emit_style_escape returns this->isatty() && term_cli_styling().
• term_cli_styling on Windows is true as long as "%TERM%" != "dumb".
• this->isatty() calls isatty(m_fd) where m_fd is derived from the constructor.
• tui_file, which is used by the TUI component, inherits stdio_file and its constructor passes the fd to it.
• tui_file for stdout is instantiated in tui_initialize_io with stdout fd.

VALIDATION/TODO:

• Verify that isatty(stdout) returns true. => It returns true and ultimately gdb_stdout->can_emit_style_escape () is also true.
• An exception is thrown inside the highlighter code block. Analyse this exception. => error during the parsing of a definition file

FINAL ANALYSIS:

• highlighter->highlight(...) invokes various internal functions that eventually attempts to resolve the "data directory" path using the Settings::retrieveDataDir() function.
• Settings::retrieveDataDir() function uses an internal hard-coded (from install prefix) path, home directory, or the SOURCE_HIGHLIGHT_DATADIR environment variable to resolve the "data directory" path.
• The "data directory" contains language, style and output definition files; the source highlight library, for obvious reasons, fails to function when they are missing.
• GDB includes neither the source highlight data directory nor any special form of special path configurations to resolve the source highlight data directory path (it relies on the user system to have one in the home directory or in SOURCE_HIGHLIGHT_DATADIR).

ECO (PATCHES):

• GDB build process shall resolve the build system source-highlight data directory and copy/include it under ${PREFIX}/share/gdb/source-highlight (rework the installation script).
• GDB TUI initialisation procedure shall configure the GDB-local source-highlight data directory via Settings:setGlobalDataDir(const std::string &dataDir), unless the SOURCE_HIGHLIGHT_DATADIR environment variable is set in which case its value shall take precedence over the internally resolved path.
• GDB TUI initialisation procedure shall invoke SetConsoleMode(handle, ENABLE_VIRTUAL_TERMINAL_PROCESSING) to ensure that the ANSI color escape codes are properly handled regardless of the host shell environment.

[stephanosio]

GDB patches:
https://sourceware.org/pipermail/gdb-patches/2020-June/169206.html
https://sourceware.org/pipermail/gdb-patches/2020-June/169208.html
https://sourceware.org/pipermail/gdb-patches/2020-June/169209.html