Frontend Config + One grammar system + -p command line option #512

jaybosamiya · 2016-07-12T16:55:06Z

This PR makes a lot of changes.

Passes are no longer called using --PASS, but instead must be called using -p PASS. This concludes the discussion Discussion: Change to command line arguments #503.
The command line grammar is now a single grammar that contains all the possible arguments. This means that when plugins add command line options, these options propagate to the main bap --help. Note that --PLUGIN-help also works, and lists only arguments specific to that plugin, along with its own manpage.
Config is now moved completely out of the Self(). In a future PR, Self() will be completely phased out and plugin developers will no longer have to do the "magic" include Self() anymore.
Frontends now use a very similar interface to write command line options as Config, but since they would use Frontend.Config, they are allowed to also set up special commands (similar to the way status and add are commands for git). This allows a lot of versatality for frontends.
Frontends are allowed to set up positional arguments as well (such as FILE used in bap).
Checks are put in so that plugins cannot mess with frontend, and frontend cannot mess with plugin parameters.
Update all of our frontends to the new interface.
Allows frontends to set up "post-checks" which basically run after plugins are loaded, but before frontend is made ready. This allows to catch errors for things like --rooter etc very early, even though it depends on the plugins finishing off their registrations.
Does pre-processing on the command line arguments (but hidden away internally) so that plugin loading is no longer needed to be handled specifically by the frontend (such as the -l, -L etc. options), but is done in advance, and still works perfectly from the grammar.

Note: Some more minor changes and fixes might need to be done, but I am making this PR so that the review process can start off faster. Also, a refactor of the implemntation of Config needs to be done (for minor cleanups) and would be done in a future PR.

Sorry for the noise but this PR is same as #511 but re-opened since Travis could not detect that PR at all.

This basically ensures that the complete name of argument shows up everywhere, rather than stripped with plugin name (for example, `--taint-ptr` shows up now, rather than `--ptr`). This will help when moving to the one-grammar approach. This also adds the `is_plugin` boolean which makes checking for plugin or not simple, and makes sure that things are set up correctly (for example, at deprecation, for front ends). WARNING! This breaks help pages (i.e. plugins `--<plugin>-help` no longer works). This will be fixed in a commit soon.

This basically allows frontends to be written in the exact same way as plugins while still making sure that the grammar is evaluated correctly

Also improve error handling

ivg · 2016-07-14T20:23:55Z

lib/bap/bap_configuration.ml

+
+  type action = Keep | Drop
+
+  let filter_option options prefix =


Why do we still need this function?

Currently, the filter_option function exists to get rid of --no-PLUGIN type of arguments. If we remove it, then we'll need to add in --no-taint, --no-propagate-taint, --no-ida, etc (i.e. for every plugin). While this would be an easy change to make, it'd cause further bloat to the man page. Are we sure we want to do this? If so, then I can make that change, and remove this completely.

ivg · 2016-07-14T20:30:13Z

Some observed bugs:

bap --list-formats doesn't work as expected:

$ bap --list-formats
Config.error> Required argument FILE is missing

printing format choosing doesn't work any more:

$ bap bin/arm-linux-gnueabi-echo -dbir

Man page for the main frontend doesn't contain sections from manpages of the plugins

jaybosamiya · 2016-07-24T10:28:01Z

As for --list-formats, it is one of those "command" type of params. Now, my initial assumption was the frontends would not have "command" type of params.. One of the ways of doing this is to make a list plugin, which basically does this instead. In fact, to me, it makes sense as a plugin rather than a front end thing. The change needed for allowing --* based commands which override the required positional arguments is such a massively intrusive change that it'd involve changing parts of the Frontend.Config interface (at least as per my understanding, though you might be able to suggest better).

Printing format choosing - I'm going to have to look into it again. I am unable to reproduce the bug on my system. I'll try getting on a completely clean build soon, to see if that ends up reproducing the bug.

Manpage - didn't we decide not to put it in the main manpage (since the manpage explanations can be seen with --PLUGIN-help?) The change to do this will not be to complicated, but would lead to even more bloat on the frontend manpage.

