On 24/09/2018 17:55, Sebastian Huber wrote: > On 24/09/2018 08:35, Chris Johns wrote: >> On 24/09/2018 15:44, Sebastian Huber wrote: >>> A quick and dirty fix could look like this: >>> >>> diff --git a/tester/rtems/testing/coverage/symbol-sets.ini >>> b/tester/rtems/testing/coverage/symbol-sets.ini >>> index 2685ef4..d9afe85 100644 >>> --- a/tester/rtems/testing/coverage/symbol-sets.ini >>> +++ b/tester/rtems/testing/coverage/symbol-sets.ini >>> @@ -29,9 +29,10 @@ >>> # >>> >>> [symbol-sets] >>> -sets = >>> score,rtems,sapi,libdl,posix,libirfs,libdosfs,libdevfs,libimfs,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libblock >>> >>> >>> +sets = >>> cpukit,score,rtems,sapi,libdl,posix,libirfs,libdosfs,libdevfs,libimfs,libcsupport,libbspcmdline,libcpuuse,libstackchk,libfsmount,libstringto,libdevnull,libdumpbuf,libblock >>> >>> >>> >>> [libraries] >>> +cpukit = @BUILD-TARGET@/c/@BSP@/cpukit/libcpukit.a >>> score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a >>> rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a >>> sapi = @BUILD-TARGET@/c/@BSP@/cpukit/sapi/libsapi.a >>> >>> Then build up a regular expression using all libraries other than >>> libcpukit.a, >>> e.g. '(cpukit/score)|(cpukit/rtems)|(cpukit/sapi)'. Then use this regular >>> expression in cache.load_symbols (symbols, regex, true) to filter the >>> symbols. >> We need the complete set of symbols for a "component" so we can determine the >> level of coverage. I am not sure we can have a symbols in more than one >> component, ie cpukit and cpukit/score? > > The approach above would keep the cover tool compatible with the existing > build > tree and the new build tree with a reduced library set. >
The tool is under going change and the current format is new. I do not see an overriding reason to maintain backward compatibility. >> >> Is this grouping on source path or still via libraries? Using internal >> libraries >> seems fragile to me. If we completely flatten the build to create a single >> library, which could happen, we would need to use source paths. > > The grouping would be based on the source path. > Agreed. >> >>> We would have to go from the symbol to the ELF file to the DWARF info of the >>> compilation unit. >> All info should be directly via the ELF and DWARF format. I do not know if we >> need to reference the ELF symbol table or we can just use the DWARF CU data. >> The >> use of objdump should be avoided. > > I only briefly look into this, but you have to go from the > rld::symbols::symbol > to the DWARF info somehow if DesiredSymbols.cc:95 is the right spot to add > this > stuff. > You could be right. The DWARF info will contain all symbols and more. Should these files move to the rtems.git repo? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
