[PATCH 11/25] Merge sapi/Makefile.am into cpukit/Makefile.am

[Chris Johns]

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