[GSOC] Weekly report

[Vidushi Vashishth]

Hi!

As asked by my mentor, I am going to post my weekly project target on the
mailing list every Monday. For this week I have the following planned:

1) Develop use cases (common development problems catered to, etc) for the
rtems tracing support and identify what all needs to be implemented around
with it. This would be documented first in my blog then the users manual.

2) Create a babeltrace conversion formula for CTF conversion. Document it
with sufficient example test cases.

3) Fixing the buffering sample test cases which is currently failing a
rtems-path check on execution.

4) Gain familiarity with barectf, identify methods of integrating it with
rtems-tld output and working on array support for barectf.


Best,
Vidushi
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] sparc64 niagara, usiii: Remove -D options from cfg file and move to bspopts.h

[Joel Sherrill]

I haven't tested this but what do you think of this?


-RTEMS_BSPOPTS_SET([US3],[usiii],[1])
-RTEMS_BSPOPTS_SET([US3],[*],[])
-RTEMS_BSPOPTS_HELP([US3],
-[If defined, enable UltraSPARC optons for the USIII BSP.])
-
-RTEMS_BSPOPTS_SET([SUN4U],[usiii],[1])
-RTEMS_BSPOPTS_SET([SUN4U],[*],[])
-RTEMS_BSPOPTS_HELP([SUN4U],
-[If defined, enable SUN model optons for the USIII BSP.])
+AC_DEFINE(US3, 1, [UltraSPARC model option])
+AC_DEFINE(SUN4U, 1, [SUN model option])


On Sun, May 13, 2018 at 11:16 AM, Joel Sherrill  wrote:

>
>
> On Sun, May 13, 2018, 10:20 AM Gedare Bloom  wrote:
>
>> On Wed, May 9, 2018 at 4:23 PM, Joel Sherrill  wrote:
>> > Updates #3425.
>> > ---
>> >  bsps/sparc64/include/arch/arch.h  |  4 
>> >  bsps/sparc64/include/arch/mm/frame.h  |  4 
>> >  bsps/sparc64/include/arch/mm/mmu.h|  4 
>> >  bsps/sparc64/include/arch/mm/tlb.h|  3 +++
>> >  bsps/sparc64/include/arch/mm/tte.h|  4 
>> >  bsps/sparc64/niagara/config/niagara.cfg   |  2 +-
>> >  bsps/sparc64/usiii/config/usiii.cfg   |  2 +-
>> >  c/src/lib/libbsp/sparc64/niagara/configure.ac |  4 
>> >  c/src/lib/libbsp/sparc64/usiii/configure.ac   | 10 +-
>> >  9 files changed, 34 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/bsps/sparc64/include/arch/arch.h
>> b/bsps/sparc64/include/arch/arch.h
>> > index 5fdd4a2..36aa922 100644
>> > --- a/bsps/sparc64/include/arch/arch.h
>> > +++ b/bsps/sparc64/include/arch/arch.h
>> > @@ -37,10 +37,14 @@
>> >  #ifndef KERN_sparc64_ARCH_H_
>> >  #define KERN_sparc64_ARCH_H_
>> >
>> > +#include 
>> > +
>> >  #if defined (SUN4U)
>> >  #include 
>> >  #elif defined (SUN4V)
>> >  #include 
>> > +#else
>> > +#error "No SUN model defined"
>> >  #endif
>> >
>> >  #define ASI_AIUP   0x10/** Access to primary context
>> with user privileges. */
>> > diff --git a/bsps/sparc64/include/arch/mm/frame.h
>> b/bsps/sparc64/include/arch/mm/frame.h
>> > index fb66e54..2fc17cc 100644
>> > --- a/bsps/sparc64/include/arch/mm/frame.h
>> > +++ b/bsps/sparc64/include/arch/mm/frame.h
>> > @@ -35,10 +35,14 @@
>> >  #ifndef KERN_sparc64_FRAME_H_
>> >  #define KERN_sparc64_FRAME_H_
>> >
>> > +#include 
>> > +
>> >  #if defined (SUN4U)
>> >  #include 
>> >  #elif defined (SUN4V)
>> >  #include 
>> > +#else
>> > +#error "No SUN model defined"
>> >  #endif
>> >
>> >  #endif
>> > diff --git a/bsps/sparc64/include/arch/mm/mmu.h
>> b/bsps/sparc64/include/arch/mm/mmu.h
>> > index 1d445f2..aab143f 100644
>> > --- a/bsps/sparc64/include/arch/mm/mmu.h
>> > +++ b/bsps/sparc64/include/arch/mm/mmu.h
>> > @@ -35,10 +35,14 @@
>> >  #ifndef KERN_sparc64_MMU_H_
>> >  #define KERN_sparc64_MMU_H_
>> >
>> > +#include 
>> > +
>> >  #if defined (SUN4U)
>> >  #include 
>> >  #elif defined (SUN4V)
>> >  #include 
>> > +#else
>> > +#error "No SUN model defined"
>> >  #endif
>> >
>> >
>> > diff --git a/bsps/sparc64/include/arch/mm/tlb.h
>> b/bsps/sparc64/include/arch/mm/tlb.h
>> > index 4adf26c..7a6b85d 100644
>> > --- a/bsps/sparc64/include/arch/mm/tlb.h
>> > +++ b/bsps/sparc64/include/arch/mm/tlb.h
>> > @@ -35,11 +35,14 @@
>> >  #ifndef KERN_sparc64_TLB_H_
>> >  #define KERN_sparc64_TLB_H_
>> >
>> > +#include 
>> >
>> >  #if defined (SUN4U)
>> >  #include 
>> >  #elif defined (SUN4V)
>> >  #include 
>> > +#else
>> > +#error "No SUN model defined"
>> >  #endif
>> >
>> >  #endif
>> > diff --git a/bsps/sparc64/include/arch/mm/tte.h
>> b/bsps/sparc64/include/arch/mm/tte.h
>> > index f0b746e..10a672b 100644
>> > --- a/bsps/sparc64/include/arch/mm/tte.h
>> > +++ b/bsps/sparc64/include/arch/mm/tte.h
>> > @@ -35,10 +35,14 @@
>> >  #ifndef KERN_sparc64_TTE_H_
>> >  #define KERN_sparc64_TTE_H_
>> >
>> > +#include 
>> > +
>> >  #if defined (SUN4U)
>> >  #include 
>> >  #elif defined (SUN4V)
>> >  #include 
>> > +#else
>> > +#error "No SUN model defined"
>> >  #endif
>> >
>> >  #endif
>> > diff --git a/bsps/sparc64/niagara/config/niagara.cfg
>> b/bsps/sparc64/niagara/config/niagara.cfg
>> > index 2fd8973..bfa73aa 100644
>> > --- a/bsps/sparc64/niagara/config/niagara.cfg
>> > +++ b/bsps/sparc64/niagara/config/niagara.cfg
>> > @@ -7,7 +7,7 @@ RTEMS_CPU=sparc64
>> >
>> >  #  This contains the compiler options necessary to select the CPU model
>> >  #  and (hopefully) optimize for it.
>> > -CPU_CFLAGS = -mcpu=niagara -DSUN4V
>> > +CPU_CFLAGS = -mcpu=niagara
>> >
>> >  # optimize flag: typically -g -O2
>> >  CFLAGS_OPTIMIZE_V = -g -O2
>> > diff --git a/bsps/sparc64/usiii/config/usiii.cfg
>> b/bsps/sparc64/usiii/config/usiii.cfg
>> > index b9fad21..ee1c508 100644
>> > --- a/bsps/sparc64/usiii/config/usiii.cfg
>> > +++ b/bsps/sparc64/usiii/config/usiii.cfg
>> > @@ -7,7 +7,7 @@ RTEMS_CPU=sparc64
>> >
>> >  #  This contains the compiler options necessary to select the CPU model
>> >  #  and (hopefully) optimize for it.
>> > -CPU_CFLAGS = -mcpu=ultrasparc3 -DUS3 -DSUN4U
>> > +CPU_CFLAGS = -mcpu=ultrasparc3
>> >
>> >  

[PATCH] covoar: Fix build path checks for multiple executables.

