On Wednesday 06 February 2008, Nicholas Nethercote wrote: > On Tue, 5 Feb 2008, Josef Weidendorfer wrote: > > > How similar is the format for VCov to cachegrind's? I suppose this > > only needs a further "event" for a source line: whether there is debug info > > or not. > > It's simpler than Cachegrind's. There's no function-level information, so > no "fn=" lines.
Actually, I have no idea what people want here. Is the function name really totally uninteresting here? Neverless, would you say that "fn=" lines are mandatory for the cachegrind format? It should still load without, and in the absence of such lines, it should say "function name unknown" (ie. "???"). > Also, it only records one number per line, and there is no > description in the file of what that number means. I think it would be quite easy to support this simple format with KCachegrind. Would you mind to add (1) some kind of magic at start for autodetection and (2) provision for possible format changes. Something like a fixed header "creator:VCov\nversion:1\n". Both is quite important for integration with external tools; internal to the VG distribution, it can be ignored on the reading side. > I thought about reusing the Cachegrind format. I didn't for two main > reasons: > > - The output from cg_annotate isn't quite right -- it doesn't compute > coverage percentages, and it doesn't highlight unexecuted lines > sufficiently, and we don't need function-level information. Since > cg_annotate doesn't do the right thing, the motivation for using the same > format is diminished. That's right. However, I personally think that there is already a positive effect when merging/filtering tools could be reused. Josef > - I have to parse it in the tool itself (ie. in C) so simpler makes that > easier. > > It's not set in stone, but I felt the reasons against using Cachegrind's > format were stronger than the reasons for. > > > Ah, I just saw the description before parse_buffer(). Do you only output > > lines where debug info is available? > > Yes. > > Nick > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
