Overview and philosophy
bismon (this is a temporary name) is a persistent monitor which (in the future) would interact with the GCC compiler thru plugins.
It is (or will become) somehow a successor to my old GCC MELT project; the medium-term goal is also static program source code analysis with the help of GCC. The source code repository (GPLv3+ licensed) is on https://github.com/bstarynk/bismon ..
My (Basile Starynkevitch, employed
at CEA, LIST in France) work on
partly funded (from start of 2018 to end of 2020) by the European
Union, Horizon H2020 programme, CHARIOT
project, under Grant Agreement No 780075. Within CHARIOT I will focus
on analysis of some kind of
IoT software coded
in C or C++ and (cross-) compiled by GCC on
some Linux desktop. In 2019 - 2021 the development of
bismon is also
partly funded by the DECODER H2020
project, under Grant Agreement 824231 (related to its Persistent
Knowledge Monitor WP1).
Currently (start of 2019)
bismon still in pre alpha-stage, and it is free software under GPLv3+ license. It is intended for a Linux x86-64 desktop developer's workstation (won't work on Windows or MacOSX or Android).
Some still incomplete documentation (as a technical report
doc/bismon-chariot-doc.pdf in PDF) can be generated (with
make doc; that command requires you to have a writable
$HOME/tmp/ directory). An early draft of it might be available on
Potential future usages
While Bismon is currently funded by H2020 projects with
static-analysis goals, please notice that Bismon might later
-when more mature, after 2024- be probably usable as a somehow
generic framework, with a lot of additional work (years, not
months), for many other purposes (the most significant limit being
your imagination, and the power of your computer), including perhaps
even some kind of
graphical environments, many interactive web-based collaborative
concurrently used by some team, or object
or relevant problems. Since Bismon is GPLv3+ licensed, any future
software using it should, IMHO,
practically also be GPLv3+ (but other licensing schemes could be
possible, contact me on
firstname.lastname@example.org for more;
however, IANAL ...)
Develop some kind of high-level (more expressive, more declarative) domain-specific language to facilitate static program source code analysis above GCC and generate GCC plugins for it, so same motivations as GCC MELT (and more broadly related -in motivations- to Coccinnelle, Frama-C, Rascal, CrossMiner, Clang analyser, Clasp etc...).
Important features and goals of that domain-specific language and its implementation include:
orthogonal persistence; this is a major feature (useful for whole program static source code analysis of an analyzed program made of several translation units, each compiled independently) which was not realistically addable to GCC MELT so requires a complete redesign. The
bismonprocess is expected to be relatively long-lived -server like- and retains most of its data from one run to the next (in
store*.bmontextual files). In the future the
bismonprocess will communicate with
g++(cross-)compilation processes (using some GCC plugin, to be generated by
multi-threaded but without any GIL. A small thread pool of worker threads is repeatedly and concurrently fetching tasklets from a global agenda. Each tasklet runs quickly (milliseconds) in some worker thread and can update that agenda (e.g. by adding itself to be continued).
precisely garbage collected
declarative, with good pattern matching and rules formalisms
generating GCC plugins (in C++) which would interact with
bismonby some RPC mechanism
Notice that the syntax and semantics (still undocumented) of
bismon is work-in-progress and subject to change incompatibly.
bismon will be completed to point of being usable, it would be
typically used (thru some web interface) by a small team of developers
working together on some (common) software project coded mostly in C
or C++ (and preferably a free software project).
bismon is in C99 or C11 (including an increasing amount of
generated C code under
modules/), but some few hand-written code
is in C++14 (notably
misc_BM.cc and the
metaprogram generating C headers).
On Linux/x86-64 (e.g. Debian/Unstable or recent Ubuntu) only (Without additional patches or work, Bismon won't work on 32 bits machines!) :
recent GCC (so GCC 7 or preferably GCC 8 ...), with C and C++ and JIT support and plugins enabled (check with
gcc -v; if your system
g++lack support for plugins and libgccjit, you should build and install a recent GCC release from its source code, and configure it to provide them.). An old GCC (e.g. version 6 or earlier) cannot be used.
the documentation needs a
/usr/bin/mipsel-linux-gnu-gcc-8cross-compiler provided by
gcc-8-mipsel-linux-gnuDebian package. Beware, that package conflicts with
gcc-multilib*packages on Debian.
ninja builder, version 1.8 or newer is needed (and is started by
make). Don't use an older one (check with
ninja --version; if that does not work, your
ninjais too old).
a recent Guile interpreter is required, version 2 or better (preferably Guile 2.2). I don't know and strongly dislike Python and the Guile interpreter is GNU, LGPLv3+, and much more familiar to me. Also, concepts from Lisp dialects such as Scheme (the language implemented by Guile) are strongly relevant to understand Bismon, where Guile is used to generate the
build.ninjascript used by the ninja builder.
Jansson 2.12 or better is needed for JSON (used in relation to WebSockets).
libonion is needed for the web interface (later than end of march 2019).
GNU make 4 or better
ccache is used to avoid useless recompilations. If you don't have it, you'll need to edit our
Makefilefor compilation of generated modules.
libbacktrace - it is sometimes part of your system GCC, but you'll better install it separately (e.g. in your
markdown is required for some documentation, such as this
tarfile postprocessor) is used to generate documentation.
relevant Debian/Ubuntu build-dependency packages
On Debian/Unstable or recent Ubuntu,
apt-get install build-essential make ninja-build gcc-8 g++-8 gcc-8-plugin-dev libgccjit-8-dev ccache gcc-8-mipsel-linux-gnu inkscape hevea texlive-full xindy fonts-inconsolata ttf-ubuntu-font-family fonts-ubuntu ttfautohint guile-2.2 for
the building infrastructure; notice that
the MIPSel GCC cross-compiler - it is conflicting with
ttfautohint are needed for generating the documentation.
We still need
apt-get install libgtk-3-dev for GTK 3. This may pull a lot of dependencies.
libbacktrace is not independently packaged in Debian. I recommend building and installing
it from its source code, or else (not recommended,
Makefile to uses your system GCC compiler's one.
libonion is not independently packaged in Debian.
apt-get install markdown indent astyle tardy and
apt-get install texlive texlive-full hevea
dependencies/ subdirectory is for
git submodule-s related to
You may need to add
.mjs as a valid suffix or file extension for
and see Debian
locale to be sure that your localization is POSIX compliant or
English (British or American) in UTF-8 (it cannot for instance
be Italian or Greek or French). So it should be
en_GB.UTF-8. You might want to set your environment
variables appropriately (at least
LC_ALL=en_US.UTF-8, with no other
environment variable). See
don't ask me to understand more these very subtle internationalizaion
details, that topic is very complex. If you still need that work to
be done by me, send me an email at work to
email@example.com. But don't expect it to be done by me
/etc/mime.types file (used by
libonion) does not know about
it, you need to add there the following lines (the first line below,
with an hash
#, is a comment; what is important is the line
The documentation generation needs a writable
You might want (adapt
this suggestion and
define your custom
to improve the interactive output of
git diff on
persistent data files. Perhaps something inspired from
git config diff.bismon.xfuncname '"^«_[0-9A-Za-z_]*$"' might work, but not really.
git repository as usual, and build then use
inside the obtained source tree.
Look into the
Makefile, and edit it if needed; perhaps update the
LIBES= lines, e.g. to use your system's GCC
libbacktrace, by adding
$(shell gcc-7 -print-file-name=include)
PREPROFLAGS= line, and
$(shell gcc-7 -print-file-name=libbacktrace.a) to the
LIBES= line. Of course
replace the 7 by 8 if appropriate. Maybe you need to explicitly set
GXX= to your specific GCC C and C++ compilers.
The persistency mechanism is tested by
./bismon program is (temporarily) still using GTK and
libonion. We want to get rid of GTK. It is symlinked as
Be sure to run
--help at first to
understand the program options that are available.
adding yourself as a contributor
bismon (at least its Web version) needs to know about you. So you
should register yourself once to it (and that would grow its
persistent state). And
bismon (more exactly
bismonion) has a login
form, so you should have a password (specific to
to any other password you have).
You first need to initialize an empty password file (the default
password file is
~/passwords_BM; you could specify another one on
the command line). So run the command
touch ~/passwords_BM in a
terminal (shell) to create that empty file. Then you need to restrict
its permission (readable and writable by your Unix user only) with
chmod u+rw,go-rwx ~/passwords_BM. At last, check with
ls -ls ~/passwords_BM that this file is empty and readable & writable only
Then you'll register yourself. If
Alan Turing is your name or
firstname.lastname@example.org is your main email, with your secondary
turing@localhost, you can add yourself to
running it with something similar to
--contributor='Alan Turing;email@example.com;turing@localhost' and
--dump-after-load=. program options. Of course you
by whatever is appropriate for you. The secondary email (also called
alias) is optional. If you don't use it (so if you don't provide any
alias, which is likely - so replace
turing@localhost with an empty
bismon knows no more about you than
git does (see git
user.name). You might even code some shell script to extract that
personal data information from
git and put it into
At last you need to set your password (it is unrelated to other
passwords in your computer or on the web, but should has at least 10
Unicode characters, and digits, letters, punctuations), as known to
bismon, using the
--add-passwords option (also with
--dump-after-load=.). To set your initial password to
mypass!123456 create some temporary text file (it contains
contributor names and their updated passwords in clear text, so you
should not keep it), perhaps
/tmp/addpassbismon, containing for
Alan Turing:mypass!123456 add run
--add-passwords=/tmp/addpassbismon --batch then remove
/tmp/addpassbismon. Of course you'll better write some shell script
wrapping that, and be sure to have a strong enough password which is
not in this
You might perhaps add a few other users (probably less than a dozen)
that you trust and that can work with you. Every user could mess or
bismon system as easily as you could. Be then sure to be
compliant with the GDPR if any of your
users is European (and GDPR compliance is then your
responsability). The login form is templated (with code from
web_ONIONBM.c) from source file
login_ONIONBM.thtml (and you might
improve the text inside that file if you want).
It is not really usable yet except by me (Basile) in july 2018 (no
static source code analysis yet, no generation of GCC plugins yet). If
you want to see something using GTK, run
./bismongtk then type
the_system in the command window labelled new-bismon, then both
Ctrl and Return keys pressed together. If you want to see
something thru the web interface, run
./bismonion then open its URL
localhost:8086/ or whatever has been specified with
--web-base) in your web browser.
It is recommended to run
make clean once in a while (e.g. daily or
weekly). When generating files,
bismon makes a backup of their
git repository also contains, for convenience, the
jqueryui 1.12 framework (which has a different
MIT license) under
This is unreleased free software
The license (GPLv3+) is likely to not change (it is contractually specified in the CHARIOT grant). The copyright notice is probably wrong: in generated files, it is not yet conforming to GPL expectations. These details are pending bugs, but there are much more other bugs too.
The author is fully aware -in mid 2019- of several bugs in this
bismon system - a research project -, but correcting them is not a
priority (since continuing the progressive bootstrap of Bismon is
much more important, and is not yet achieved). The GTK interface
is buggy by design and crashes often (that won't be corrected), and
should be as quickly as possible replaced by a more usable web
interface - and that is work in progress in mid 2019. Please contact
by email the author to get possible workarounds. Notice that such
temporary bugs known to the author are not registered as Bismon
gitlab issues, since
this software is yet unreleased.