Re: Re: rtems-5.1 source code test coverage failed
Thank you once again. Your reply is very very fast. small...@aliyun.com From: Joel Sherrill Date: 2020-10-23 10:03 To: smallphd CC: devel Subject: Re: Re: rtems-5.1 source code test coverage failed Hit send too soon On Thu, Oct 22, 2020, 8:59 PM Joel Sherrill wrote: On Thu, Oct 22, 2020, 8:53 PM small...@aliyun.com wrote: Thanks joel. I google the Couverture-Qemu and find many useful document about rtems test coverage. The conventional approach will compile source codes to create *.gcno files. But the Couverture-Qemu method needn't. In the final report, the Couverture-Qemu method will create an annotated.html file in which the instructions are listed as "NOT EXECUTED" or executed. The main different is only assembly language is used, while the conventional approach will list the souce code in C language. The reports from covoar include the source code. The reports are from a developer perspective and we haven't had any feedback from iv folks. If the reports don't match what you need, there is always the source code . :) This is an area where feedback, contributions, and supporting developers is really appreciated. And there is an RSB recipe for couverture qemu which should make it easier to build. I'd love to see this area of our tooling and ecosystem get love and grow. :) --joel small...@aliyun.com From: Joel Sherrill Date: 2020-10-22 23:49 To: small...@aliyun.com CC: devel Subject: Re: rtems-5.1 source code test coverage failed On Thu, Oct 22, 2020 at 4:02 AM small...@aliyun.com wrote: hi, all I want test source code coverage in qemu. There are some questions I met. 1. If compiling without -ftest-coverage, the test only produce a percent coverage, no *.gcov file which is important to recognize which lines not execute. 2. If compiling with -ftest-coverage, *.gcno are created in the same directory with *.o and these *.gcno file are included in xilinx_zynq_a9_qemu-symbols.ini. However this ini file could only include *.o. So the execution will raise error - File format not ELF or archive. Is there a tutorial introducing how to get rtems-5.1 source code test coverage? We don't do coverage that way. Some simulators can directly produce gcov data. I think tsim can do that for example. gcov foundationally assumes that it can run, collect data, and write it to a file at program exit. That model doesn't work on embedded targets. There are some write ups on the net of people forcing gcov data to be written sporadically and magic to get it off target. But this isn't how RTEMS has done coverage. We depend on simulators that write trace logs and a utility called covoar which can correlate multiple trace logs with the program executables and product a unified report. Remember that the same function may be in two RTEMS executables but they will not be at the same physical address. The trace/log execution information produced by the simulators will be in terms of which physical addresses are executed. The RTEMS Tester has support for running coverage and hopefully the documentation is good at explaining that. The qemu couverture project (a separate repo from regular qemu), sis, and tsim all produce trace/coverage info for an executable that covoar should be able to process. FWIW there is at least one known issue with covoar right now. Sometimes the reported size of a method differs between two executables. Historically, this has been due to padding after a method so the next adjacent method in memory is cache line aligned. covoar will reject information when a method has different sizes in different executables. But can adjust if it is nop padding to ignore at the end. No one has produced a reproducible test case to investigate for this latest one. Given two executables where function X appears to be different sizes, it is usually easy to see by hand what the program is missing. But you need that test case. --joel Thank you very much! small...@aliyun.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Re: rtems-5.1 source code test coverage failed
Hit send too soon On Thu, Oct 22, 2020, 8:59 PM Joel Sherrill wrote: > > > On Thu, Oct 22, 2020, 8:53 PM small...@aliyun.com > wrote: > >> Thanks joel. >> >> I google the Couverture-Qemu and find many useful document about rtems >> test coverage. >> The conventional approach will compile source codes to create *.gcno >> files. But the Couverture-Qemu method needn't. >> In the final report, the Couverture-Qemu method will create an >> annotated.html file in which the instructions are listed as "NOT EXECUTED" >> or executed. >> The main different is only assembly language is used, while the >> conventional approach will list the souce code in C language. >> > > The reports from covoar include the source code. The reports are from a > developer perspective and we haven't had any feedback from iv folks. If > the reports don't match what you need, there is always the source code . :) > This is an area where feedback, contributions, and supporting developers is really appreciated. And there is an RSB recipe for couverture qemu which should make it easier to build. I'd love to see this area of our tooling and ecosystem get love and grow. :) --joel > > >> -- >> small...@aliyun.com >> >> >> *From:* Joel Sherrill >> *Date:* 2020-10-22 23:49 >> *To:* small...@aliyun.com >> *CC:* devel >> *Subject:* Re: rtems-5.1 source code test coverage failed >> >> >> On Thu, Oct 22, 2020 at 4:02 AM small...@aliyun.com >> wrote: >> >>> hi, all >>> I want test source code coverage in qemu. There are some questions I met. >>> 1. If compiling without -ftest-coverage, the test only produce a percent >>> coverage, no *.gcov file which is important to recognize which lines not >>> execute. >>> 2. If compiling with -ftest-coverage, *.gcno are created in the same >>> directory with *.o and these *.gcno file are included >>> in xilinx_zynq_a9_qemu-symbols.ini. However this ini file could only >>> include *.o. So the execution will raise error - File format not ELF or >>> archive. >>> >>> Is there a tutorial introducing how to get rtems-5.1 source code test >>> coverage? >>> >> >> We don't do coverage that way. Some simulators can directly produce gcov >> data. >> I think tsim can do that for example. >> >> gcov foundationally assumes that it can run, collect data, and write it >> to a file >> at program exit. That model doesn't work on embedded targets. There are >> some write ups on the net of people forcing gcov data to be written >> sporadically >> and magic to get it off target. But this isn't how RTEMS has done >> coverage. >> >> We depend on simulators that write trace logs and a utility called >> covoar which >> can correlate multiple trace logs with the program executables and product >> a unified report. Remember that the same function may be in two RTEMS >> executables but they will not be at the same physical address. The >> trace/log >> execution information produced by the simulators will be in terms of which >> physical addresses are executed. >> >> The RTEMS Tester has support for running coverage and hopefully the >> documentation is good at explaining that. >> >> The qemu couverture project (a separate repo from regular qemu), sis, >> and tsim all produce trace/coverage info for an executable that covoar >> should be able to process. >> >> FWIW there is at least one known issue with covoar right now. Sometimes >> the reported size of a method differs between two executables. >> Historically, >> this has been due to padding after a method so the next adjacent >> method in memory is cache line aligned. covoar will reject information >> when a method has different sizes in different executables. But can >> adjust if it is nop padding to ignore at the end. No one has produced >> a reproducible test case to investigate for this latest one. Given >> two executables where function X appears to be different sizes, it >> is usually easy to see by hand what the program is missing. But you >> need that test case. >> >> --joel >> >> >>> Thank you very much! >>> >>> -- >>> small...@aliyun.com >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >> >> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Re: rtems-5.1 source code test coverage failed
On Thu, Oct 22, 2020, 8:53 PM small...@aliyun.com wrote: > Thanks joel. > > I google the Couverture-Qemu and find many useful document about rtems > test coverage. > The conventional approach will compile source codes to create *.gcno > files. But the Couverture-Qemu method needn't. > In the final report, the Couverture-Qemu method will create an > annotated.html file in which the instructions are listed as "NOT EXECUTED" > or executed. > The main different is only assembly language is used, while the > conventional approach will list the souce code in C language. > The reports from covoar include the source code. The reports are from a developer perspective and we haven't had any feedback from iv folks. If the reports don't match what you need, there is always the source code . :) If > > -- > small...@aliyun.com > > > *From:* Joel Sherrill > *Date:* 2020-10-22 23:49 > *To:* small...@aliyun.com > *CC:* devel > *Subject:* Re: rtems-5.1 source code test coverage failed > > > On Thu, Oct 22, 2020 at 4:02 AM small...@aliyun.com > wrote: > >> hi, all >> I want test source code coverage in qemu. There are some questions I met. >> 1. If compiling without -ftest-coverage, the test only produce a percent >> coverage, no *.gcov file which is important to recognize which lines not >> execute. >> 2. If compiling with -ftest-coverage, *.gcno are created in the same >> directory with *.o and these *.gcno file are included >> in xilinx_zynq_a9_qemu-symbols.ini. However this ini file could only >> include *.o. So the execution will raise error - File format not ELF or >> archive. >> >> Is there a tutorial introducing how to get rtems-5.1 source code test >> coverage? >> > > We don't do coverage that way. Some simulators can directly produce gcov > data. > I think tsim can do that for example. > > gcov foundationally assumes that it can run, collect data, and write it to > a file > at program exit. That model doesn't work on embedded targets. There are > some write ups on the net of people forcing gcov data to be written > sporadically > and magic to get it off target. But this isn't how RTEMS has done coverage. > > We depend on simulators that write trace logs and a utility called > covoar which > can correlate multiple trace logs with the program executables and product > a unified report. Remember that the same function may be in two RTEMS > executables but they will not be at the same physical address. The > trace/log > execution information produced by the simulators will be in terms of which > physical addresses are executed. > > The RTEMS Tester has support for running coverage and hopefully the > documentation is good at explaining that. > > The qemu couverture project (a separate repo from regular qemu), sis, > and tsim all produce trace/coverage info for an executable that covoar > should be able to process. > > FWIW there is at least one known issue with covoar right now. Sometimes > the reported size of a method differs between two executables. > Historically, > this has been due to padding after a method so the next adjacent > method in memory is cache line aligned. covoar will reject information > when a method has different sizes in different executables. But can > adjust if it is nop padding to ignore at the end. No one has produced > a reproducible test case to investigate for this latest one. Given > two executables where function X appears to be different sizes, it > is usually easy to see by hand what the program is missing. But you > need that test case. > > --joel > > >> Thank you very much! >> >> -- >> small...@aliyun.com >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Re: rtems-5.1 source code test coverage failed
Thanks joel. I google the Couverture-Qemu and find many useful document about rtems test coverage. The conventional approach will compile source codes to create *.gcno files. But the Couverture-Qemu method needn't. In the final report, the Couverture-Qemu method will create an annotated.html file in which the instructions are listed as "NOT EXECUTED" or executed. The main different is only assembly language is used, while the conventional approach will list the souce code in C language. small...@aliyun.com From: Joel Sherrill Date: 2020-10-22 23:49 To: small...@aliyun.com CC: devel Subject: Re: rtems-5.1 source code test coverage failed On Thu, Oct 22, 2020 at 4:02 AM small...@aliyun.com wrote: hi, all I want test source code coverage in qemu. There are some questions I met. 1. If compiling without -ftest-coverage, the test only produce a percent coverage, no *.gcov file which is important to recognize which lines not execute. 2. If compiling with -ftest-coverage, *.gcno are created in the same directory with *.o and these *.gcno file are included in xilinx_zynq_a9_qemu-symbols.ini. However this ini file could only include *.o. So the execution will raise error - File format not ELF or archive. Is there a tutorial introducing how to get rtems-5.1 source code test coverage? We don't do coverage that way. Some simulators can directly produce gcov data. I think tsim can do that for example. gcov foundationally assumes that it can run, collect data, and write it to a file at program exit. That model doesn't work on embedded targets. There are some write ups on the net of people forcing gcov data to be written sporadically and magic to get it off target. But this isn't how RTEMS has done coverage. We depend on simulators that write trace logs and a utility called covoar which can correlate multiple trace logs with the program executables and product a unified report. Remember that the same function may be in two RTEMS executables but they will not be at the same physical address. The trace/log execution information produced by the simulators will be in terms of which physical addresses are executed. The RTEMS Tester has support for running coverage and hopefully the documentation is good at explaining that. The qemu couverture project (a separate repo from regular qemu), sis, and tsim all produce trace/coverage info for an executable that covoar should be able to process. FWIW there is at least one known issue with covoar right now. Sometimes the reported size of a method differs between two executables. Historically, this has been due to padding after a method so the next adjacent method in memory is cache line aligned. covoar will reject information when a method has different sizes in different executables. But can adjust if it is nop padding to ignore at the end. No one has produced a reproducible test case to investigate for this latest one. Given two executables where function X appears to be different sizes, it is usually easy to see by hand what the program is missing. But you need that test case. --joel Thank you very much! small...@aliyun.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS Presentations at EPICS Collaboration Meeting
Hi Gedare and Chris presented at the EPICS Collaboration Meeting this week. A news item with links to the presentations is at https://www.rtems.org/node/136. A core theme is that we want RTEMS to be a great foundation for frameworks like EPICS and CFS. Chris did a great job presenting on the past, present, and future of EPICS+RTEMS highlighting areas that will need work in the future. He did this in spite of it being the middle of the night for him. Gedare presented on his security research related to EPICS and RTEMS. There are lots of opportunities to improve our testing presented. For those fashion conscious RTEMS users, Gedare looked snazzy rocking the 15th anniversary Google Summer of Code T-Shirt. Please take a few minutes to look through the presentations and feel free to ask questions. The best presentations are just the starting point for discussion. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS big comment conventions
On 23/10/20 3:13 am, Joel Sherrill wrote: > On Thu, Oct 22, 2020 at 6:07 AM Andrew Butterfield > mailto:andrew.butterfi...@scss.tcd.ie>> > wrote: > > Dear all, > > In the RTEMS Software Engineering manual, Sec 6.3.2.1 > > https://docs.rtems.org/branches/master/eng/coding-80cols.html#breaking-long-lines > it recommends excessively long comments be broken as follows: > > /* first line > * second line > * third, and in this case last line */ > > I don't think that should be used. I don't know that we ever allowed that. > Maybe that's a formatting mistake in the documentation. That part of the > engineering guide was converted from the wiki to Sphinx by students. I agree we should avoid this style. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: [PATCH] score/aarch64: Size saved SP register for ABI
From: Hesham Almatary
Sent: Thursday, October 22, 2020 14:51
To: Kinsey Moore
Cc: devel@rtems.org
Subject: Re: [PATCH] score/aarch64: Size saved SP register for ABI
On Thu, 22 Oct 2020 at 20:07, Kinsey Moore
mailto:kinsey.mo...@oarcorp.com>> wrote:
This ensures that the saved SP register is sized appropriately depending
on the chosen ABI and prevents a warning in the libmisc stack checker.
---
cpukit/score/cpu/aarch64/include/rtems/score/cpu.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
index da2140a2a8..b33f6a1c85 100644
--- a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
@@ -489,7 +489,10 @@ typedef struct {
#ifdef AARCH64_MULTILIB_ARCH_V8_ILP32
uint32_t _register_lr_top;
#endif
- uint64_t register_sp;
+ uintptr_t register_sp;
+#ifdef AARCH64_MULTILIB_ARCH_V8_ILP32
+ uint32_t _register_sp_top;
Won’t uintptr_t work here (and for all of the other integer registers) as well
and consequently we get rid of all of such multiarch ifdefs?
It doesn’t get rid of the multiarch ifdefs, it would just move them to the
offsets #define block above and into the assembly for generating the stack
frame. I’d much rather have the exception frame be a static size and avoid
adjusting the assembly and offsets based on ABI since from the machine’s
perspective it’s still a 64bit pointer even if C and C++ view it as a 32bit
pointer.
Kinsey
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] score/aarch64: Size saved SP register for ABI
On Thu, 22 Oct 2020 at 20:07, Kinsey Moore wrote:
> This ensures that the saved SP register is sized appropriately depending
> on the chosen ABI and prevents a warning in the libmisc stack checker.
> ---
> cpukit/score/cpu/aarch64/include/rtems/score/cpu.h | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
> b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
> index da2140a2a8..b33f6a1c85 100644
> --- a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
> +++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
> @@ -489,7 +489,10 @@ typedef struct {
> #ifdef AARCH64_MULTILIB_ARCH_V8_ILP32
>uint32_t _register_lr_top;
> #endif
> - uint64_t register_sp;
> + uintptr_t register_sp;
> +#ifdef AARCH64_MULTILIB_ARCH_V8_ILP32
> + uint32_t _register_sp_top;
Won’t uintptr_t work here (and for all of the other integer registers) as
well and consequently we get rid of all of such multiarch ifdefs?
> +#endif
>void *register_pc;
> #ifdef AARCH64_MULTILIB_ARCH_V8_ILP32
>uint32_t _register_pc_top;
--
> 2.20.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
--
Hesham
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] score/aarch64: Size saved SP register for ABI
This ensures that the saved SP register is sized appropriately depending
on the chosen ABI and prevents a warning in the libmisc stack checker.
---
cpukit/score/cpu/aarch64/include/rtems/score/cpu.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
index da2140a2a8..b33f6a1c85 100644
--- a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
@@ -489,7 +489,10 @@ typedef struct {
#ifdef AARCH64_MULTILIB_ARCH_V8_ILP32
uint32_t _register_lr_top;
#endif
- uint64_t register_sp;
+ uintptr_t register_sp;
+#ifdef AARCH64_MULTILIB_ARCH_V8_ILP32
+ uint32_t _register_sp_top;
+#endif
void *register_pc;
#ifdef AARCH64_MULTILIB_ARCH_V8_ILP32
uint32_t _register_pc_top;
--
2.20.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Fatal exceptions on context-switching for more than two isolated threads
On 22/10/2020 02:40, Utkarsh Rai wrote: Hello, this thread has gone a bit cold over the last few weeks, due to my engagement in the university tests. I have provided a debug trace for the issue. The reason for fatal exceptions is the fact that while iterating over the chain of user extensions we access a node whose memory location has been set to NO-ACCESS during the context switch. Is there any work-around to this? The option is to move the User_extensions_Iterator storage out of the stack to Thread_Control and Per_CPU_Control. -- 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
Re: RTEMS big comment conventions
Hi Andrew, On Thu, Oct 22, 2020 at 5:07 AM Andrew Butterfield wrote: > > Dear all, > > In the RTEMS Software Engineering manual, Sec 6.3.2.1 > https://docs.rtems.org/branches/master/eng/coding-80cols.html#breaking-long-lines > it recommends excessively long comments be broken as follows: > > /* first line > * second line > * third, and in this case last line */ > > In Sec 6.3.5.2 > https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#fileheadercopyright > we see a copyright and license header which uses the following format > convention: > > /** > * first line > * second line > * third, and in this case last line > */ > > Most RTEMS code I look at seems to follow this second approach, > or the following with only one asterisk on the first line > - particularly the comments that are used to generate Doxygen docs. > > /* > * first line > * second line > * third, and in this case last line > */ > > PS - I prefer this secon/third approach, particularly when the large comment > immediately precedes code. > Correct, the /** is specifically meant for doxygen. (It is the "javadoc" style of comments that doxygen can parse.) A little bit of grep/regex suggests that inside of cpukit/score we have: 3679 occurrences of /* or /** with */ on the same line 2524 occurrences of /* or /** with no */ on the same line 124 occurrences of /* or /** with some trailing characters and no */ on same line 2400 occurrences of /* or /** with no trailing characters on the same line 2524 occurrences of */ with no /* on the same line (good, that matches from above!) 35 occurrences of */ with preceding non-whitespace characters. So your observation is certainly confirmed. We have not been particular about the comment style, but I think usually we see two-liners with /* first line * second line */ While longer than two-lines tends to follow that /* * first * second * third * etc. */ pattern. Use the /** for doxygen comments. I think it would be fine to go with the empty first/last line. That does seem to be the precedent. > I am developing code (C and Promela) for the qualification activity, Our style guidelines for C code is mainly for the code that is internal to RTEMS. We are fine with any self-consistent style in other contributions (such as BSPs) although code that is meant to be added to rtems.git should strive to follow our style. We are looking at how to make style more easily enforced and maintained by tooling. > and want to start to get this right - so which should I use? For standalone tools it is really your choice. We would prefer adoption of an easily maintained style consistent with some kind of sane default. > > Regards, > Andrew Butterfield > > > Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 > Lero@TCD, Head of Software Foundations & Verification Research Group > School of Computer Science and Statistics, > Room G.39, O'Reilly Institute, Trinity College, University of Dublin > http://www.scss.tcd.ie/Andrew.Butterfield/ > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS big comment conventions
On Thu, Oct 22, 2020 at 6:07 AM Andrew Butterfield < andrew.butterfi...@scss.tcd.ie> wrote: > Dear all, > > In the RTEMS Software Engineering manual, Sec 6.3.2.1 > > https://docs.rtems.org/branches/master/eng/coding-80cols.html#breaking-long-lines > it recommends excessively long comments be broken as follows: > > /* first line > * second line > * third, and in this case last line */ > I don't think that should be used. I don't know that we ever allowed that. Maybe that's a formatting mistake in the documentation. That part of the engineering guide was converted from the wiki to Sphinx by students. > In Sec 6.3.5.2 > > https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#fileheadercopyright > we see a copyright and license header which uses the following format > convention: > > /** > * first line > * second line > * third, and in this case last line > */ > The "/**" says this is a comment block to be picked up by Doxygen. > > Most RTEMS code I look at seems to follow this second approach, > or the following with only one asterisk on the first line > - particularly the comments that are used to generate Doxygen docs. > > /* > * first line > * second line > * third, and in this case last line > */ > This is probably most comment for copyright and license blocks which should not be picked up in the Doxygen. But I know it is also used for inline comments in code also not intended for Doxygen. > > PS - I prefer this secon/third approach, particularly when the large > comment > immediately precedes code. > > I am developing code (C and Promela) for the qualification activity, > and want to start to get this right - so which should I use? > Please not the first. Looks like a documentation bug to me. Please feel free to submit a patch and ticket for this. --joel > > Regards, > Andrew Butterfield > > > Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 > Lero@TCD, Head of Software Foundations & Verification Research Group > School of Computer Science and Statistics, > Room G.39, O'Reilly Institute, Trinity College, University of Dublin > http://www.scss.tcd.ie/Andrew.Butterfield/ > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-5.1 source code test coverage failed
On Thu, Oct 22, 2020 at 4:02 AM small...@aliyun.com wrote: > hi, all > I want test source code coverage in qemu. There are some questions I met. > 1. If compiling without -ftest-coverage, the test only produce a percent > coverage, no *.gcov file which is important to recognize which lines not > execute. > 2. If compiling with -ftest-coverage, *.gcno are created in the same > directory with *.o and these *.gcno file are included > in xilinx_zynq_a9_qemu-symbols.ini. However this ini file could only > include *.o. So the execution will raise error - File format not ELF or > archive. > > Is there a tutorial introducing how to get rtems-5.1 source code test > coverage? > We don't do coverage that way. Some simulators can directly produce gcov data. I think tsim can do that for example. gcov foundationally assumes that it can run, collect data, and write it to a file at program exit. That model doesn't work on embedded targets. There are some write ups on the net of people forcing gcov data to be written sporadically and magic to get it off target. But this isn't how RTEMS has done coverage. We depend on simulators that write trace logs and a utility called covoar which can correlate multiple trace logs with the program executables and product a unified report. Remember that the same function may be in two RTEMS executables but they will not be at the same physical address. The trace/log execution information produced by the simulators will be in terms of which physical addresses are executed. The RTEMS Tester has support for running coverage and hopefully the documentation is good at explaining that. The qemu couverture project (a separate repo from regular qemu), sis, and tsim all produce trace/coverage info for an executable that covoar should be able to process. FWIW there is at least one known issue with covoar right now. Sometimes the reported size of a method differs between two executables. Historically, this has been due to padding after a method so the next adjacent method in memory is cache line aligned. covoar will reject information when a method has different sizes in different executables. But can adjust if it is nop padding to ignore at the end. No one has produced a reproducible test case to investigate for this latest one. Given two executables where function X appears to be different sizes, it is usually easy to see by hand what the program is missing. But you need that test case. --joel > Thank you very much! > > -- > small...@aliyun.com > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS big comment conventions
Dear all, In the RTEMS Software Engineering manual, Sec 6.3.2.1 https://docs.rtems.org/branches/master/eng/coding-80cols.html#breaking-long-lines it recommends excessively long comments be broken as follows: /* first line * second line * third, and in this case last line */ In Sec 6.3.5.2 https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#fileheadercopyright we see a copyright and license header which uses the following format convention: /** * first line * second line * third, and in this case last line */ Most RTEMS code I look at seems to follow this second approach, or the following with only one asterisk on the first line - particularly the comments that are used to generate Doxygen docs. /* * first line * second line * third, and in this case last line */ PS - I prefer this secon/third approach, particularly when the large comment immediately precedes code. I am developing code (C and Promela) for the qualification activity, and want to start to get this right - so which should I use? Regards, Andrew Butterfield Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Software Foundations & Verification Research Group School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
rtems-5.1 source code test coverage failed
hi, all I want test source code coverage in qemu. There are some questions I met. 1. If compiling without -ftest-coverage, the test only produce a percent coverage, no *.gcov file which is important to recognize which lines not execute. 2. If compiling with -ftest-coverage, *.gcno are created in the same directory with *.o and these *.gcno file are included in xilinx_zynq_a9_qemu-symbols.ini. However this ini file could only include *.o. So the execution will raise error - File format not ELF or archive. Is there a tutorial introducing how to get rtems-5.1 source code test coverage? Thank you very much! small...@aliyun.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