[Cillian O'Donnell]

---
 tester/covoar/covoar.cc | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
index 5c87402..c6b0589 100644
--- a/tester/covoar/covoar.cc
+++ b/tester/covoar/covoar.cc
@@ -75,7 +75,7 @@ static void createBuildPath(Executables& executablesToAnalyze,
 if (buildPrefix.empty()) {
   buildPrefix = *pri;
 } else {
-  if (buildBSP != *pri) {
+  if (buildPrefix != *pri) {
 fail = "executable build prefix does not match: " + buildPrefix;
 break;
   }
@@ -97,7 +97,7 @@ static void createBuildPath(Executables& executablesToAnalyze,
 if (buildPath.empty()) {
   buildPath = thisBuildPath;
 } else {
-  if (buildBSP != *pri) {
+  if (buildPath != thisBuildPath) {
 fail = "executable build path does not match: " + buildPath;
   }
 }
@@ -316,11 +316,7 @@ int main(
 std::cerr << "warning: Unable to read executable: " << argv[i] << 
std::endl;
   } else {
 coverageFileName = argv[i];
-coverageFileName.replace(
-  coverageFileName.length() - executableExtension.size(),
-  executableExtension.size(),
-  coverageExtension
-);
+coverageFileName.append( "." + coverageExtension );
 
 if (!FileIsReadable( coverageFileName.c_str() )) {
   std::cerr << "warning: Unable to read coverage file: " << 
coverageFileName
-- 
2.7.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: gcov support in Covoar

[Vijay Kumar Banerjee]

On 14 May 2018 at 23:37, Joel Sherrill  wrote:

>
>
> On Mon, May 14, 2018 at 12:43 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 14 May 2018 at 21:21, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Mon, May 14, 2018 at 10:19 AM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 Hello,

 The coverage report is showing some data now (txt only). There is still
 some work needed to be done for it to get merged with the main repo. As it
 depends on the ongoing work on the covoar.cc and coverage.py, meanwhile I
 want to get started with the gcov support in covoar as I already have some
 coverage data in txt format to compare with .

 I would like to know the following points to get started:

 1. What is the current state of the gcov support in covoar. I can
 see work on GcovData and GcovFunction data in covoar, what's the current
 status of it ?

>>>
>>> Technically unknown, potentially bit rotted.
>>>
>> Seems like it will take some time before it starts making sense .
>>
>
> Maybe. Since you can produce coverage reports now, I am betting it
> will likely work quickly. :)
>
Hopefully.

>
>
>>
>>
>>>
>>>

 2. Did it use to run at some point? seeing it in action will be
 very helpful.

>>>
>>> It used to produce .gcov files that could be processed by gcov and
>>> produce reports.
>>>
>> Then our very first objective is to get the .gcov file output only then
>> can we proceed with the  discripancies
>>
>
> Yes.
>
> Use the same test executables and symbols of interest.
>
> I suspect you have been looking at a report for the same test exe and the
> same methods.
> Just check that the report from gcov matches. If it doesn't, then we have
> a small test case.
>
Yeah that will be the approach.

>
>
>>
>>> Once you started to compare the reports to the native reports from
>>> covoar, you would sometimes see places that covoar thought some code was
>>> executed that did not show up in the gcov generated report. When I
>>> investigated, I got far enough to know we had executed the code in question.
>>>
>>>

 3. What are the listed blockers rn ? Other than the reliability of
 the report .

>>>
>>> That's it. Get it working and then let's work on automation, use of
>>> lcov, etc. Along the way, I am sure we will spot the difference in
>>> reporting. Then that will have to be fixed.
>>>
>>>
 4. are there any tickets related to gcov?

>>>
>>> Not from RTEMS' perspective.
>>>
>>> One challenge we had previously is that the .gcov file format was only
>>> documented in the header file. That was why I asked for someone from the
>>> gcc community to help us once we spot difference. Hopefully they can help
>>> us figure out what is wrong with the file covoar is producing.
>>>
>>
 Please add any suggestions or references that might help me get started
 properly .

>>>
> https://gcc.gnu.org/onlinedocs/gcc/Gcov-Data-Files.html is an overview
> from a gcc user's perspective.
>
> The details are in the gcc source code. This should be the current version
> of the gcov file:
>
> https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov-io.h
>
Thanks for the links

>
>
> I don't remember a comment in the version in covoar specifying that the
> format could change
> with GCC versions. Maybe that's the gcno data and not the coverage data.
>
> This needs to be looked into properly to undertsand how the versions
impact the report generation.

> Randomly found this tool which looks like another option for more
> reports/analysis once gcov
> files are available:
>
> https://gcovr.com/guide.html
>
>
it says XML reports!
Looks like we have some cool options to try out once we get the initial
steps done.

>
 Thank you,

>>>
> R
>
>>
 Vijay



>>>
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On Mon, 14 May 2018, 23:24 Cillian O'Donnell,  wrote:

>
>
> On Mon, 14 May 2018, 09:50 Vijay Kumar Banerjee, 
> wrote:
>
>> On 14 May 2018 at 12:10, Cillian O'Donnell  wrote:
>>
>>>
>>>
>>> On Sun, 13 May 2018, 22:15 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 14 May 2018 at 02:15, Cillian O'Donnell 
 wrote:

> ---
>  tester/covoar/covoar.cc | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
> index 5c87402..c6b0589 100644
> --- a/tester/covoar/covoar.cc
> +++ b/tester/covoar/covoar.cc
> @@ -75,7 +75,7 @@ static void createBuildPath(Executables&
> executablesToAnalyze,
>  if (buildPrefix.empty()) {
>buildPrefix = *pri;
>  } else {
> -  if (buildBSP != *pri) {
> +  if (buildPrefix != *pri) {
>  fail = "executable build prefix does not match: " +
> buildPrefix;
>  break;
>}
> @@ -97,7 +97,7 @@ static void createBuildPath(Executables&
> executablesToAnalyze,
>  if (buildPath.empty()) {
>buildPath = thisBuildPath;
>  } else {
> -  if (buildBSP != *pri) {
> +  if (buildPath != thisBuildPath) {
>  fail = "executable build path does not match: " +
> buildPath;
>}
>  }
> @@ -316,11 +316,7 @@ int main(
>  std::cerr << "warning: Unable to read executable: " <<
> argv[i] << std::endl;
>} else {
>  coverageFileName = argv[i];
> -coverageFileName.replace(
> -  coverageFileName.length() - executableExtension.size(),
> -  executableExtension.size(),
> -  coverageExtension
> -);
> +coverageFileName.append( "." + coverageExtension );
>
>  if (!FileIsReadable( coverageFileName.c_str() )) {
>std::cerr << "warning: Unable to read coverage file: " <<
> coverageFileName
> --
> 2.7.4
>
> This worked !

>>>
>>> Cool, looks like we're onto fixing the reports then. If you take a look
>>> at report.html only the headings are there. I think what might be wrong
>>> there is it's just searching in the wrong place for the results. The fix
>>> for that will lie in coverage.py. Warning about coverage.py, there could be
>>> whole sections in there that might just be deleted, it's still being
>>> reorganized.
>>>
>>> Are you working on it ?
>>
>
> Yeah I'll be hacking away at that, won't make much of a dent till the
> weekend though.
>
>> Also the absolute path needs to be parsed form the score-symbol.ini for
>> running it from out of the build tree
>>
>
> This is true.
>
>> Or seeing as covoar is in good shape now and I think the txt report is ok
>>> (you should check and make sure of that). You could move onto gcov, lcov
>>> stuff. Figure out the state of the gcov support in covoar, generate gcov
>>> reports, compare the results.
>>>
>> I'll creat a new thread for gcov report then.
>>
>
> Cool, you're gonna do the gcov stuff then.
>
yeah. hopefully it will show some movement soon. :)

> ___
> 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: gcov support in Covoar

[Joel Sherrill]

On Mon, May 14, 2018 at 12:43 PM, Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

> On 14 May 2018 at 21:21, Joel Sherrill  wrote:
>
>>
>>
>> On Mon, May 14, 2018 at 10:19 AM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> The coverage report is showing some data now (txt only). There is still
>>> some work needed to be done for it to get merged with the main repo. As it
>>> depends on the ongoing work on the covoar.cc and coverage.py, meanwhile I
>>> want to get started with the gcov support in covoar as I already have some
>>> coverage data in txt format to compare with .
>>>
>>> I would like to know the following points to get started:
>>>
>>> 1. What is the current state of the gcov support in covoar. I can
>>> see work on GcovData and GcovFunction data in covoar, what's the current
>>> status of it ?
>>>
>>
>> Technically unknown, potentially bit rotted.
>>
> Seems like it will take some time before it starts making sense .
>

Maybe. Since you can produce coverage reports now, I am betting it
will likely work quickly. :)


>
>
>>
>>
>>>
>>> 2. Did it use to run at some point? seeing it in action will be very
>>> helpful.
>>>
>>
>> It used to produce .gcov files that could be processed by gcov and
>> produce reports.
>>
> Then our very first objective is to get the .gcov file output only then
> can we proceed with the  discripancies
>

Yes.

Use the same test executables and symbols of interest.

I suspect you have been looking at a report for the same test exe and the
same methods.
Just check that the report from gcov matches. If it doesn't, then we have a
small test case.


>
>> Once you started to compare the reports to the native reports from
>> covoar, you would sometimes see places that covoar thought some code was
>> executed that did not show up in the gcov generated report. When I
>> investigated, I got far enough to know we had executed the code in question.
>>
>>
>>>
>>> 3. What are the listed blockers rn ? Other than the reliability of
>>> the report .
>>>
>>
>> That's it. Get it working and then let's work on automation, use of lcov,
>> etc. Along the way, I am sure we will spot the difference in reporting.
>> Then that will have to be fixed.
>>
>>
>>> 4. are there any tickets related to gcov?
>>>
>>
>> Not from RTEMS' perspective.
>>
>> One challenge we had previously is that the .gcov file format was only
>> documented in the header file. That was why I asked for someone from the
>> gcc community to help us once we spot difference. Hopefully they can help
>> us figure out what is wrong with the file covoar is producing.
>>
>
>>> Please add any suggestions or references that might help me get started
>>> properly .
>>>
>>
https://gcc.gnu.org/onlinedocs/gcc/Gcov-Data-Files.html is an overview from
a gcc user's perspective.

The details are in the gcc source code. This should be the current version
of the gcov file:

https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov-io.h

I don't remember a comment in the version in covoar specifying that the
format could change
with GCC versions. Maybe that's the gcno data and not the coverage data.

Randomly found this tool which looks like another option for more
reports/analysis once gcov
files are available:

https://gcovr.com/guide.html


>
>>> Thank you,
>>>
>>
R

>
>>> Vijay
>>>
>>>
>>>
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Mon, 14 May 2018, 09:50 Vijay Kumar Banerjee, 
wrote:

> On 14 May 2018 at 12:10, Cillian O'Donnell  wrote:
>
>>
>>
>> On Sun, 13 May 2018, 22:15 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 14 May 2018 at 02:15, Cillian O'Donnell 
>>> wrote:
>>>
 ---
  tester/covoar/covoar.cc | 10 +++---
  1 file changed, 3 insertions(+), 7 deletions(-)

 diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
 index 5c87402..c6b0589 100644
 --- a/tester/covoar/covoar.cc
 +++ b/tester/covoar/covoar.cc
 @@ -75,7 +75,7 @@ static void createBuildPath(Executables&
 executablesToAnalyze,
  if (buildPrefix.empty()) {
buildPrefix = *pri;
  } else {
 -  if (buildBSP != *pri) {
 +  if (buildPrefix != *pri) {
  fail = "executable build prefix does not match: " +
 buildPrefix;
  break;
}
 @@ -97,7 +97,7 @@ static void createBuildPath(Executables&
 executablesToAnalyze,
  if (buildPath.empty()) {
buildPath = thisBuildPath;
  } else {
 -  if (buildBSP != *pri) {
 +  if (buildPath != thisBuildPath) {
  fail = "executable build path does not match: " +
 buildPath;
}
  }
 @@ -316,11 +316,7 @@ int main(
  std::cerr << "warning: Unable to read executable: " << argv[i]
 << std::endl;
} else {
  coverageFileName = argv[i];
 -coverageFileName.replace(
 -  coverageFileName.length() - executableExtension.size(),
 -  executableExtension.size(),
 -  coverageExtension
 -);
 +coverageFileName.append( "." + coverageExtension );

  if (!FileIsReadable( coverageFileName.c_str() )) {
std::cerr << "warning: Unable to read coverage file: " <<
 coverageFileName
 --
 2.7.4

 This worked !
>>>
>>
>> Cool, looks like we're onto fixing the reports then. If you take a look
>> at report.html only the headings are there. I think what might be wrong
>> there is it's just searching in the wrong place for the results. The fix
>> for that will lie in coverage.py. Warning about coverage.py, there could be
>> whole sections in there that might just be deleted, it's still being
>> reorganized.
>>
>> Are you working on it ?
>

Yeah I'll be hacking away at that, won't make much of a dent till the
weekend though.

> Also the absolute path needs to be parsed form the score-symbol.ini for
> running it from out of the build tree
>

This is true.

> Or seeing as covoar is in good shape now and I think the txt report is ok
>> (you should check and make sure of that). You could move onto gcov, lcov
>> stuff. Figure out the state of the gcov support in covoar, generate gcov
>> reports, compare the results.
>>
> I'll creat a new thread for gcov report then.
>

Cool, you're gonna do the gcov stuff then.

> ___
 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: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Mon, 14 May 2018, 16:46 Joel Sherrill,  wrote:

> I'll commit this once there is a log message. :)
>

You want the word 'Fix' is it?... :)

>
> On Sun, May 13, 2018 at 3:45 PM, Cillian O'Donnell 
> wrote:
>
>> ---
>>  tester/covoar/covoar.cc | 10 +++---
>>  1 file changed, 3 insertions(+), 7 deletions(-)
>>
>> diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
>> index 5c87402..c6b0589 100644
>> --- a/tester/covoar/covoar.cc
>> +++ b/tester/covoar/covoar.cc
>> @@ -75,7 +75,7 @@ static void createBuildPath(Executables&
>> executablesToAnalyze,
>>  if (buildPrefix.empty()) {
>>buildPrefix = *pri;
>>  } else {
>> -  if (buildBSP != *pri) {
>> +  if (buildPrefix != *pri) {
>>  fail = "executable build prefix does not match: " +
>> buildPrefix;
>>  break;
>>}
>> @@ -97,7 +97,7 @@ static void createBuildPath(Executables&
>> executablesToAnalyze,
>>  if (buildPath.empty()) {
>>buildPath = thisBuildPath;
>>  } else {
>> -  if (buildBSP != *pri) {
>> +  if (buildPath != thisBuildPath) {
>>  fail = "executable build path does not match: " + buildPath;
>>}
>>  }
>> @@ -316,11 +316,7 @@ int main(
>>  std::cerr << "warning: Unable to read executable: " << argv[i]
>> << std::endl;
>>} else {
>>  coverageFileName = argv[i];
>> -coverageFileName.replace(
>> -  coverageFileName.length() - executableExtension.size(),
>> -  executableExtension.size(),
>> -  coverageExtension
>> -);
>> +coverageFileName.append( "." + coverageExtension );
>>
>>  if (!FileIsReadable( coverageFileName.c_str() )) {
>>std::cerr << "warning: Unable to read coverage file: " <<
>> coverageFileName
>> --
>> 2.7.4
>>
>> ___
>> 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: gcov support in Covoar

[Vijay Kumar Banerjee]

On 14 May 2018 at 21:21, Joel Sherrill  wrote:

>
>
> On Mon, May 14, 2018 at 10:19 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Hello,
>>
>> The coverage report is showing some data now (txt only). There is still
>> some work needed to be done for it to get merged with the main repo. As it
>> depends on the ongoing work on the covoar.cc and coverage.py, meanwhile I
>> want to get started with the gcov support in covoar as I already have some
>> coverage data in txt format to compare with .
>>
>> I would like to know the following points to get started:
>>
>> 1. What is the current state of the gcov support in covoar. I can see
>> work on GcovData and GcovFunction data in covoar, what's the current status
>> of it ?
>>
>
> Technically unknown, potentially bit rotted.
>
Seems like it will take some time before it starts making sense .

>
>
>>
>> 2. Did it use to run at some point? seeing it in action will be very
>> helpful.
>>
>
> It used to produce .gcov files that could be processed by gcov and produce
> reports.
>
Then our very first objective is to get the .gcov file output only then can
we proceed with the  discripancies

>
> Once you started to compare the reports to the native reports from covoar,
> you would sometimes see places that covoar thought some code was executed
> that did not show up in the gcov generated report. When I investigated, I
> got far enough to know we had executed the code in question.
>
>
>>
>> 3. What are the listed blockers rn ? Other than the reliability of
>> the report .
>>
>
> That's it. Get it working and then let's work on automation, use of lcov,
> etc. Along the way, I am sure we will spot the difference in reporting.
> Then that will have to be fixed.
>
>
>> 4. are there any tickets related to gcov?
>>
>
> Not from RTEMS' perspective.
>
> One challenge we had previously is that the .gcov file format was only
> documented in the header file. That was why I asked for someone from the
> gcc community to help us once we spot difference. Hopefully they can help
> us figure out what is wrong with the file covoar is producing.
>

>> Please add any suggestions or references that might help me get started
>> properly .
>>
>> Thank you,
>>
>> Vijay
>>
>>
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: x86_64 port and BSP (GSoC 2018)

[Joel Sherrill]

On Mon, May 14, 2018 at 10:20 AM, Gedare Bloom  wrote:

> On Mon, May 14, 2018 at 9:30 AM, Sebastian Huber
>  wrote:
> > On 14/05/18 15:20, Amaan Cheval wrote:
> >>
> >> For now, do we all agree to x86_64 as the arch, and x86_64_generic as
> the
> >> BSP?
> >
> >
> > I would drop the _generic. I don't think there will be a non-generic BSP
> on
> > this architecture.
> >
>
> I agree. Use x86_64 for the arch. The BSP name can also be x86_64, or
> a variant of the generic such as (please don't hit me): amd64, x86 :)
>

amd64's not awful. :)

Another direction which is dated now but I think FreeBSD has directories
with these names is the "PCxxx" standards. These are the PC System
Design Guide editions from Intel and Microsoft.

https://en.wikipedia.org/wiki/PC_System_Design_Guide

Unfortunately, the last was PC2001.

http://tech-insider.org/windows/research/2000/1102.html

But that predates UEFI so wouldn't be the best option.

The PCxxx specifications show that the PC evolved slowly but has had
changes over the years. Don't assume that just because some peripherals
are part of the "CPU" component now that they aren't shared or won't
change in the future. For example, the PC/AT included the cascaded
part of i8259s which are still emulated today in "legacy" mode. However,
the APIC is the preferred interrupt controller now and it has been through
a couple of revisions as I recall.  This is leading up to putting this
support
code in bsps/x86_64/shared and have BSP variants use various combinations.
You could start with a "legacy" BSP (bad name) which uses old style
interrupts, etc. As more code for "non-legacy" comes into being, use
it in another BSP variant.

--joel


>
>
> >
> > --
> > 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
> ___
> 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: gcov support in Covoar

[Joel Sherrill]

On Mon, May 14, 2018 at 10:19 AM, Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

> Hello,
>
> The coverage report is showing some data now (txt only). There is still
> some work needed to be done for it to get merged with the main repo. As it
> depends on the ongoing work on the covoar.cc and coverage.py, meanwhile I
> want to get started with the gcov support in covoar as I already have some
> coverage data in txt format to compare with .
>
> I would like to know the following points to get started:
>
> 1. What is the current state of the gcov support in covoar. I can see
> work on GcovData and GcovFunction data in covoar, what's the current status
> of it ?
>

Technically unknown, potentially bit rotted.


>
> 2. Did it use to run at some point? seeing it in action will be very
> helpful.
>

It used to produce .gcov files that could be processed by gcov and produce
reports.

Once you started to compare the reports to the native reports from covoar,
you would sometimes see places that covoar thought some code was executed
that did not show up in the gcov generated report. When I investigated, I
got far enough to know we had executed the code in question.


>
> 3. What are the listed blockers rn ? Other than the reliability of the
> report .
>

That's it. Get it working and then let's work on automation, use of lcov,
etc. Along the way, I am sure we will spot the difference in reporting.
Then that will have to be fixed.


> 4. are there any tickets related to gcov?
>

Not from RTEMS' perspective.

One challenge we had previously is that the .gcov file format was only
documented in the header file. That was why I asked for someone from the
gcc community to help us once we spot difference. Hopefully they can help
us figure out what is wrong with the file covoar is producing.

>
> Please add any suggestions or references that might help me get started
> properly .
>
> Thank you,
>
> Vijay
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Joel Sherrill]

I'll commit this once there is a log message. :)

On Sun, May 13, 2018 at 3:45 PM, Cillian O'Donnell 
wrote:

> ---
>  tester/covoar/covoar.cc | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
> index 5c87402..c6b0589 100644
> --- a/tester/covoar/covoar.cc
> +++ b/tester/covoar/covoar.cc
> @@ -75,7 +75,7 @@ static void createBuildPath(Executables&
> executablesToAnalyze,
>  if (buildPrefix.empty()) {
>buildPrefix = *pri;
>  } else {
> -  if (buildBSP != *pri) {
> +  if (buildPrefix != *pri) {
>  fail = "executable build prefix does not match: " +
> buildPrefix;
>  break;
>}
> @@ -97,7 +97,7 @@ static void createBuildPath(Executables&
> executablesToAnalyze,
>  if (buildPath.empty()) {
>buildPath = thisBuildPath;
>  } else {
> -  if (buildBSP != *pri) {
> +  if (buildPath != thisBuildPath) {
>  fail = "executable build path does not match: " + buildPath;
>}
>  }
> @@ -316,11 +316,7 @@ int main(
>  std::cerr << "warning: Unable to read executable: " << argv[i] <<
> std::endl;
>} else {
>  coverageFileName = argv[i];
> -coverageFileName.replace(
> -  coverageFileName.length() - executableExtension.size(),
> -  executableExtension.size(),
> -  coverageExtension
> -);
> +coverageFileName.append( "." + coverageExtension );
>
>  if (!FileIsReadable( coverageFileName.c_str() )) {
>std::cerr << "warning: Unable to read coverage file: " <<
> coverageFileName
> --
> 2.7.4
>
> ___
> 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: BSPs with Same Name, Different Architecture

[Joel Sherrill]

On Mon, May 14, 2018, 10:16 AM Gedare Bloom  wrote:

> This is an excellent rule. BSP names should be unique.
>

I am not sure the current logic ensures that but it did break one of my
name reuses.


> On Mon, May 14, 2018 at 8:36 AM, Joel Sherrill  wrote:
> > Hi
> >
> > Just a note that I had used the BSP name deos for three architectures.
> This
> > worked until Chris added the BSP/architecture check.
> >
> > I am ok with the rule thank a bsp name is unique across all architectures
> > but wanted to make sure this was a conscious rule now.
> >
> > --joel
> >
> > ___
> > 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: x86_64 port and BSP (GSoC 2018)

[Gedare Bloom]

On Mon, May 14, 2018 at 9:30 AM, Sebastian Huber
 wrote:
> On 14/05/18 15:20, Amaan Cheval wrote:
>>
>> For now, do we all agree to x86_64 as the arch, and x86_64_generic as the
>> BSP?
>
>
> I would drop the _generic. I don't think there will be a non-generic BSP on
> this architecture.
>

I agree. Use x86_64 for the arch. The BSP name can also be x86_64, or
a variant of the generic such as (please don't hit me): amd64, x86 :)


>
> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

gcov support in Covoar

[Vijay Kumar Banerjee]

Hello,

The coverage report is showing some data now (txt only). There is still
some work needed to be done for it to get merged with the main repo. As it
depends on the ongoing work on the covoar.cc and coverage.py, meanwhile I
want to get started with the gcov support in covoar as I already have some
coverage data in txt format to compare with .

I would like to know the following points to get started:

1. What is the current state of the gcov support in covoar. I can see
work on GcovData and GcovFunction data in covoar, what's the current status
of it ?

2. Did it use to run at some point? seeing it in action will be very
helpful.

3. What are the listed blockers rn ? Other than the reliability of the
report .
4. are there any tickets related to gcov?

Please add any suggestions or references that might help me get started
properly .

Thank you,

Vijay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BSPs with Same Name, Different Architecture

[Gedare Bloom]

This is an excellent rule. BSP names should be unique.

On Mon, May 14, 2018 at 8:36 AM, Joel Sherrill  wrote:
> Hi
>
> Just a note that I had used the BSP name deos for three architectures. This
> worked until Chris added the BSP/architecture check.
>
> I am ok with the rule thank a bsp name is unique across all architectures
> but wanted to make sure this was a conscious rule now.
>
> --joel
>
> ___
> 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: GSOC Weekly IRC Meetings

[Gedare Bloom]

Sebastian,

I understand. For this Wed meeting it is only important that all the
students attend to provide their mid-week status update.

I also like your suggestion to your student to provide a Monday
update/plan for the week to the devel@ mailing list. I will encourage
this for all students.

Gedare

On Mon, May 14, 2018 at 1:49 AM, Sebastian Huber
 wrote:
> Hello,
>
> this is 16:00 in UTC+2, which means I am always in a local train during that
> time. So, I cannot attend.
>
> --
> 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

[PATCH] bsp/powerpc: Remove wildcards in linkcmds.base

[Sebastian Huber]

This reverts commit 40c623a883da5dd80e4599cf4cd14097834706bd.

The use of postfix wildcards, e.g. of the form "*.x" is dangerous since
it circumvents the standard matching rules for sections.

Unknown input sections should be added explicitly to the desired output
section via "x.*" wildcards.

Update #3307.
---
 bsps/powerpc/shared/start/linkcmds.base | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bsps/powerpc/shared/start/linkcmds.base 
b/bsps/powerpc/shared/start/linkcmds.base
index e0dfdcc914..25a6414855 100644
--- a/bsps/powerpc/shared/start/linkcmds.base
+++ b/bsps/powerpc/shared/start/linkcmds.base
@@ -100,10 +100,10 @@ SECTIONS {
*(.eh_frame_hdr)
} > REGION_RODATA AT > REGION_RODATA_LOAD
.eh_frame : ALIGN_WITH_INPUT {
-   KEEP (*(*.eh_frame))
+   KEEP (*(.eh_frame))
} > REGION_RODATA AT > REGION_RODATA_LOAD
.gcc_except_table : ALIGN_WITH_INPUT {
-   *(.gcc_except_table *.gcc_except_table.*)
+   *(.gcc_except_table .gcc_except_table.*)
} > REGION_RODATA AT > REGION_RODATA_LOAD
.tdata : ALIGN_WITH_INPUT {
_TLS_Data_begin = .;
@@ -260,7 +260,7 @@ SECTIONS {
*(set_domain_*);
*(set_pseudo_*);
 
-   KEEP (*(SORT(*.rtemsroset.*)))
+   KEEP (*(SORT(.rtemsroset.*)))
bsp_section_rodata_end = .;
} > REGION_RODATA AT > REGION_RODATA_LOAD
bsp_section_rodata_size = bsp_section_rodata_end - 
bsp_section_rodata_begin;
-- 
2.12.3

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 2/3] libchip: Use rtems_blkdev_create()

[Sebastian Huber]

Update #3358.
---
 bsps/shared/dev/i2c/spi-sd-card.c | 58 ++-
 1 file changed, 15 insertions(+), 43 deletions(-)

diff --git a/bsps/shared/dev/i2c/spi-sd-card.c 
b/bsps/shared/dev/i2c/spi-sd-card.c
index a343f7faa8..bf8ed403a5 100644
--- a/bsps/shared/dev/i2c/spi-sd-card.c
+++ b/bsps/shared/dev/i2c/spi-sd-card.c
@@ -5,12 +5,13 @@
  */
 
 /*
- * Copyright (c) 2008
- * Embedded Brains GmbH
- * Obere Lagerstr. 30
- * D-82178 Puchheim
- * Germany
- * rt...@embedded-brains.de
+ * Copyright (c) 2008, 2018 embedded brains GmbH
+ *
+ *  embedded brains GmbH
+ *  Dornierstr. 4
+ *  82178 Puchheim
+ *  Germany
+ *  
  *
  * The license and distribution terms for this file may be
  * found in the file LICENSE in this distribution or at
@@ -25,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -1238,11 +1238,9 @@ sd_card_disk_block_write_cleanup:
 
 static int sd_card_disk_ioctl( rtems_disk_device *dd, uint32_t req, void *arg)
 {
-   RTEMS_DEBUG_PRINT( "sd_card_disk_ioctl minor = %u, req = 0x%08x, arg = 
%p\n",
-   (unsigned)rtems_filesystem_dev_minor_t(dd->dev), 
(unsigned)req, arg);
+   RTEMS_DEBUG_PRINT( "sd_card_disk_ioctl req = 0x%08x, arg = %p\n", 
(unsigned)req, arg);
if (req == RTEMS_BLKIO_REQUEST) {
-   rtems_device_minor_number minor = rtems_disk_get_minor_number( 
dd);
-   sd_card_driver_entry *e = _card_driver_table [minor];
+   sd_card_driver_entry *e = rtems_disk_get_driver_data( dd);
rtems_blkdev_request *r = (rtems_blkdev_request *) arg;
int (*f)( sd_card_driver_entry *, rtems_blkdev_request *);
uint32_t retries = e->retries;
@@ -1272,18 +1270,14 @@ static int sd_card_disk_ioctl( rtems_disk_device *dd, 
uint32_t req, void *arg)
}
 }
 
-static rtems_status_code sd_card_disk_init( rtems_device_major_number major, 
rtems_device_minor_number minor, void *arg)
+rtems_status_code sd_card_register( void)
 {
-   rtems_status_code sc = RTEMS_SUCCESSFUL;
-
-   /* Initialize disk IO */
-   sc = rtems_disk_io_initialize();
-   RTEMS_CHECK_SC( sc, "Initialize RTEMS disk IO");
+   size_t i;
 
-   for (minor = 0; minor < sd_card_driver_table_size; ++minor) {
-   sd_card_driver_entry *e = _card_driver_table [minor];
-   dev_t dev = rtems_filesystem_make_dev_t( major, minor);
+   for (i = 0; i < sd_card_driver_table_size; ++i) {
+   sd_card_driver_entry *e = _card_driver_table [i];
uint32_t retries = e->retries;
+   rtems_status_code sc;
 
/* Initialize SD Card */
do {
@@ -1292,31 +1286,9 @@ static rtems_status_code sd_card_disk_init( 
rtems_device_major_number major, rte
RTEMS_CHECK_SC( sc, "Initialize SD Card");
 
/* Create disk device */
-   sc = rtems_disk_create_phys( dev, e->block_size, 
e->block_number, sd_card_disk_ioctl, NULL, e->device_name);
+   sc = rtems_blkdev_create( e->device_name, e->block_size, 
e->block_number, sd_card_disk_ioctl, NULL);
RTEMS_CHECK_SC( sc, "Create disk device");
}
 
return RTEMS_SUCCESSFUL;
 }
-
-/** @} */
-
-static const rtems_driver_address_table sd_card_disk_ops = {
-   .initialization_entry = sd_card_disk_init,
-   .open_entry = rtems_blkdev_generic_open,
-   .close_entry = rtems_blkdev_generic_close,
-   .read_entry = rtems_blkdev_generic_read,
-   .write_entry = rtems_blkdev_generic_write,
-   .control_entry = rtems_blkdev_generic_ioctl
-};
-
-rtems_status_code sd_card_register( void)
-{
-   rtems_status_code sc = RTEMS_SUCCESSFUL;
-   rtems_device_major_number major = 0;
-
-   sc = rtems_io_register_driver( 0, _card_disk_ops, );
-   RTEMS_CHECK_SC( sc, "Register disk SD Card driver");
-
-   return RTEMS_SUCCESSFUL;
-}
-- 
2.12.3

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 1/3] libblock: Init deps in rtems_blkdev_create()

[Sebastian Huber]

Update #3358.
---
 cpukit/include/rtems/blkdev.h  |  1 +
 cpukit/libblock/src/blkdev-imfs.c  | 14 ++
 testsuites/libtests/block17/init.c | 10 --
 3 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/cpukit/include/rtems/blkdev.h b/cpukit/include/rtems/blkdev.h
index 3f829e6068..929cf4fc24 100644
--- a/cpukit/include/rtems/blkdev.h
+++ b/cpukit/include/rtems/blkdev.h
@@ -296,6 +296,7 @@ rtems_blkdev_ioctl(rtems_disk_device *dd, uint32_t req, 
void *argp);
  * @retval RTEMS_INVALID_NUMBER Media block size or count is not positive.
  * @retval RTEMS_NO_MEMORY Not enough memory.
  * @retval RTEMS_UNSATISFIED Cannot create generic device node.
+ * @retval RTEMS_INCORRECT_STATE Cannot initialize bdbuf.
  *
  * @see rtems_blkdev_create_partition(), rtems_bdbuf_set_block_size(), and
  * rtems_blkdev_request.
diff --git a/cpukit/libblock/src/blkdev-imfs.c 
b/cpukit/libblock/src/blkdev-imfs.c
index ebe6ebb1d7..a46babb593 100644
--- a/cpukit/libblock/src/blkdev-imfs.c
+++ b/cpukit/libblock/src/blkdev-imfs.c
@@ -6,10 +6,10 @@
  */
 
 /*
- * Copyright (c) 2012 embedded brains GmbH.  All rights reserved.
+ * Copyright (c) 2012, 2018 embedded brains GmbH.  All rights reserved.
  *
  *  embedded brains GmbH
- *  Obere Lagerstr. 30
+ *  Dornierstr. 4
  *  82178 Puchheim
  *  Germany
  *  
@@ -279,9 +279,15 @@ rtems_status_code rtems_blkdev_create(
   void *driver_data
 )
 {
-  rtems_status_code sc = RTEMS_SUCCESSFUL;
-  rtems_blkdev_imfs_context *ctx = malloc(sizeof(*ctx));
+  rtems_status_code sc;
+  rtems_blkdev_imfs_context *ctx;
+
+  sc = rtems_bdbuf_init();
+  if (sc != RTEMS_SUCCESSFUL) {
+return RTEMS_INCORRECT_STATE;
+  }
 
+  ctx = malloc(sizeof(*ctx));
   if (ctx != NULL) {
 sc = rtems_disk_init_phys(
   >dd,
diff --git a/testsuites/libtests/block17/init.c 
b/testsuites/libtests/block17/init.c
index d916c738d5..3346c7cf17 100644
--- a/testsuites/libtests/block17/init.c
+++ b/testsuites/libtests/block17/init.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2013 embedded brains GmbH.  All rights reserved.
+ * Copyright (c) 2013, 2018 embedded brains GmbH.  All rights reserved.
  *
  *  embedded brains GmbH
  *  Dornierstr. 4
@@ -17,6 +17,7 @@
 #endif
 
 #include 
+#include 
 
 #include "tmacros.h"
 
@@ -24,8 +25,13 @@ const char rtems_test_name[] = "BLOCK 17";
 
 static void test(void)
 {
-  rtems_status_code sc = rtems_bdbuf_init();
+  rtems_status_code sc;
+
+  sc = rtems_bdbuf_init();
   rtems_test_assert(sc == RTEMS_INVALID_NUMBER);
+
+  sc = rtems_blkdev_create(NULL, 0, 0, NULL, NULL);
+  rtems_test_assert(sc == RTEMS_INCORRECT_STATE);
 }
 
 static void Init(rtems_task_argument arg)
-- 
2.12.3

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 3/3] libtests/block05: Use rtems_blkdev_create()

[Sebastian Huber]

Update #3358.
---
 testsuites/libtests/block05/init.c | 47 --
 1 file changed, 25 insertions(+), 22 deletions(-)

diff --git a/testsuites/libtests/block05/init.c 
b/testsuites/libtests/block05/init.c
index c20ccbf20d..79616276de 100644
--- a/testsuites/libtests/block05/init.c
+++ b/testsuites/libtests/block05/init.c
@@ -7,10 +7,10 @@
  */
 
 /*
- * Copyright (c) 2009-2012 embedded brains GmbH.  All rights reserved.
+ * Copyright (c) 2009, 2018 embedded brains GmbH.  All rights reserved.
  *
  *  embedded brains GmbH
- *  Obere Lagerstr. 30
+ *  Dornierstr. 4
  *  82178 Puchheim
  *  Germany
  *  
@@ -24,14 +24,17 @@
 #include "config.h"
 #endif
 
-#include "tmacros.h"
-#include 
+#include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
 #include 
-#include 
+#include 
+
+#include 
 
 const char rtems_test_name[] = "BLOCK 5";
 
@@ -394,32 +397,33 @@ static int disk_ioctl(rtems_disk_device *dd, uint32_t 
req, void *argp)
 }
 
 static void disk_register(
+  const char *dev,
   uint32_t block_size,
   rtems_blkdev_bnum block_count,
   rtems_disk_device **dd_ptr
 )
 {
-  rtems_status_code sc = RTEMS_SUCCESSFUL;
-  rtems_device_major_number major = 0;
-  dev_t dev = 0;
-
-  sc = rtems_io_register_driver(0, _ops, );
-  ASSERT_SC(sc);
+  rtems_status_code sc;
+  int rv;
+  int fd;
 
-  dev = rtems_filesystem_make_dev_t(major, 0);
-
-  sc = rtems_disk_create_phys(
+  sc = rtems_blkdev_create(
 dev,
 block_size,
 block_count,
 disk_ioctl,
-NULL,
 NULL
   );
   ASSERT_SC(sc);
 
-  *dd_ptr = rtems_disk_obtain(dev);
-  rtems_test_assert(*dd_ptr!= NULL);
+  fd = open(dev, O_RDWR);
+  rtems_test_assert(rv >= 0);
+
+  rv = rtems_disk_fd_get_disk_device(fd, dd_ptr);
+  rtems_test_assert(rv == 0);
+
+  rv = close(fd);
+  rtems_test_assert(rv == 0);
 }
 
 static rtems_task Init(rtems_task_argument argument)
@@ -431,12 +435,9 @@ static rtems_task Init(rtems_task_argument argument)
 
   task_id_init = rtems_task_self();
 
-  sc = rtems_disk_io_initialize();
-  ASSERT_SC(sc);
-
-  disk_register(BLOCK_SIZE_A, BLOCK_COUNT_A, _a);
+  disk_register("dd_b", BLOCK_SIZE_A, BLOCK_COUNT_A, _a);
 
-  disk_register(BLOCK_SIZE_B, BLOCK_COUNT_B, _b);
+  disk_register("dd_a", BLOCK_SIZE_B, BLOCK_COUNT_B, _b);
 
   sc = rtems_task_create(
 rtems_build_name(' ', 'L', 'O', 'W'),
@@ -517,6 +518,8 @@ static rtems_task Init(rtems_task_argument argument)
 #define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
 
+#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 5
+
 #define CONFIGURE_MAXIMUM_TASKS 4
 #define CONFIGURE_MAXIMUM_DRIVERS 4
 
-- 
2.12.3

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: x86_64 port and BSP (GSoC 2018)

[Sebastian Huber]

On 14/05/18 15:20, Amaan Cheval wrote:

For now, do we all agree to x86_64 as the arch, and x86_64_generic as the BSP?


I would drop the _generic. I don't think there will be a non-generic BSP 
on this architecture.


--
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: x86_64 port and BSP (GSoC 2018)

[Amaan Cheval]

On Mon, May 14, 2018 at 6:08 PM, Sebastian Huber
 wrote:
> On 14/05/18 14:34, Joel Sherrill wrote:
>>
>>
>>
>> On Mon, May 14, 2018, 7:12 AM Sebastian Huber
>> > > wrote:
>>
>> On 14/05/18 14:09, Joel Sherrill wrote:
>> > On Mon, May 14, 2018, 7:07 AM Sebastian Huber
>> > > 
>> > > >> wrote:
>> >
>> > On 14/05/18 13:14, Amaan Cheval wrote:
>> > > Regarding naming, how about we settle on something like
>> > > "bsps/amd64/amd64_generic", borrowing from how the riscv
>> target is
>> > > structured?
>> >
>> > In case you want to name the new architecture "amd64", then
>> the tool
>> > chain should be renamed as well, currently we have
>> > x86_64-rtems5-gcc, etc.
>> >
>> >
>> > The target is picked after the GNU target name. We have always
>> agreed
>> > with the GNU target name.
>>
>> Ok, makes sense. Will the new stuff support the 32-bit instruction
>> set?
>>
>>
>> I have no idea. On a native Linux or BSD toolset, does -m32 produce the
>> same 32 bit ABI code as i386-elf?
>>
>> I am pretty sure our x86_64 toolset does not have the 32 bit multilibs.

+1 from cursory checks earlier, they don't.

>>
>> In fairness, even though x86_64 appears to be the canonical name, maybe
>> amd64 is an acceptable alias. Internally, the tools use x86_64 though.
>>
>> I would prefer to stick to the canonical name internally.
>
>
> All targets use the canonical name up to now (riscv is a small exception
> with riscv32 and riscv64). I would not make an exception for the current
> Intel architecture invented by AMD. Either name it x86 (if there is a
> potential 32-bit support, why would you use it?) or x86_64.
>

Naming it x86 right now, with 32-bit support not being in the scope of
the summer's project at the moment would only cause confusion IMO,
since we'd have both i386 and x86. In the situation that we do want to
add multilib support and whatnot, we can rename later and make x86_64
a BSP within the x86 arch, right?

For now, do we all agree to x86_64 as the arch, and x86_64_generic as the BSP?

>
> --
> 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: x86_64 port and BSP (GSoC 2018)

[Sebastian Huber]

On 14/05/18 14:34, Joel Sherrill wrote:



On Mon, May 14, 2018, 7:12 AM Sebastian Huber 
> wrote:


On 14/05/18 14:09, Joel Sherrill wrote:
> On Mon, May 14, 2018, 7:07 AM Sebastian Huber
> 
> >> wrote:
>
>     On 14/05/18 13:14, Amaan Cheval wrote:
>     > Regarding naming, how about we settle on something like
>     > "bsps/amd64/amd64_generic", borrowing from how the riscv
target is
>     > structured?
>
>     In case you want to name the new architecture "amd64", then
the tool
>     chain should be renamed as well, currently we have
>     x86_64-rtems5-gcc, etc.
>
>
> The target is picked after the GNU target name. We have always
agreed
> with the GNU target name.

Ok, makes sense. Will the new stuff support the 32-bit instruction
set?


I have no idea. On a native Linux or BSD toolset, does -m32 produce 
the same 32 bit ABI code as i386-elf?


I am pretty sure our x86_64 toolset does not have the 32 bit multilibs.

In fairness, even though x86_64 appears to be the canonical name, 
maybe amd64 is an acceptable alias. Internally, the tools use x86_64 
though.


I would prefer to stick to the canonical name internally.


All targets use the canonical name up to now (riscv is a small exception 
with riscv32 and riscv64). I would not make an exception for the current 
Intel architecture invented by AMD. Either name it x86 (if there is a 
potential 32-bit support, why would you use it?) or x86_64.


--
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

BSPs with Same Name, Different Architecture

[Joel Sherrill]

Hi

Just a note that I had used the BSP name deos for three architectures. This
worked until Chris added the BSP/architecture check.

I am ok with the rule thank a bsp name is unique across all architectures
but wanted to make sure this was a conscious rule now.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: x86_64 port and BSP (GSoC 2018)

[Joel Sherrill]

On Mon, May 14, 2018, 7:12 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 14/05/18 14:09, Joel Sherrill wrote:
> > On Mon, May 14, 2018, 7:07 AM Sebastian Huber
> >  > > wrote:
> >
> > On 14/05/18 13:14, Amaan Cheval wrote:
> > > Regarding naming, how about we settle on something like
> > > "bsps/amd64/amd64_generic", borrowing from how the riscv target is
> > > structured?
> >
> > In case you want to name the new architecture "amd64", then the tool
> > chain should be renamed as well, currently we have
> > x86_64-rtems5-gcc, etc.
> >
> >
> > The target is picked after the GNU target name. We have always agreed
> > with the GNU target name.
>
> Ok, makes sense. Will the new stuff support the 32-bit instruction set?
>

I have no idea. On a native Linux or BSD toolset, does -m32 produce the
same 32 bit ABI code as i386-elf?

I am pretty sure our x86_64 toolset does not have the 32 bit multilibs.

In fairness, even though x86_64 appears to be the canonical name, maybe
amd64 is an acceptable alias. Internally, the tools use x86_64 though.

I would prefer to stick to the canonical name internally.



> --
> 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: x86_64 port and BSP (GSoC 2018)

[Sebastian Huber]

On 14/05/18 14:09, Joel Sherrill wrote:
On Mon, May 14, 2018, 7:07 AM Sebastian Huber 
> wrote:


On 14/05/18 13:14, Amaan Cheval wrote:
> Regarding naming, how about we settle on something like
> "bsps/amd64/amd64_generic", borrowing from how the riscv target is
> structured?

In case you want to name the new architecture "amd64", then the tool
chain should be renamed as well, currently we have
x86_64-rtems5-gcc, etc.


The target is picked after the GNU target name. We have always agreed 
with the GNU target name.


Ok, makes sense. Will the new stuff support the 32-bit instruction set?

--
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: x86_64 port and BSP (GSoC 2018)

[Joel Sherrill]

On Mon, May 14, 2018, 7:07 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 14/05/18 13:14, Amaan Cheval wrote:
> > Regarding naming, how about we settle on something like
> > "bsps/amd64/amd64_generic", borrowing from how the riscv target is
> > structured?
>
> In case you want to name the new architecture "amd64", then the tool
> chain should be renamed as well, currently we have x86_64-rtems5-gcc, etc.
>

The target is picked after the GNU target name. We have always agreed with
the GNU target name.


> Since this is a plug and play architecture there should be only one BSP
> family. I would name it identical to the architecture name.
>
> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: x86_64 port and BSP (GSoC 2018)

[Sebastian Huber]

On 14/05/18 13:14, Amaan Cheval wrote:

Regarding naming, how about we settle on something like
"bsps/amd64/amd64_generic", borrowing from how the riscv target is
structured?


In case you want to name the new architecture "amd64", then the tool 
chain should be renamed as well, currently we have x86_64-rtems5-gcc, etc.


Since this is a plug and play architecture there should be only one BSP 
family. I would name it identical to the architecture name.


--
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: x86_64 port and BSP (GSoC 2018)

[Amaan Cheval]

Regarding naming, how about we settle on something like
"bsps/amd64/amd64_generic", borrowing from how the riscv target is
structured?

On Tue, May 8, 2018 at 9:02 AM, Chris Johns  wrote:
> On 05/05/2018 04:07, Amaan Cheval wrote:
>> On Fri, May 4, 2018 at 7:03 AM Chris Johns  wrote:
>>
>>> On 03/05/2018 17:09, Amaan Cheval wrote:
 On Thu, May 3, 2018 at 5:56 AM Chris Johns  wrote:

> On 01/05/2018 23:09, Amaan Cheval wrote:
>> Quick update: My x86_64 stub port compiles and can be linked to all
 default
>> tests now! _dance_
>>
>> I've pushed the stub port for the x86_64 to my fork on Github; the
 commits
>> are horribly messy (I did most of the work aiming for the stub to be
>> one
>> commit, then later I realized several commits would make more sense
>> for
>> when I'll have to rebase and catch up with master - TL;DR: ignore the
>> commits, I'll squash and make them make more sense later).
>>
>>

>> https://github.com/AmaanC/rtems/tree/ac/stub-x86-link-tests-pre-bspreorg-bak
>>

> Thanks. Updating to master would be good, lots has changed.

> Why ...

>   bsps/x86_64/i386
>   bsps/x86_64/i386/pc386

> .. ? Can the BSP's layout be simplified to something flatter?


 Definitely - the work so far has been very hacky, leaving a mess all
>> over
 the place to just make note of issues that I'll need to look into in
>> more
 detail. With the rebase to master, I'll be making these changes with a
>> lot
 more thought.
>>
>>> Excellent and thanks.
>>

> I see FreeBSD has amd64, x86 and i386 in src/sys. I do not know what
>> the
> differences are? I run FreeBSD amd64 on Intel devices.


 Not sure of the differences, really. I noticed that earlier too, but
>> I'll
 have to dig into that later.

>>
>>> I briefly looked and it seems the amd64 was more complete.
>>
>>> Do you think we should have bsps/x86_64/amd64 as the BSP?
>>
>>> I think the more generic name of 'amd64' is better than 'pc' plus it
>> aligns us
>>> with the naming other platforms use.
>>
>>
>> Given that amd64/x86_64 refer to the ISAs, not specific processors, I think
>> it's up between these for me:
>>
>> - amd64/pc
>> - x86_64/pc
>
> I would prefer we have a single BSP. If we reach a point these differences are
> important I would be super impressed.
>
>
>> I don't feel strongly about this, but I think the generic "x86_64/pc" may
>> be more technically accurate given that there are some very subtle
>> differences between x86-64 and AMD64, and this port will be tested on
>> generic 64-bit Intel processors.>
>> https://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64
>>
>> What do you think?
>
> When I look at an OS I tend to get the amd64 build for any x86_64
> implementation, maybe this is just my view of things.
>
> These offer amd64 ...
>
> http://mirror.internode.on.net/pub/ubuntu/releases/18.04/
> http://mirror.internode.on.net/pub/FreeBSD/releases/
> http://mirror.internode.on.net/pub/NetBSD/NetBSD-7.1.2/
> http://mirror.internode.on.net/pub/debian/dists/Debian9.4/main/
>
> CentOS and Fedora are different and offer x86_64:
>
> http://mirror.internode.on.net/pub/centos/7.4.1708/isos/x86_64/
> http://mirror.internode.on.net/pub/fedora/linux/releases/28/Everything/x86_64/
>
> macOS (darwin) is x86_64:
>
> $ uname -a
> Darwin mohua 17.5.0 Darwin Kernel Version 17.5.0: Mon Mar  5 22:24:32 PST 
> 2018;
> root:xnu-4570.51.1~1/RELEASE_X86_64 x86_64
>
>>
> Is there a build of x86_64 hardware that is _not_ a PC? I think it
>> makes
 sense
> to assume for now we support just a PC and so we can have x86_64/pc. To
 clarify
> this statement, I am sure there are a number VME, CompactPCI and other
> industrial boards which I suspect will be a PC architecture to the
 operating
> systems running on them.

> I would prefer you commit files from the i386/.. tree as they are
>> merged,
 tested
> and cleaned up rather than dumping in the existing PC BSP into the new
 BSP. For
> example I would prefer we consider:

>   https://github.com/freebsd/freebsd/tree/master/sys/dev/vt

> for the console for this BSP. The code will have FreeBSD kernel
 dependencies
> which can be wrapped or compiled out. Please consider following the
>> rules
 we use
> for adding and changing FreeBSD source in libbsd, it would help us
>> track
 FreeBSD
> in the future. I would also consider adding this code to x86_64/dev/vt
 and have
> the x86_64/pc BSP reference it.
>>
>> What do you think about x86_64/contrib/dev/vt etc. instead and then have
>> x86_64/pc reference it? Sounds good to me.
>
> Contrib as opposed too what other type of sources? I think we will have a lot 
> of
> contributed code in this BSP given the mature base of existing code. My 
> concern
> 

Re: [PATCH] no_cpu/no_bsp: Fix path to bspgetworkarea-default.c in Makefile

[Sebastian Huber]

I checked in the patch with a shortened commit message.

--
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

[GSoC] Procedure for linker script of new port

[Amaan Cheval]

Hi!

We discussed this briefly in a thread earlier[1], but I'd like more
definitive advice if possible. What are the things to keep in mind
when designing the linker script for a new port? As far as I can tell,
I can just use the default one (as shown by "x86_64-rtems5-ld
--verbose") with a few modifications to:

- Try to offload the things bsp_specs does into the linker script, as
Joel requested[2].
- Add configuration parameters if required (I see this on other
architectures, for eg. bsp_stack_irq_size on
./*/arm/shared/startup/linkcmds.base).

Is there anything else to keep in mind? I believe not, but I figured
I'd confirm.

[1] https://lists.rtems.org/pipermail/devel/2018-April/021050.html
[2] https://lists.rtems.org/pipermail/devel/2018-May/021430.html
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] x86_64/gcc: Have gcc build crti.o and crtn.o

[Sebastian Huber]

On 14/05/18 11:06, Amaan Cheval wrote:

Hey, Chris! Just thought I'd remind you of this pending patch in case
it slipped through the cracks. Let me know if you'd like any changes!


I checked in the patch.

--
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: [PATCH] no_cpu/no_bsp: Fix path to bspgetworkarea-default.c in Makefile

[Amaan Cheval]

Hi!

I figured I'd bump this.

Given that no_bsp serves as the reference BSP, I think we ought to
keep it relatively updated (more than what this patch does too, which
I'll look into if I have the bandwidth along with the x86-64 port).
That way creating a new BSP with parts based on no_bsp should be
easier (for eg. a new arch + BSP from scratch).
Would you all agree?

On Mon, Apr 30, 2018 at 10:04 PM, Amaan Cheval  wrote:
> ---
>  c/src/lib/libbsp/no_cpu/no_bsp/Makefile.am | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/c/src/lib/libbsp/no_cpu/no_bsp/Makefile.am 
> b/c/src/lib/libbsp/no_cpu/no_bsp/Makefile.am
> index e4c11f6f5a..a9d69067b7 100644
> --- a/c/src/lib/libbsp/no_cpu/no_bsp/Makefile.am
> +++ b/c/src/lib/libbsp/no_cpu/no_bsp/Makefile.am
> @@ -14,7 +14,7 @@ librtemsbsp_a_SOURCES =
>
>  # startup
>  librtemsbsp_a_SOURCES += 
> ../../../../../../bsps/shared/start/bspfatal-default.c
> -librtemsbsp_a_SOURCES += ../../../../../../bsps/shared/start/bspgetworkarea.c
> +librtemsbsp_a_SOURCES += 
> ../../../../../../bsps/shared/start/bspgetworkarea-default.c
>  librtemsbsp_a_SOURCES += 
> ../../../../../../bsps/no_cpu/no_bsp/start/bspstart.c
>  librtemsbsp_a_SOURCES += ../../../../../../bsps/shared/start/sbrk.c
>  librtemsbsp_a_SOURCES += 
> ../../../../../../bsps/shared/dev/getentropy/getentropy-cpucounter.c
> --
> 2.16.0.rc0
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] x86_64/gcc: Have gcc build crti.o and crtn.o

[Amaan Cheval]

Hey, Chris! Just thought I'd remind you of this pending patch in case
it slipped through the cracks. Let me know if you'd like any changes!

On Tue, May 8, 2018 at 11:23 PM, Amaan Cheval  wrote:
> The original commit in GCC's repo is here:
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ab55f7db3694293e4799d58f7e1a556c0eae863a
>
> We need this to be able to use crti.o and crtn.o in the bsp_specs file for the
> port, and therefore provide missing symbols like "_fini" which RTEMS assumes 
> are
> defined in:
>
> ./cpukit/libcsupport/src/newlibc_exit.c
> ---
>  rtems/config/5/rtems-x86_64.bset | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/rtems/config/5/rtems-x86_64.bset 
> b/rtems/config/5/rtems-x86_64.bset
> index 951ae85..9b92538 100644
> --- a/rtems/config/5/rtems-x86_64.bset
> +++ b/rtems/config/5/rtems-x86_64.bset
> @@ -8,4 +8,10 @@
>  %patch add gcc --rsb-file=gcc-99c7ae16793d88d7c16c692fb468ab308cb4d12d.patch 
> https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff_plain;f=gcc/config.gcc;h=99c7ae16793d88d7c16c692fb468ab308cb4d12d;hp=ae19655bf328e29ea4f00966b5060967684a7f1b;hb=602fa1e9d3ea5e87d4d6e17e3e91fc2647e42da3;hpb=7ea6a6472d360c634a00358dbaab2e236e785367
>  %hash sha512 gcc-99c7ae16793d88d7c16c692fb468ab308cb4d12d.patch 
> ed519aacb199be54bce514bd6745cf532d66250f0163e8be6b6e630d83ec1a68e086467320f589191dce3a7638bdc867663f38dfc569ee2f27c6b686c040130f
>
> +#
> +# Have gcc build crti.o and crtn.o
> +#
> +%patch add gcc --rsb-file=gcc-f8fd78279d353f6959e75ac25571c1b7b2dec110.patch 
> https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff_plain;f=libgcc/config.host;h=f8fd78279d353f6959e75ac25571c1b7b2dec110;hp=11b4acaff55e00ee6bd3c182e9da5dc597ac57c4;hb=ab55f7db3694293e4799d58f7e1a556c0eae863a;hpb=344c180cca810c50f38fd545bb9a102fb39306b7
> +%hash sha512 gcc-f8fd78279d353f6959e75ac25571c1b7b2dec110.patch 
> aef76f9d45a53096a021521375fc302a907f78545cc57683a7a00ec61608b8818115720f605a6b1746f479c8568963b380138520e259cbb9e8951882c2f1567f
> +
>  %include 5/rtems-default.bset
> --
> 2.13.0
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 14 May 2018 at 12:10, Cillian O'Donnell  wrote:

>
>
> On Sun, 13 May 2018, 22:15 Vijay Kumar Banerjee, 
> wrote:
>
>> On 14 May 2018 at 02:15, Cillian O'Donnell  wrote:
>>
>>> ---
>>>  tester/covoar/covoar.cc | 10 +++---
>>>  1 file changed, 3 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
>>> index 5c87402..c6b0589 100644
>>> --- a/tester/covoar/covoar.cc
>>> +++ b/tester/covoar/covoar.cc
>>> @@ -75,7 +75,7 @@ static void createBuildPath(Executables&
>>> executablesToAnalyze,
>>>  if (buildPrefix.empty()) {
>>>buildPrefix = *pri;
>>>  } else {
>>> -  if (buildBSP != *pri) {
>>> +  if (buildPrefix != *pri) {
>>>  fail = "executable build prefix does not match: " +
>>> buildPrefix;
>>>  break;
>>>}
>>> @@ -97,7 +97,7 @@ static void createBuildPath(Executables&
>>> executablesToAnalyze,
>>>  if (buildPath.empty()) {
>>>buildPath = thisBuildPath;
>>>  } else {
>>> -  if (buildBSP != *pri) {
>>> +  if (buildPath != thisBuildPath) {
>>>  fail = "executable build path does not match: " + buildPath;
>>>}
>>>  }
>>> @@ -316,11 +316,7 @@ int main(
>>>  std::cerr << "warning: Unable to read executable: " << argv[i]
>>> << std::endl;
>>>} else {
>>>  coverageFileName = argv[i];
>>> -coverageFileName.replace(
>>> -  coverageFileName.length() - executableExtension.size(),
>>> -  executableExtension.size(),
>>> -  coverageExtension
>>> -);
>>> +coverageFileName.append( "." + coverageExtension );
>>>
>>>  if (!FileIsReadable( coverageFileName.c_str() )) {
>>>std::cerr << "warning: Unable to read coverage file: " <<
>>> coverageFileName
>>> --
>>> 2.7.4
>>>
>>> This worked !
>>
>
> Cool, looks like we're onto fixing the reports then. If you take a look at
> report.html only the headings are there. I think what might be wrong there
> is it's just searching in the wrong place for the results. The fix for that
> will lie in coverage.py. Warning about coverage.py, there could be whole
> sections in there that might just be deleted, it's still being reorganized.
>
> Are you working on it ?
Also the absolute path needs to be parsed form the score-symbol.ini for
running it from out of the build tree

> Or seeing as covoar is in good shape now and I think the txt report is ok
> (you should check and make sure of that). You could move onto gcov, lcov
> stuff. Figure out the state of the gcov support in covoar, generate gcov
> reports, compare the results.
>
I'll creat a new thread for gcov report then.

> ___
>>> 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: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Sun, 13 May 2018, 22:15 Vijay Kumar Banerjee, 
wrote:

> On 14 May 2018 at 02:15, Cillian O'Donnell  wrote:
>
>> ---
>>  tester/covoar/covoar.cc | 10 +++---
>>  1 file changed, 3 insertions(+), 7 deletions(-)
>>
>> diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
>> index 5c87402..c6b0589 100644
>> --- a/tester/covoar/covoar.cc
>> +++ b/tester/covoar/covoar.cc
>> @@ -75,7 +75,7 @@ static void createBuildPath(Executables&
>> executablesToAnalyze,
>>  if (buildPrefix.empty()) {
>>buildPrefix = *pri;
>>  } else {
>> -  if (buildBSP != *pri) {
>> +  if (buildPrefix != *pri) {
>>  fail = "executable build prefix does not match: " +
>> buildPrefix;
>>  break;
>>}
>> @@ -97,7 +97,7 @@ static void createBuildPath(Executables&
>> executablesToAnalyze,
>>  if (buildPath.empty()) {
>>buildPath = thisBuildPath;
>>  } else {
>> -  if (buildBSP != *pri) {
>> +  if (buildPath != thisBuildPath) {
>>  fail = "executable build path does not match: " + buildPath;
>>}
>>  }
>> @@ -316,11 +316,7 @@ int main(
>>  std::cerr << "warning: Unable to read executable: " << argv[i]
>> << std::endl;
>>} else {
>>  coverageFileName = argv[i];
>> -coverageFileName.replace(
>> -  coverageFileName.length() - executableExtension.size(),
>> -  executableExtension.size(),
>> -  coverageExtension
>> -);
>> +coverageFileName.append( "." + coverageExtension );
>>
>>  if (!FileIsReadable( coverageFileName.c_str() )) {
>>std::cerr << "warning: Unable to read coverage file: " <<
>> coverageFileName
>> --
>> 2.7.4
>>
>> This worked !
>

Cool, looks like we're onto fixing the reports then. If you take a look at
report.html only the headings are there. I think what might be wrong there
is it's just searching in the wrong place for the results. The fix for that
will lie in coverage.py. Warning about coverage.py, there could be whole
sections in there that might just be deleted, it's still being reorganized.

Or seeing as covoar is in good shape now and I think the txt report is ok
(you should check and make sure of that). You could move onto gcov, lcov
stuff. Figure out the state of the gcov support in covoar, generate gcov
reports, compare the results.

> ___
>> 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