On 22/04/2022 07:37, Sebastian Huber wrote: > > > On 17/04/2022 13:27, Jørgen Kvalsvik wrote: >>> In theory, would it be possible to print the state of the truth table with >>> the >>> information available in the gcda and gcno files? For example: >>> >>> Truth table for: a && (b || c)) && d >>> >>> 0 | 1 | 2 | 3 || covered >>> --+---+---+---++-------- >>> 0 | X | X | X || Y >>> 0 | X | X | X || Y >>> 0 | X | X | X || Y >>> 0 | X | X | X || Y >>> 0 | X | X | X || Y >>> 0 | X | X | X || Y >>> 0 | X | X | X || Y >>> 0 | X | X | X || Y >>> 1 | 0 | 0 | X || N >>> 1 | 0 | 0 | X || N >>> 1 | 0 | 1 | 0 || N >>> 1 | 0 | 1 | 1 || N >>> 1 | 1 | X | 0 || Y >>> 1 | 1 | X | 0 || Y >>> 1 | 1 | X | 1 || Y >>> 1 | 1 | X | 1 || Y >> Maybe? We would at least need to store the masking tables too, which right >> now >> are implicitly stored as in the instrumentation. It's not too bad, but it >> probably means the two functions should return some richer structure, which >> in >> turn means a little bit of redesign. Computing the truth table itself >> shouldn't >> be difficult. > > Using the tool in the context of safety-critical application would normally > require also a tool qualification. For GCC, this is a bit unrealistic. It > would > help if the tool output can be verified. Being able to inspect the masking > tables could help a reviewer to check what the tool did for a sample set of > inputs. >
It would be useful for the developer too. Recording the masking vectors isn't hard (they have to be computed after all), maybe it as opt-in behind a flag?
