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 <chr...@rtems.org
<mailto:chr...@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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
