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

[Chris Johns]

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