|
From: Benoit P. <ben...@en...> - 2005-04-25 16:58:11
|
Le lun 25/04/2005 =E0 18:02, Josef Weidendorfer a =E9crit : > It would be good to have some iterator functions for debug info available= for=20 > tools. Structs are bad wrt. interface stability. Yes.=20 If I want to provide a patch for this (and maybe for other tools) how should I proceed ? > > As the format is extensible, I'd like to keep a new information > > associated with each file name : the soname where it has been found. > > Can I add a so=3D... before fl=3D... ? >=20 > Do you mean the file name of a shared library, or the soname defined in t= he=20 > shared library? The file name of the shared lib is stored in callgrind fi= les=20 > via "ob=3D" (meaning: ELF object). It would be nice if we could use the s= ame. Let's go for ob=3D > BTW, what are you using this for? I'm using this to group source files in the summary. Sources can be grouped by library, or by directory. That's why I don't really mind if it's the filename or the soname, though the filename may be more explicit to developers. > It seems quite natural for me to also do code coverage on this level. The= n you=20 > would also get information for a source line like: "only 20% of instructi= ons=20 > attributed to this source line are executed". It does coverage at debug level, this means that if there are multiple instructions associated with a line you can have 20% of a line executed. But this is not assembler level, the compiler doesn't associate each opcode with a line. For example a for loop line can be executed from 2 places (so either 0%, 50% or 100%). I don't think getting deeper is usefull. Usually you don't want to get assembler coverage for extern libraries. If you are coding in assembler, doesn't your compiler add this information already ? Benoit |