ivg · 2016-07-25T14:01:52Z

One of the ways of doing this is to make a list plugin, which basically does this instead.

One of the reasons why it was made on a frontend side is because, this command must be evaluated only when all plugins are loaded. At the time of adding this option, there were no such mechanism, that why I added this option, that naturally belongs to the print plugin. I think it would be indeed a good idea to move this option to a plugin. We should, however decide, whether it should be a print plugin, e.g., --print-formats. Or a list plugin, that will gather all list options, e.g., --list-formats, --list-passes, etc. An argument against the former, is that formats can be added externally, so the listing operation actually exists on a higher level, then the print plugin. An argument against the latter, is that I don't see a clear mechanism for extending it (especially if we will stick to --list-something format, instead of --list=something,else). Another argument against it, is that we cannot make this interface mandatory, so new plugins may forget to use it, and introduce their own mechanisms.

Printing format choosing - I'm going to have to look into it again. I am unable to reproduce the bug on my system.

It might be because, you have a different order of loading... or you forgot to push some fixes ;)

Manpage - didn't we decide not to put it in the main manpage

Did we? Maybe this indeed would be a good idea. As we still have all possible options (so we satisfy the greppable requirement). And we can get an extended information by querying specific plugin for the help, e.g., --<plugin>-help (that satisfies structural requirement). So, indeed it might be a good idea.

Conflicts: src/bap_cmdline_terms.ml src/bap_main.ml src/bap_mc.ml

ivg · 2018-08-08T14:10:17Z

@gitoleg, you're the new owner of this PR, so make sure that it is merged, or at least the necessary parts of it are merged. We still have the configuration system broken, and we need it fixed.

ivg · 2019-02-18T19:06:02Z

Let's admit we won't merge it and it anyway bitrotten beyond repair. We will be inspired with this code when we will release BAP 2.0.

The master branch is already restricted from pushes so the code can reach the master branch only through a pull requested. We don't want to the same work twice. Also removes (the commented) windows line, we will return it back, once we will have time for that, see also BinaryAnalysisPlatform#512

* Try to use GitHub Actions * Fix LLVM installation for Homebrew * Disable install for now * MacOS fixes * Disable Windows for now * Fix CI * fixes CI, build on ubuntu only * launch unit tests after bap installed * try set cache home dir via env * wip * wip * Grammar eye-candy. * Try MacOS again * switches to a non-alternate llvm, removes the LLVM_CONFIG step First of all, `/usr/local/opt/llvm/bin/llvm-config` is llvm-config of LLVM that is shipped with MacOS and which is stripped from any non-native targets so we can't use it. The requested llvm@9 is installed at `/usr/local/opt/llvm@9` and is not symlinked to `/usr/local` because it is keg-only: ``` llvm@9 is keg-only, which means it was not symlinked into /usr/local, because this is an alternate version of another formula. If you need to have llvm@9 first in your PATH run: echo 'export PATH="/usr/local/opt/llvm@9/bin:$PATH"' >> /Users/runner/.bash_profile For compilers to find llvm@9 you may need to set: export LDFLAGS="-L/usr/local/opt/llvm@9/lib" export CPPFLAGS="-I/usr/local/opt/llvm@9/include" ``` llvm@10 aka llvm is also keg-only so it will be installed only into the cellar. I have to guess whether the llvm-config binary will be named llvm-config or llvm-config-9, but I bet for the former. * sets TMPDIR env var to pass tests on mac os * updates testsuite * do not run on each push The master branch is already restricted from pushes so the code can reach the master branch only through a pull requested. We don't want to the same work twice. Also removes (the commented) windows line, we will return it back, once we will have time for that, see also #512 Co-authored-by: oleg <forown@yandex.ru> Co-authored-by: ivg <ivg@ieee.org>

jaybosamiya added 30 commits July 5, 2016 12:20

Allow plugins to register grammar into global

10d6a42

Simplify help code

a0890a9

Add when_ready and front_end

547f43a

Use CmdlineGrammar to set up global grammar stuff

61538bd

Temporary workaround

a43f466

Remove workaround; frontend can use same interface

845cadb

