[PATCH 11/25] Merge sapi/Makefile.am into cpukit/Makefile.am
Sebastian Huber
sebastian.huber at embedded-brains.de
Mon Sep 17 05:13:11 UTC 2018
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.
More information about the devel
mailing list