As someone that does dynamic binary translation for kernel modules (to find bugs) and eventually wants to get into symbolic/concolic execution (to find bugs), this is cool. I would be really pleased if they're able to make a successful business out of this!
I'll try to come up with more ideas as they pop into my head, but given that you consume a binary, I'd like to see a service that consumes core dumps and does what "
Automated Debugging for Arbitrarily Long Executions" (HotOS'13) does (a sort of reverse symbolic execution for find the root cause(s) of a the failure). An extension of this idea would be to operate on arbitrary program images, perhaps multiple images, as a mechanism of doing concolic execution.
Are you using concolic execution, or thinking of going in that direction as a way of generating more runtime-specific info, e.g. execution interleavings, data sharing, common values for memory locations, hot paths, etc.
I suppose a bunch of this is probably outlined in your API or integration with one's build system, but it would be great if a lot more about the process and capabilities of this system were detailed up front. For example, I think it would be useful to make some case studies of some programs, in a similar way that the Viva64 guy does for PVS-Studio, as a way of showing people how to use your system effectively.
Otherwise, I find the traces hard to digest. Unless there is some better interface for reading things, I think it would help convince people that your product is useful if, for example, your system reported the bugs it found in a very clear way. If debug info is in the binary then that should also be referenced, etc.
Finally, a passing note: I think your biggest "competitor" is going to be a tool like AddressSanitizer and other compiler extensions. I mean, I know solving more bugs is good for everyone and whatever gets the job done means better code out there, but I assume eventually you need to make money and convince people that you're going to solve a problem that a compiler extension can't. This is kind of the situation for DBT systems now :-P
Comments
As someone that does dynamic binary translation for kernel modules (to find bugs) and eventually wants to get into symbolic/concolic execution (to find bugs), this is cool. I would be really pleased if they're able to make a successful business out of this!
Thanks! If you have any advice, we are all ears.
I'll try to come up with more ideas as they pop into my head, but given that you consume a binary, I'd like to see a service that consumes core dumps and does what " Automated Debugging for Arbitrarily Long Executions" (HotOS'13) does (a sort of reverse symbolic execution for find the root cause(s) of a the failure). An extension of this idea would be to operate on arbitrary program images, perhaps multiple images, as a mechanism of doing concolic execution.
Are you using concolic execution, or thinking of going in that direction as a way of generating more runtime-specific info, e.g. execution interleavings, data sharing, common values for memory locations, hot paths, etc.
I suppose a bunch of this is probably outlined in your API or integration with one's build system, but it would be great if a lot more about the process and capabilities of this system were detailed up front. For example, I think it would be useful to make some case studies of some programs, in a similar way that the Viva64 guy does for PVS-Studio, as a way of showing people how to use your system effectively.
Otherwise, I find the traces hard to digest. Unless there is some better interface for reading things, I think it would help convince people that your product is useful if, for example, your system reported the bugs it found in a very clear way. If debug info is in the binary then that should also be referenced, etc.
Finally, a passing note: I think your biggest "competitor" is going to be a tool like AddressSanitizer and other compiler extensions. I mean, I know solving more bugs is good for everyone and whatever gets the job done means better code out there, but I assume eventually you need to make money and convince people that you're going to solve a problem that a compiler extension can't. This is kind of the situation for DBT systems now :-P