This basically allows frontends to be written in the exact same way as plugins while still making sure that the grammar is evaluated correctly

Allow Config types outside of Self()

f3cf36b

First approximation for Frontend.Config

3085ce8

Massively simplified interface

f24fb1a

Move standard converters into a module

f531d7c

Make a Command module

19d0bbf

Remove repetitive preprocessing

2295852

Move Command higher

95953f7

Update CmdlineGrammar

7adb244

Ensure frontends cannot call the normal Config

ee53e13

Dont allow plugins to access Frontend

eff20c4

Remove a promise never kept :D

c10e758

better formatting

8884af3

Simplify Command

30b16a7

Remove unused code

4c9eba9

Clarify usage and split frontends and plugins in grammar

fc70fc6

Allow frontends to now say "when_ready"

edb2fcb

Frontends should not add to the plugin stuff

c8c1b58

Use clearer naming

d20f032

Add positional arguments

b9aafbf

Also improve error handling

Prevent spurious errors

44b3a07

Move more stuff outside Self()

19e92c1

Squash some warnings

00ebd3d

Clear up naming confusion

17ba2b4

jaybosamiya added 10 commits July 11, 2016 17:56

Allow None to be specified

bd83132

Add nicer error handling

9ba7288

Allow version info

d7a3425

Allow plugin versions to show

06fbce1

Better formatting for errors

ec74c17

Dont die on version

6266e4a

Check required positionals after plugins are done

debc87f

Merge all rooters if not specified

a6be59b

Separate terminfos for each plugin

0b14b90

Merge branch 'master' into config-frontends

1827a14

jaybosamiya mentioned this pull request Jul 12, 2016

Onward to a single grammar config #510

Closed

jaybosamiya added 3 commits July 12, 2016 14:01

Let frontends get their proper version number

eea0f2f

Clearer description for verbose

a76b88f

Remove options for passes which no longer apply

083dbe9

jaybosamiya mentioned this pull request Jul 12, 2016

Update to use new bap interface BinaryAnalysisPlatform/bap-ida-python#16

Closed

ivg reviewed Jul 14, 2016
View reviewed changes

jaybosamiya mentioned this pull request Jul 28, 2016

Introduce -p, --pass, --passes #531

Merged

Merge branch 'master' into config-frontends

8cebdde

Conflicts: src/bap_cmdline_terms.ml src/bap_main.ml src/bap_mc.ml

ivg mentioned this pull request Sep 29, 2016

LLVM plugin cannot be used as a library #570

Closed

ivg mentioned this pull request Aug 17, 2017

Fix configuration files and merge 512 #691

Closed

ivg added the wip label Oct 27, 2017

ivg closed this Feb 18, 2019

ivg mentioned this pull request Oct 29, 2019

introduces bap-main, unified frontend, new command line interface, etc #1005

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Frontend Config + One grammar system + -p command line option #512

Frontend Config + One grammar system + -p command line option #512

Uh oh!

jaybosamiya commented Jul 12, 2016

Uh oh!

ivg Jul 14, 2016

Uh oh!

jaybosamiya Jul 24, 2016

Uh oh!

ivg commented Jul 14, 2016

Uh oh!

jaybosamiya commented Jul 24, 2016

Uh oh!

ivg commented Jul 25, 2016

Uh oh!

ivg commented Aug 8, 2018

Uh oh!

ivg commented Feb 18, 2019

Uh oh!

Uh oh!

Frontend Config + One grammar system + -p command line option #512

Frontend Config + One grammar system + -p command line option #512

Uh oh!

Conversation

jaybosamiya commented Jul 12, 2016

Uh oh!

ivg Jul 14, 2016

Choose a reason for hiding this comment

Uh oh!

jaybosamiya Jul 24, 2016

Choose a reason for hiding this comment

Uh oh!

ivg commented Jul 14, 2016

Uh oh!

jaybosamiya commented Jul 24, 2016

Uh oh!

ivg commented Jul 25, 2016

Uh oh!

ivg commented Aug 8, 2018

Uh oh!

ivg commented Feb 18, 2019

Uh oh!

Uh oh!