Approach for exposing HTIF options to other tools

[seldridge]

This provides one strategy for exposing what options are supported by the host to other tools. This uses getopt_long for all argument parsing and exposes the data structures necessary for the parsing in htif_t.h.

As it's necessary to still provide backwards support for spike and elf2hex, two additional legacy constructors are provided for htif_t:

• A no-argument constructor (for elf2hex)
• A constructor taking std::vector<std::string> (for spike)

Summarily:

• Add htif_t constructor that uses (int argc, char** argv) instead of (const std::vector<std::string>)
• Use getopt_long for option parsing and add equivalent -- long options to all existing + options
• Expose supported htif_t options to external programs via macros in htif_t.h (see freechipsproject/rocket-chip#597)
• Trying to use the +disk option will throw a std::invalid_argument exception (as I'm still not aware of this being supported)
• Add check on options that should be skipped -- currently limited to VCS' -cm XXX+YYY
• Fix incorrect set_chroot error message

Fixes #24.

Due to the use of the legacy std::vector<std::string> this should, theoretically, not break anything. However, it may... I was unaware until trying to build riscv-torture that elf2hex wants to pass empty options into the htif_t constructor.

This is intended to be backed up by freechipsproject/rocket-chip#597.

[aswaterman]

Is there a getopt_long that isn’t GPL? I thought it was infectious, but maybe I’m misremembering.

[seldridge]

Yes, there's a BSD implementation (https://github.com/freebsd/freebsd/blob/master/include/getopt.h).

Also, getopt/getopt_long are libc (which in my understanding is LGPL and avoids any problems here). Equivalently, I think this is the same territory as include <stdio.h>.

I defer to an expert here, as this isn't something that you want to get wrong...

Some earlier discussion of this here: https://github.com/freechipsproject/rocket-chip/issues/484#issuecomment-265831119

[aswaterman]

Indeed, my memory is faulty. @palmer-dabbelt any objections?

[palmer-dabbelt]

It looks like it's a GNU extension, but that's not a GPL thing -- we're in the same license territory as linking against anything else in libc. I'm OK with it.

[neelgala]

Hi, There are zero argument commands in spike as well: spike --dump-dts. (A binary should not be needed to generate dts). However, htif fails on this and I believe this particular commit/pull-request is responsible for this.

should I be filing a new issue or would you prefer opening this again?

[seldridge]

@neelgala: thanks, you are right about this. Spike should be able to handle a one-argument option. I think the fix is a lot simpler initially, however... spike creates a sim_t object before it knows if it's going to exit (https://github.com/riscv/riscv-isa-sim/blob/9d1e10a36e771bf8cfbf515e07e856e021c1007a/spike_main/spike.cc#L157).

For the time being, the binary doesn't appear to have to actually exist:

spike --dump-dts foo

This is a new issue on spike. I expect I can get a PR together that will fix this and a second that aligns spike's option parsing with fesvr.

Edit: Ignore my comment about moving the sim_t object. Totally wrong. I looked at this too quickly.

[seldridge]

Digging into this more... the existing (though undocumented) way to specify a "no-binary htif" is by passing "none" as the program (see: https://github.com/riscv/riscv-fesvr/blob/master/fesvr/htif.cc#L79). This code path is never hit by spike --dump-dts none, but this appears to be the (ancient) kludge that's in there now. If this is the way that we want to go, then this "none" escape should be reflected in the option parsing.

This probably warrants a broader discussion related to whether or not htif should be mandating a program to load. @aswaterman: what do you think?