Discussion: Change to command line arguments

[jaybosamiya]

In regards to the updating to the new single-grammar based command line parsing, there are some alternatives we need to consider and decide soon.

Note: I use configuration and command line options almost interchangeably in the discussion below.

Since there exist some plugins which might register pass or not depending on what configuration it has got at runtime, we would be unable to get the complete set of command line options (there is a circular dependency, options depend on registering depends on options). Hence the proposal is to do one of the following:

• Peek Arguments - Peek at the arguments that are known at that point of time, so that plugins are able to receive all configuration parameters, and then are able to register passes, which peeks at the arguments to see "oh, was I called? then lemme run"
  • Advantage(s)
    • User interface remains the same
    • plugin authors write plugins as they've been writing until now
  • Disadvantage(s)
    • Since we are only peeking at items, we can no longer say "unknown option XYZ". This leads to problems for the users who will say "but it should have run the pass" when they've made a typo
    • for plugin developers where due to some mistake in their code, they might end up registering a pass which isn't called and then they would not realize that it is only because of some command line problem
• Promise - Each plugin must, as a promise, provide a bool Config.param (i.e. a flag) which would be used as a witness to register a pass (i.e. cannot register a pass that is not promised earlier).
  • Advantage(s)
    • User interface remains the same
    • we can see complete list of promised passes at a single point (man page)
  • Disadvantage(s)
    • Plugin authors are now forced to do this promise-witness thing for each pass
    • it is significantly harder to guarantee that the witness is not given later on, after the whole command line is parsed (i.e. plugin developers can cause system to break quite easily)
    • users will sometimes see a pass in the manpage which might not work "no such pass registered"
• New -p argument - Passes can now be called via -p pass1,pass2,pass3,... (--pass and --passes would alias to the -p)
  • Advantage(s)
    • No extra work for plugin developers
    • Users now see a more clear interface which separates the passes from plugin options (this will especially help new users, since actually speaking, the order of options doesn't matter, but a new user might think that something like the current --taint-reg=0x2 --taint --somepass --taint-ptr=0x3 --taint --someotherpass refers to a special ordering; but with the new system, it would be clear that the internal working is just --taint-reg=0x2 --taint-ptr=0x3 -p taint,somepass)
  • Disadvantage(s)
    • Users would need to update their scripts to use the new command line options
• Leave it as it is! - Nothing changes
  • Advantage(s)
    • Nothing changes. No extra work for plugin developers, no extra work for users, no extra work for me
  • Disadvantage(s)
    • We cannot move to the single-grammar system, where all options can be seen from a single point
    • We continue using the current hack of manually manipulating the argv and passing to each plugin
    • Users still keep getting confused about --taint-reg=0x2 --taint --somepass --taint-ptr=0x3 --taint --someotherpass meaning that the passes go in that order, though the passes form an internal order amongst themselves (i.e. order of command line args doesn't matter)
    • The currently existing hack forces weird things like bap --no-cache FILE --somepass would say "required argument FILE is missing" but just reordering to bap FILE --somepass --no-cache would work just fine. This can be counter intuitive for users.
• Anything other alternatives?

Please do comment and let me know which of the alternatives would make most sense, since this change would affect a lot of things. Also, as most of us probably agree, we should not be changing API etc much, so any changes we make now for this would definitely stick as a definite design choice from this point forward.

[ivg]

I'm voting for the -p option. The only way, how we can handle --<pass> style of options is by hacking the command line parsing. The reason is that there is a circular dependency, a plugin needs values of arguments before it will register a pass. Moreover, he can't actually make a promise to register the pass, as depending on passed options he might decide not to register it at all.

Also, -p plays well with -d and all other plugin extensible options. So it will be much more consistent.

And finally, I don't want to make bap a special kind of frontend. It should be possible for everyone to make their own frontend. So, we shouldn't do any tricks at the fronted.

[jaybosamiya]

Since there has been no further comments from anyone, and we have a good reason to do it via -p, I will be implementing using this. Please comment further (even on the closed issue) if you have something to add.