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? 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. > 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. >> The blocking issue for the change is the need to define and agree on the >> data, >> format and location we want to export from RTEMS. As stated before we >> currently >> have 2 or maybe more pieces of data which are part of RTEMS we depend on by >> external tools. I would like to have this formalised as an interface to >> provide >> some stability for the tools that depend on it. >> >> The updating of any external tools to the agreed format can happen >> independently >> of this change. >> >> The BSP data is defined in the test tool and I recommend we accept this >> format >> for that data. The INI file format can be read by Python and C++ via the >> RTEMS >> Toolkit. I know there are other better formats like YAML however we need >> extra >> package dependences to support it. >> >> The key question for me I would like to resolve is where we put this data. >> Should we move it into rtems.git and install it when RTEMS is installed? > > The question is at which level should the thing be configurable? I see two use cases, the first and primary use case is an RTEMS release and the grouping is what the developers and community agree on. The second case is specialised to certification or related activities where the tools are being used with specific groupings related to a certification effort. Ideally these are the same or converge to be the same. The idea is the tool can be reused with a specific data set to perform a task. The RTEMS kernel provides a set of data for it. All this is on the tool side and not the RTEMS kernel side. > Do you want > some sort of RTEMS components and the user can select a component or not for > whatever tool? Selection maybe supported but that would be on the tool side. Selecting a subset could help improve covoar performance by limited what is examined plus some components may not be used by a user skewing the result. The data should hold the complete definition. > Should be user have the ability to define components? Yes, this is related to an option to say covoar to specify a different set of files. This is reuse issue related to covoar. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
