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
k4st|12 years ago
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