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

[Sebastian Huber]

On 17/09/2018 05:23, Chris Johns wrote:
> On 17/09/2018 08:46, Joel Sherrill wrote:
>> On Sat, Sep 15, 2018 at 12:58 AM Chris Johns <chrisj at rtems.org
>> <mailto:chrisj at rtems.org>> wrote:
>>
>>      On 14/9/18 11:18 pm, Sebastian Huber wrote:
>>      > ---
>>      >  cpukit/Makefile.am                    | 79
>>      ++++++++++++++++++++++++++++++++++-
>>      >  cpukit/configure.ac <http://configure.ac>                   |  1 -
>>      >  cpukit/sapi/Makefile.am               | 63 ----------------------------
>>      >  cpukit/{sapi => }/vc-key.sh           |  0
>>      >  cpukit/{sapi => }/version-vc-key.h.in <http://version-vc-key.h.in> |  0
>>      >  cpukit/wrapup/Makefile.am             |  2 +-
>>      >  6 files changed, 79 insertions(+), 66 deletions(-)
>>      >  delete mode 100644 cpukit/sapi/Makefile.am
>>      >  rename cpukit/{sapi => }/vc-key.sh (100%)
>>      >  rename cpukit/{sapi => }/version-vc-key.h.in <http://version-vc-key.h.in>
>>      (100%)
>>
>>      Could you please explain why you are performing this merge?
>>
>>      I am not against such a change however I would like to understand what the plan
>>      is and where this is going?
>>
>>      The coverage tool and covoar work is using the internally built libraries to
>>      group functionality, for example score. If the cpukit build is completely
>>      fattened I think that tool may need to change to manage the grouping.
>>
>> The coverage analysis has always assumed that the directories and the
>> sub-libraries created imply areas of functionality that a developer would
>> like to know the coverage of independently of other areas. For example,
>> should the score, fatfs, and shell be lumped into one coverage report
>> or would it be IMO preferable to generate them on each area?
> This makes sense. Any user or organisation wanting coverage information will
> only be interested in specific areas and not everything that could be run. We
> need to provide what we see as the standard groupings and I suspect we will need
> to allow that data to be specialised where a more accurate and controlled
> profile is needed.
>
>> We need to recognize that some code analysis needs to know the logical
>> grouping of code. How do you propose this happen when the information
>> implicit in the sub-libraries is lost?
> We have a growing set of data with RTEMS. Some of the files under this tree in
> the tester are an example:
>
> https://git.rtems.org/rtems-tools/tree/tester/rtems
>
> I see the grouping of source as another set of data we need to maintain. The
> current use of libraries is implementation specific ...
>
> https://git.rtems.org/rtems-tools/tree/tester/rtems/testing/coverage/symbol-sets.ini
>
> ... and we would need to find a workable solution for this patch to be merged.
>
> I am starting to wonder if this data is held in the RTEMS repo and it gets
> installed?

I was not aware that this set of temporary build system artefacts was 
used outside the build tree for some other purposes. I think this 
grouping of coverage analysis should be done independent of build system 
internals. In the DWARF debug information of an object file you have the 
DW_TAG_compile_unit tag and DW_AT_name attribute:

objdump -g --dwarf 
./sparc-rtems5/c/erc32/cpukit/score/src/libscore_a-threaddispatch.o | 
grep -A 10 '(DW_TAG_compile_unit)'
  <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
     <c>   DW_AT_producer    : (indirect string, offset: 0x1f31): GNU 
C11 7.3.0 20180125 (RTEMS 5, RSB 
9670d7541e0621915e521fe76e7bb33de8cee661, Newlib 
d13c84eb07e35984bf7a974cd786a6cdac29e6b9) -mcpu=cypress -g -O2 
-ffunction-sections -fdata-sections
     <10>   DW_AT_language    : 12       (ANSI C99)
     <11>   DW_AT_name        : (indirect string, offset: 0x38d): 
/home/EB/sebastian_h/git-rtems-5/c/src/../../cpukit/score/src/threaddispatch.c
     <15>   DW_AT_comp_dir    : (indirect string, offset: 0x1216): 
/build/git-build/b-erc32/sparc-rtems5/c/erc32/cpukit/score
     <19>   DW_AT_ranges      : 0xd0
     <1d>   DW_AT_low_pc      : 0x0
     <21>   DW_AT_stmt_list   : 0x0
  <1><25>: Abbrev Number: 2 (DW_TAG_base_type)
     <26>   DW_AT_byte_size   : 4
     <27>   DW_AT_encoding    : 5        (signed)

A path pattern could be used for the grouping, e.g. in

https://git.rtems.org/rtems-tools/tree/tester/rtems/testing/coverage/symbol-sets.ini

replace the [libraries] with regular expressions for path patterns. This 
relies on the source tree layout which should be more or less static 
after our header file and BSP movement.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.