date:20180317

Hello!

I was trying to set up the sparc/erc32 bsp on a new system and was
following the quickstart on the user manual. Though I have successfully
done this before, this time its throwing an error. PFA the rsb log file
with the error report. I was doing this to run the trace buffering
examples.

Why is the shell command /bin/sh -ex failing?

Regards,
Vidushi
RTEMS Tools Project - Source Builder Error Report
Build: error: building sparc-rtems5-gdb-8.0.1-x86_64-apple-darwin16.7.0-1
Command Line: ../source-builder/sb-set-builder
--prefix=/Users/vidushi/development/rtems/5 5/rtems-sparc
Python: 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 12:01:12) [GCC 4.2.1 (Apple
Inc. build 5666) (dot 3)]

git://git.rtems.org/rtems-source-builder.git/origin/4b3e0f8e3d6998b84a2503dd2e11578989b1672b
Darwin Vidushis-MacBook-Air.local 16.7.0 Darwin Kernel Version 16.7.0: Thu Jan
11 22:59:40 PST 2018; root:xnu-3789.73.8~1/RELEASE_X86_64 x86_64
Tail of the build log:
checking whether rawmemchr is declared without a macro... no
checking whether stpcpy is declared without a macro... yes
checking whether stpncpy is declared without a macro... yes
checking whether strchrnul is declared without a macro... no
checking whether strdup is declared without a macro... yes
checking whether strncat is declared without a macro... yes
checking whether strndup is declared without a macro... yes
checking whether strnlen is declared without a macro... yes
checking whether strpbrk is declared without a macro... yes
checking whether strsep is declared without a macro... yes
checking whether strcasestr is declared without a macro... yes
checking whether strtok_r is declared without a macro... yes
checking whether strerror_r is declared without a macro... yes
checking whether strsignal is declared without a macro... yes
checking whether strverscmp is declared without a macro... no
checking whether strstr works... yes
checking whether strtok_r is declared... (cached) yes
checking whether stat file-mode macros are broken... no
checking for mode_t... yes
checking for a thread-safe mkdir -p...
../../../gdb-8.0.1/gdb/gnulib/../../install-sh -c -d
checking for struct timespec in ... yes
checking whether uses 'inline' correctly... yes
checking for wint_t... yes
checking for alloca as a compiler built-in... yes
checking whether alphasort is declared without a macro... yes
checking whether closedir is declared without a macro... yes
checking whether dirfd is declared without a macro... yes
checking whether fdopendir is declared without a macro... yes
checking whether opendir is declared without a macro... yes
checking whether readdir is declared without a macro... yes
checking whether rewinddir is declared without a macro... yes
checking whether scandir is declared without a macro... yes
checking for dirfd... yes
checking whether dirfd is declared... (cached) yes
checking whether dirfd is a macro... no
checking whether // is distinct from /... (cached) no
checking for flexible array member... yes
checking whether conversion from 'int' to 'long double' works... yes
checking for working GNU fnmatch... no
checking whether isblank is declared... yes
checking whether isblank is declared... (cached) yes
checking whether frexp works... yes
checking whether frexpl is declared... yes
checking whether frexpl() can be used without linking with libm... yes
checking whether frexpl works... yes
checking whether gettimeofday clobbers localtime buffer... no
checking for gettimeofday with POSIX signature... yes
checking whether INT32_MAX < INTMAX_MAX... yes
checking whether INT64_MAX == LONG_MAX... yes
checking whether UINT32_MAX < UINTMAX_MAX... yes
checking whether UINT64_MAX == ULONG_MAX... yes
checking whether isnan(double) can be used without linking with libm... yes
checking whether isnan(long double) can be used without linking with libm... no
checking where to find the exponent in a 'long double'... word 2 bit 0
checking whether NAN macro works... yes
checking whether HUGE_VAL works... yes
checking whether acosf is declared without a macro... yes
checking whether acosl is declared without a macro... yes
checking whether asinf is declared without a macro... yes
checking whether asinl is declared without a macro... yes
checking whether atanf is declared without a macro... yes
checking whether atanl is declared without a macro... yes
checking whether cbrt is declared without a macro... yes
checking whether cbrtf is declared without a macro... yes
checking whether cbrtl is declared without a macro... yes
checking whether ceilf is declared without a macro... yes
checking whether ceill is declared without a macro... yes
checking whether copysign is declared without a macro... yes
checking whether copysignf is declared without a macro... yes
checking whether copysignl is declared without a macro... yes
checking whether cosf is declared without a macro... yes
checking whether cosl is declared without a macro... yes
checking whether coshf is declared without a macro... ye

Re: RSB build failure

2018-03-17 Thread Amaan Cheval

Hi!

> checking for python...
/Library/Frameworks/Python.framework/Versions/2.7/bin/python
> checking for python2.7... no
> configure: error: python is missing or unusable

That looks like the problem (at least on the surface). macOS does come with
Python built-in, but I don't believe that's good enough for development
(vague memories only of issues) - have you installed Python separately too?

If so, could you confirm that you have the python2.7 binary in your PATH
variable too?

On Sat, Mar 17, 2018 at 3:24 PM Vidushi Vashishth 
wrote:

> Hello!

> I was trying to set up the sparc/erc32 bsp on a new system and was
following the quickstart on the user manual. Though I have successfully
done this before, this time its throwing an error. PFA the rsb log file
with the error report. I was doing this to run the trace buffering
examples.

> Why is the shell command /bin/sh -ex failing?

> Regards,
> Vidushi
> ___
> 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: RSB build failure

2018-03-17 Thread Amaan Cheval

> Why is the shell command /bin/sh -ex failing?

That's likely because the "doit" script calls the configure script, which
errors out because it can't find python2.7, by the way.

On Sat, Mar 17, 2018 at 3:30 PM Amaan Cheval  wrote:

> Hi!

> > checking for python...
> /Library/Frameworks/Python.framework/Versions/2.7/bin/python
> > checking for python2.7... no
> > configure: error: python is missing or unusable

> That looks like the problem (at least on the surface). macOS does come
with
> Python built-in, but I don't believe that's good enough for development
> (vague memories only of issues) - have you installed Python separately
too?

> If so, could you confirm that you have the python2.7 binary in your PATH
> variable too?

> On Sat, Mar 17, 2018 at 3:24 PM Vidushi Vashishth 
> wrote:

> > Hello!

> > I was trying to set up the sparc/erc32 bsp on a new system and was
> following the quickstart on the user manual. Though I have successfully
> done this before, this time its throwing an error. PFA the rsb log file
> with the error report. I was doing this to run the trace buffering
> examples.

> > Why is the shell command /bin/sh -ex failing?

> > Regards,
> > Vidushi
> > ___
> > 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: RSB build failure

2018-03-17 Thread Aditya Upadhyay

install python-dev... Will solve the issue. If you are using ubuntu..
sudo apt-get install python-dev.

On Sat, Mar 17, 2018, 3:30 PM Amaan Cheval  wrote:

> Hi!
>
> > checking for python...
> /Library/Frameworks/Python.framework/Versions/2.7/bin/python
> > checking for python2.7... no
> > configure: error: python is missing or unusable
>
> That looks like the problem (at least on the surface). macOS does come with
> Python built-in, but I don't believe that's good enough for development
> (vague memories only of issues) - have you installed Python separately too?
>
> If so, could you confirm that you have the python2.7 binary in your PATH
> variable too?
>
> On Sat, Mar 17, 2018 at 3:24 PM Vidushi Vashishth 
> wrote:
>
> > Hello!
>
> > I was trying to set up the sparc/erc32 bsp on a new system and was
> following the quickstart on the user manual. Though I have successfully
> done this before, this time its throwing an error. PFA the rsb log file
> with the error report. I was doing this to run the trace buffering
> examples.
>
> > Why is the shell command /bin/sh -ex failing?
>
> > Regards,
> > Vidushi
> > ___
> > 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: RSB build failure

So it was a problem with the path variable.

Fixed it. The setup worked. Thanks!

On Sat, Mar 17, 2018 at 3:33 PM, Aditya Upadhyay 
wrote:

> install python-dev... Will solve the issue. If you are using ubuntu..
> sudo apt-get install python-dev.
>
> On Sat, Mar 17, 2018, 3:30 PM Amaan Cheval  wrote:
>
>> Hi!
>>
>> > checking for python...
>> /Library/Frameworks/Python.framework/Versions/2.7/bin/python
>> > checking for python2.7... no
>> > configure: error: python is missing or unusable
>>
>> That looks like the problem (at least on the surface). macOS does come
>> with
>> Python built-in, but I don't believe that's good enough for development
>> (vague memories only of issues) - have you installed Python separately
>> too?
>>
>> If so, could you confirm that you have the python2.7 binary in your PATH
>> variable too?
>>
>> On Sat, Mar 17, 2018 at 3:24 PM Vidushi Vashishth 
>> wrote:
>>
>> > Hello!
>>
>> > I was trying to set up the sparc/erc32 bsp on a new system and was
>> following the quickstart on the user manual. Though I have successfully
>> done this before, this time its throwing an error. PFA the rsb log file
>> with the error report. I was doing this to run the trace buffering
>> examples.
>>
>> > Why is the shell command /bin/sh -ex failing?
>>
>> > Regards,
>> > Vidushi
>> > ___
>> > 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: x86_64 port and BSP (GSoC 2018)

2018-03-17 Thread Gedare Bloom

On Sat, Mar 17, 2018 at 2:24 AM, Amaan Cheval  wrote:
> Hey everyone!
>
> Here's a link to a draft of my proposal (also shared through the GSoC
> website, and linked to on the wiki):
> https://docs.google.com/document/d/1X79Yj0DNqvaDFqpJMUX4gF3WC550GDvVDS5QufvAnFE/edit?usp=sharing
>
> I'd appreciate all comments - even if you're just skimming, let me know if
> you have something to say!
>
> I have a few questions too, which I'd appreciate help with:
>
> Regarding the proposal:
>
> - Does it seem like I'm committing too little / too much?

I don't think you have work planned in a good way. The scope of the
second half is light, while the first half may be heavy. It is OK to
have schedule slip, but it is better if you can try to balance the
work over the phases. Also, note that GSoC is now a three-thirds
instead of two-halves timeline.

> - Are there any issues I've completely overlooked? Something I've
> oversimplified / that I may not realize the scope / difficulty of?

Getting boot to work properly may be harder than you anticipate. Doing
the ISR right means implementing the APIC support in a proper way. I
think it will be a good idea for you to address SMP issues together
with the UP implementation.

> - It seems like Chris (cc'd) owns the x86_64 ticket - would Chris be a
> potential mentor, or is ticket ownership not indicative of who the mentor
> might be?

Yes, Chris or Joel are likely mentors, unless another interested party pops up.

>
> Misc:
>
> - I noticed that this project has been proposed in the past, at least
> twice. Is there any constructive criticism from the proposals back then
> that I could learn from?

Not really. The previous proposals were weak, and this project was not
a high priority back then.

> - In the proposals, I've left some tasks about the x86_64 rtems-tools
> highlighted in red because I'm hoping to test the tools before the proposal
> deadline to have a clearer idea for the timeline. The ticket[1] lists some
> tasks regarding the tools, but I'm not sure what the status of them is yet,
> or how to carry the tasks out quite yet. I aim to tackle this as soon as
> possible, but if you can provide any guidance, I'd appreciate that.
>

The x86_64 tools have a recipe in RSB, you can give it a try. The
tasks identified there are in two categories:
1. GCC multilib support for FPU -- You should ask Joel to look into
this for you. :)
2. Newlib support for setjmp/longjmp, and anything else that should be
in the libc. You should do this. Join newlib mailing list, check out
the source, and find the current i386 and x86_64 implementations.
(Hint: newlib.git/newlib/libc/machine/[i386 x86_64]).
3. TLS. There are multiple ways to implement it. I don't know what is
preferred for this. See https://www.akkadia.org/drepper/tls.pdf for a
thorough background.

> Thanks!
>
> [1] https://devel.rtems.org/ticket/2898#Tools
> ___
> 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: Improve coverage analysis toolset

I built it manually

the environment variable PATH looks like this
/home/lunatic/qemu/install/bin:/home/lunatic/development/rtems/5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/lunatic/.local/bin:/home/lunatic/bin

I tried to run rtems-test again without --coverage , it gives the same
result
I have attached the log.

-- vijay

On 17 March 2018 at 00:55, Cillian O'Donnell  wrote:

> Yes this is something more than my build, I'll need someone a bit more
> expert in the RSB to step in there. In the meantime, lets just build
> couverture-qemu manually so we can see is everything else working.
>
> git clone https://github.com/AdaCore/qemu
>
> cd qemu
>
> ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
> --disable-docs --disable-virtfs --disable-werror
>
> make
>
> make install
>
> then add the prefix to $PATH in .bashrc as well like before.
>
> export PATH=$HOME/qemu/install/bin:$PATH
>
> Then run rtem-test and see what happens
>
>
> On 16 March 2018 at 19:13, Vijay Kumar Banerjee 
> wrote:
>
>> the same error comes when I try to build qemu from the
>> RTEMS/rtems-source-builder as well
>>
>> is the issue coming from my system ? I'm using fedora 27 64bit
>>
>> On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> yes , the same thing happens
>>>
>>> On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" 
>>> wrote:
>>>
 If you build regular qemu with the RSB, does the same thing happen?

 Try

 ../source-builder/sb-set-builder --log=qemu_log.txt
 --prefix=$HOME/development/5 devel/qemu


 On 16 March 2018 at 16:48, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> still the same error
>
> -- vijay
>
> On 16 March 2018 at 21:39, Cillian O'Donnell 
> wrote:
>
>> Just checked and the build was failing because one of the patches
>> needed its hash to be updated to sha256. Just pushed that change. The 
>> build
>> finishes successfully on my end. Pull that change into couverture-build
>> branch and try it again. I'm not seeing any automake stuff here, so just
>> check that and let me know.
>>
>> On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> building couverture-qemu from rtems-source-builder (
>>> https://github.com/cillianodonnell/rtems-source-builder/tr
>>> ee/couverture-build )
>>> gives error building auromake-1.12.6-x86_64-linux-gnu-1 .
>>>
>>> I have attached the error report .
>>>
>>> -- vijay
>>>
>>> On 15 March 2018 at 19:17, Cillian O'Donnell 
>>> wrote:
>>>


 On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> It runs with a bunch of errors . I have attached the log file
>

 Ok, I'm guessing you didn't set up Couverture-Qemu (special version
 of qemu designed for generating extra trace data for coverage 
 analysis).
 That's what those errors are about. I have an RSB build for that.

 https://github.com/cillianodonnell/rtems-source-builder/tree
 /couverture-build

 and the instructions for building it are

 https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin
 gCouverture-QemuwiththeRSB

 I know what the other problem is too. I have a specific environment
 variable defined for the path, sorry I can't even remember putting it
 there, I thought that was automatically generated (probably should be,
 another thing to add to the list :)... ). So wherever you stuck the 
 export
 path for where the rsb built the tools, in .bashrc or whatever you're
 using. Also put something like:

 export PATH=$HOME/development/rtems/5/bin:$PATH

 export 
 PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH


 or you could just copy covoar into the /bin directory with all the
 other rsb tools gcc and all that, it'll find it either way.



>
> -- vijay
>
> On 15 March 2018 at 16:58, Cillian O'Donnell <
> cpodonne...@gmail.com> wrote:
>
>> Looks good. If you run the samples without coverage is everything
>> ok?
>>
>> So removing --coverage and tacking on /samples
>>
>> $HOME/development/rtems-tools/tester/rtems-test
>> --rtems-bsp=leon3-qemu --log=log-leon3.log 
>> --rtems-tools=$HOME/development/rtems/5
>> --rtems-builddir=$HOME/development/rtems/kernel/leon3
>> sparc-rtems5/c/leon3/testsuites/samples
>>
>> Do the tests run?
>>
>> On 15 March 2018 at 10:53, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> w

Re: Improve coverage analysis toolset

My guess on the build error is that the automake version used by RTEMS is
very old and may not produce output for --help that help2man can parse.

Try building qemu from the RSB without the RTEMS tools in your PATH.

If Couverture has been updated to a recent enough version of the upstream
qemu, then it is likely to fail the same way.

--joel

On Mar 17, 2018 9:46 AM, "Vijay Kumar Banerjee" 
wrote:

> I built it manually
>
> the environment variable PATH looks like this
> /home/lunatic/qemu/install/bin:/home/lunatic/development/
> rtems/5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/
> sbin:/home/lunatic/.local/bin:/home/lunatic/bin
>
> I tried to run rtems-test again without --coverage , it gives the same
> result
> I have attached the log.
>
> -- vijay
>
> On 17 March 2018 at 00:55, Cillian O'Donnell 
> wrote:
>
>> Yes this is something more than my build, I'll need someone a bit more
>> expert in the RSB to step in there. In the meantime, lets just build
>> couverture-qemu manually so we can see is everything else working.
>>
>> git clone https://github.com/AdaCore/qemu
>>
>> cd qemu
>>
>> ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
>> --disable-docs --disable-virtfs --disable-werror
>>
>> make
>>
>> make install
>>
>> then add the prefix to $PATH in .bashrc as well like before.
>>
>> export PATH=$HOME/qemu/install/bin:$PATH
>>
>> Then run rtem-test and see what happens
>>
>>
>> On 16 March 2018 at 19:13, Vijay Kumar Banerjee > > wrote:
>>
>>> the same error comes when I try to build qemu from the
>>> RTEMS/rtems-source-builder as well
>>>
>>> is the issue coming from my system ? I'm using fedora 27 64bit
>>>
>>> On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 yes , the same thing happens

 On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" 
 wrote:

> If you build regular qemu with the RSB, does the same thing happen?
>
> Try
>
> ../source-builder/sb-set-builder --log=qemu_log.txt
> --prefix=$HOME/development/5 devel/qemu
>
>
> On 16 March 2018 at 16:48, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> still the same error
>>
>> -- vijay
>>
>> On 16 March 2018 at 21:39, Cillian O'Donnell 
>> wrote:
>>
>>> Just checked and the build was failing because one of the patches
>>> needed its hash to be updated to sha256. Just pushed that change. The 
>>> build
>>> finishes successfully on my end. Pull that change into couverture-build
>>> branch and try it again. I'm not seeing any automake stuff here, so just
>>> check that and let me know.
>>>
>>> On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 building couverture-qemu from rtems-source-builder (
 https://github.com/cillianodonnell/rtems-source-builder/tr
 ee/couverture-build )
 gives error building auromake-1.12.6-x86_64-linux-gnu-1 .

 I have attached the error report .

 -- vijay

 On 15 March 2018 at 19:17, Cillian O'Donnell >>> > wrote:

>
>
> On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> It runs with a bunch of errors . I have attached the log file
>>
>
> Ok, I'm guessing you didn't set up Couverture-Qemu (special
> version of qemu designed for generating extra trace data for coverage
> analysis). That's what those errors are about. I have an RSB build 
> for that.
>
> https://github.com/cillianodonnell/rtems-source-builder/tree
> /couverture-build
>
> and the instructions for building it are
>
> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin
> gCouverture-QemuwiththeRSB
>
> I know what the other problem is too. I have a specific
> environment variable defined for the path, sorry I can't even remember
> putting it there, I thought that was automatically generated (probably
> should be, another thing to add to the list :)... ). So wherever you 
> stuck
> the export path for where the rsb built the tools, in .bashrc or 
> whatever
> you're using. Also put something like:
>
> export PATH=$HOME/development/rtems/5
> /bin:$PATH
> export PATH=$HOME/development/rtems/t
> est/rtems-tools/build/tester/covoar:$PATH
>
> or you could just copy covoar into the /bin directory with all the
> other rsb tools gcc and all that, it'll find it either way.
>
>
>
>>
>> -- vijay
>>
>> On 15 March 2018 at 16:58, Cillian O'Donnell <
>> cpodonne...@gmail.com> wrote:
>>
>>> Looks good. If you run the sample

Re: x86_64 port and BSP (GSoC 2018)

2018-03-17 Thread Amaan Cheval

First off, thank you so much for the prompt and detailed response! I really
appreciate the help!

On Sat, Mar 17, 2018 at 6:46 PM Gedare Bloom  wrote:

> On Sat, Mar 17, 2018 at 2:24 AM, Amaan Cheval 
wrote:
> > Hey everyone!
> >
> > Here's a link to a draft of my proposal (also shared through the GSoC
> > website, and linked to on the wiki):
> >
https://docs.google.com/document/d/1X79Yj0DNqvaDFqpJMUX4gF3WC550GDvVDS5QufvAnFE/edit?usp=sharing
> >
> > I'd appreciate all comments - even if you're just skimming, let me know
if
> > you have something to say!
> >
> > I have a few questions too, which I'd appreciate help with:
> >
> > Regarding the proposal:
> >
> > - Does it seem like I'm committing too little / too much?

> I don't think you have work planned in a good way. The scope of the
> second half is light, while the first half may be heavy. It is OK to
> have schedule slip, but it is better if you can try to balance the
> work over the phases. Also, note that GSoC is now a three-thirds
> instead of two-halves timeline.

Noted. I've revised it a bit (same link). Would you mind having another
look?

> > - Are there any issues I've completely overlooked? Something I've
> > oversimplified / that I may not realize the scope / difficulty of?

> Getting boot to work properly may be harder than you anticipate.

That's a good point. I've made the target for phase 1 about getting stub
code there, boot/init code started, and patching the x86_64 tools up to
have them be feature-complete. (It's hard to gauge if that's a satisfactory
goal given that I'm not quite sure of the current status of the tools -
this is why I'm hoping to resolve this ASAP.)

Would you let me know if the deliverables seem more evenly distributed and
realistic now?

> Doing the ISR right means implementing the APIC support in a proper way.
> I think it will be a good idea for you to address SMP issues together
> with the UP implementation.

I agree, but I'd rather not commit to SMP support since that sounds like it
might be too much - I can't know that, of course, but I think I'd rather
keep it a bonus activity that I'll be able to pull in when I'm more in the
swing of things and better able to gauge the effort required.

> > - It seems like Chris (cc'd) owns the x86_64 ticket - would Chris be a
> > potential mentor, or is ticket ownership not indicative of who the
mentor
> > might be?

> Yes, Chris or Joel are likely mentors, unless another interested party
pops up.

I see! Do mentors usually mentor more than one student?

> >
> > Misc:
> >
> > - I noticed that this project has been proposed in the past, at least
> > twice. Is there any constructive criticism from the proposals back then
> > that I could learn from?

> Not really. The previous proposals were weak, and this project was not
> a high priority back then.

Ah. Is there anything I can do to strengthen my proposal, in that case,
besides the feedback you've already provided? I do already plan to tackle
more tickets as time permits / get a head start on fixing / verifying the
x86_64 tools up. Is there anything else I should also be doing? Any other
resources I should be looking at?

I just want to make sure that I know what I'm getting into and that you
guys aren't making a blind bet - anything I can do to prove to you and me
that I'm actually capable of handling this task would be immensely helpful.

> > - In the proposals, I've left some tasks about the x86_64 rtems-tools
> > highlighted in red because I'm hoping to test the tools before the
proposal
> > deadline to have a clearer idea for the timeline. The ticket[1] lists
some
> > tasks regarding the tools, but I'm not sure what the status of them is
yet,
> > or how to carry the tasks out quite yet. I aim to tackle this as soon as
> > possible, but if you can provide any guidance, I'd appreciate that.
> >

> The x86_64 tools have a recipe in RSB, you can give it a try. The
> tasks identified there are in two categories:
> 1. GCC multilib support for FPU -- You should ask Joel to look into
> this for you. :)

@Joel (cc'd) would you mind doing this? If you're busy / don't want to
(:P), would you mind letting me know how I can do it myself?

I'd like to dig into the tools as soon as possible because it seems like it
has the potential to significantly influence my timeline for this project,
and knowing in advance I'll be better equipped to commit the right amount.

> 2. Newlib support for setjmp/longjmp, and anything else that should be
> in the libc. You should do this. Join newlib mailing list, check out
> the source, and find the current i386 and x86_64 implementations.
> (Hint: newlib.git/newlib/libc/machine/[i386 x86_64]).
> 3. TLS. There are multiple ways to implement it. I don't know what is
> preferred for this. See https://www.akkadia.org/drepper/tls.pdf for a
> thorough background.

Thank you for the detailed resources! I'll add them to the project ticket
as well for future reference.

P.S. - I'd also like to say congrat

autotools build fail from rsb

hello ,

As suggested by Gedare , I have started this thread on the build error that
I'm getting .

I'm getting automake-1.12.6-x86_64-linux-gnu-1 building error while trying
to build autotools from rsb

I'm using fedora 27 64bit .

P.S: the error report is attached

-- vijay
RTEMS Tools Project - Source Builder Error Report
 Build: error: building automake-1.12.6-x86_64-linux-gnu-1
 Command Line: ../source-builder/sb-set-builder --prefix=/home/develpment/rtems 
devel/autotools
 Python: 2.7.14 (default, Feb 27 2018, 20:43:24) [GCC 7.3.1 20180130 (Red Hat 
7.3.1-2)]
 
git://git.rtems.org/rtems-source-builder.git/origin/4b3e0f8e3d6998b84a2503dd2e11578989b1672b
 Linux lunatic 4.15.8-300.fc27.x86_64 #1 SMP Fri Mar 9 18:11:36 UTC 2018 x86_64
Tail of the build log:
-r-xr-xr-x 1000/1000   443 2012-12-15 15:04 automake-1.12.6/t/tap-more-w.sh
-rwxr-xr-x 1000/1000  3150 2012-12-14 01:27 
automake-1.12.6/t/testsuite-summary-count.sh
-rwxr-xr-x 1000/1000  1509 2012-12-14 22:28 
automake-1.12.6/t/aclocal-path.sh
-rwxr-xr-x 1000/1000  1043 2012-12-14 22:28 automake-1.12.6/t/version6.sh
-rwxr-xr-x 1000/1000  2050 2012-12-14 22:28 
automake-1.12.6/t/distcheck-configure-flags-am.sh
-rwxr-xr-x 1000/1000  1577 2012-12-14 22:28 
automake-1.12.6/t/tests-environment-backcompat.sh
-rwxr-xr-x 1000/1000  2966 2012-12-14 22:28 automake-1.12.6/t/backcompat5.sh
-rwxr-xr-x 1000/1000   970 2012-12-14 22:28 automake-1.12.6/t/gcj2.sh
-rwxr-xr-x 1000/1000  1561 2012-12-14 22:28 automake-1.12.6/t/ccnoco3.sh
-r-xr-xr-x 1000/1000   218 2012-12-15 15:04 
automake-1.12.6/t/depcomp-lt-makedepend.tap
-rwxr-xr-x 1000/1000  1323 2012-12-14 22:28 automake-1.12.6/t/pr279.sh
-r-xr-xr-x 1000/1000   201 2012-12-15 15:04 
automake-1.12.6/t/depcomp-lt-cpp.tap
-rwxr-xr-x 1000/1000  1436 2012-12-14 22:28 automake-1.12.6/t/cond21.sh
-rwxr-xr-x 1000/1000  1651 2012-12-14 22:28 automake-1.12.6/t/alpha.sh
-rwxr-xr-x 1000/1000  1577 2012-12-14 22:28 
automake-1.12.6/t/parallel-tests-concurrency-2.sh
-rwxr-xr-x 1000/1000  1135 2012-12-14 22:28 automake-1.12.6/t/cond20.sh
-rwxr-xr-x 1000/1000  1050 2012-12-14 22:28 automake-1.12.6/t/tar2.sh
-rwxr-xr-x 1000/1000   997 2012-12-14 22:28 automake-1.12.6/t/cond28.sh
-rwxr-xr-x 1000/1000  2369 2012-12-14 22:28 automake-1.12.6/t/libtool7.sh
-rwxr-xr-x 1000/1000  1376 2012-12-14 22:28 automake-1.12.6/t/cond18.sh
-rwxr-xr-x 1000/1000  1818 2012-12-14 15:13 
automake-1.12.6/t/vala-headers.sh
-rwxr-xr-x 1000/1000  1676 2012-12-14 22:28 automake-1.12.6/t/java-clean.sh
-rwxr-xr-x 1000/1000  1290 2012-12-14 22:28 automake-1.12.6/t/specflg6.sh
-rwxr-xr-x 1000/1000  1856 2012-12-14 22:28 automake-1.12.6/t/output7.sh
-rwxr-xr-x 1000/1000  1604 2012-12-14 22:28 
automake-1.12.6/t/py-compile-basedir.sh
-rwxr-xr-x 1000/1000  1724 2012-12-14 22:28 automake-1.12.6/t/txinfo24.sh
-rwxr-xr-x 1000/1000  1928 2012-12-14 22:28 automake-1.12.6/t/txinfo28.sh
-rwxr-xr-x 1000/1000  2310 2012-12-14 22:28 automake-1.12.6/t/suffix10.tap
-rwxr-xr-x 1000/1000  1090 2012-12-14 22:28 
automake-1.12.6/t/tap-planskip-later-errors.sh
-rwxr-xr-x 1000/1000   945 2012-12-14 22:28 automake-1.12.6/t/ar-lib7.sh
-rwxr-xr-x 1000/1000  1481 2012-12-14 22:28 
automake-1.12.6/t/dist-auxfile-2.sh
-rwxr-xr-x 1000/1000  1399 2012-12-14 22:28 automake-1.12.6/t/tap-empty.sh
-rwxr-xr-x 1000/1000  1427 2012-12-14 22:28 automake-1.12.6/t/suffix9.sh
-rwxr-xr-x 1000/1000  1523 2012-12-14 22:28 automake-1.12.6/t/license.sh
-rwxr-xr-x 1000/1000  1372 2012-12-14 22:28 
automake-1.12.6/t/tap-negative-numbers.sh
-rwxr-xr-x 1000/1000  1411 2012-12-14 22:28 automake-1.12.6/t/colon7.sh
-rwxr-xr-x 1000/1000  2192 2012-12-14 22:28 
automake-1.12.6/t/primary-prefix-couples-documented-valid.sh
-rwxr-xr-x 1000/1000  4034 2012-12-14 22:28 automake-1.12.6/t/txinfo21.sh
-rwxr-xr-x 1000/1000  1942 2012-12-14 15:13 
automake-1.12.6/t/vala-per-target-flags.sh
-rwxr-xr-x 1000/1000  1639 2012-12-14 22:28 
automake-1.12.6/t/suffix-custom-subobj-and-specflg.sh
-rwxr-xr-x 1000/1000   909 2012-12-14 22:28 automake-1.12.6/t/prefix.sh
-rwxr-xr-x 1000/1000  1150 2012-12-14 22:28 automake-1.12.6/t/cond10.sh
-r-xr-xr-x 1000/1000   499 2012-12-15 15:04 
automake-1.12.6/t/tap-planskip-unplanned-w.sh
-rwxr-xr-x 1000/1000  1765 2012-12-14 22:28 
automake-1.12.6/t/aclocal-install-fail.sh
-r-xr-xr-x 1000/1000   496 2012-12-15 15:04 
automake-1.12.6/t/check-tests-in-builddir-w.sh
-rwxr-xr-x 1000/1000   928 2012-12-14 22:28 automake-1.12.6/t/backsl3.sh
-rwxr-xr-x 1000/1000   872 2012-12-14 22:28 automake-1.12.6/t/comment.sh
-rwxr-xr-x 1000/1000  2501 2012-12-14 22:28 automake-1.12.6/t/dejagnu4.sh
-rwxr-xr-x 1000/1000  2387 2012-12-14 22:28 automake-1.12.6/t/yacc-nodist.sh
-rwxr-xr-x 1000/1000  1355 2012-12-14 22:28 automake-1.12.6/t/link_dist.sh
-rwxr-xr-x 1000/1000  2284 2012-12-14 22:28 automake-1.12.6/t/cond3

Re: autotools build fail from rsb

I answered what I think the cause is on another thread.

Take the ancient RTEMS autotools out of your PATH while building qemu. Use
a PATH without RTEMS tools in it. I think the ancient automake version we
use must have --help which help2man can't parse.

On Mar 17, 2018 11:34 AM, "Vijay Kumar Banerjee" 
wrote:

> hello ,
>
> As suggested by Gedare , I have started this thread on the build error
> that I'm getting .
>
> I'm getting automake-1.12.6-x86_64-linux-gnu-1 building error while
> trying to build autotools from rsb
>
> I'm using fedora 27 64bit .
>
> P.S: the error report is attached
>
> -- vijay
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: x86_64 port and BSP (GSoC 2018)

2018-03-17 Thread Gedare Bloom

On Sat, Mar 17, 2018 at 11:58 AM, Amaan Cheval  wrote:
> First off, thank you so much for the prompt and detailed response! I really
> appreciate the help!
>
> On Sat, Mar 17, 2018 at 6:46 PM Gedare Bloom  wrote:
>
>> On Sat, Mar 17, 2018 at 2:24 AM, Amaan Cheval 
> wrote:
>> > Hey everyone!
>> >
>> > Here's a link to a draft of my proposal (also shared through the GSoC
>> > website, and linked to on the wiki):
>> >
> https://docs.google.com/document/d/1X79Yj0DNqvaDFqpJMUX4gF3WC550GDvVDS5QufvAnFE/edit?usp=sharing
>> >
>> > I'd appreciate all comments - even if you're just skimming, let me know
> if
>> > you have something to say!
>> >
>> > I have a few questions too, which I'd appreciate help with:
>> >
>> > Regarding the proposal:
>> >
>> > - Does it seem like I'm committing too little / too much?
>
>> I don't think you have work planned in a good way. The scope of the
>> second half is light, while the first half may be heavy. It is OK to
>> have schedule slip, but it is better if you can try to balance the
>> work over the phases. Also, note that GSoC is now a three-thirds
>> instead of two-halves timeline.
>
> Noted. I've revised it a bit (same link). Would you mind having another
> look?
>
>
>> > - Are there any issues I've completely overlooked? Something I've
>> > oversimplified / that I may not realize the scope / difficulty of?
>
>> Getting boot to work properly may be harder than you anticipate.
>
> That's a good point. I've made the target for phase 1 about getting stub
> code there, boot/init code started, and patching the x86_64 tools up to
> have them be feature-complete. (It's hard to gauge if that's a satisfactory
> goal given that I'm not quite sure of the current status of the tools -
> this is why I'm hoping to resolve this ASAP.)
>
> Would you let me know if the deliverables seem more evenly distributed and
> realistic now?
>

It does. I think Phase 3 remains light. I'd encourage you to flesh out
the plan for one of the "bonus" areas for this phase. That way, if you
reach it, you will be prepared to undertake it without having to think
too hard about the design aspects.

>> Doing the ISR right means implementing the APIC support in a proper way.
>> I think it will be a good idea for you to address SMP issues together
>> with the UP implementation.
>
>
> I agree, but I'd rather not commit to SMP support since that sounds like it
> might be too much - I can't know that, of course, but I think I'd rather
> keep it a bonus activity that I'll be able to pull in when I'm more in the
> swing of things and better able to gauge the effort required.
>
>> > - It seems like Chris (cc'd) owns the x86_64 ticket - would Chris be a
>> > potential mentor, or is ticket ownership not indicative of who the
> mentor
>> > might be?
>
>> Yes, Chris or Joel are likely mentors, unless another interested party
> pops up.
>
>
> I see! Do mentors usually mentor more than one student?
>

Some do.

>> >
>> > Misc:
>> >
>> > - I noticed that this project has been proposed in the past, at least
>> > twice. Is there any constructive criticism from the proposals back then
>> > that I could learn from?
>
>> Not really. The previous proposals were weak, and this project was not
>> a high priority back then.
>
> Ah. Is there anything I can do to strengthen my proposal, in that case,
> besides the feedback you've already provided? I do already plan to tackle
> more tickets as time permits / get a head start on fixing / verifying the
> x86_64 tools up. Is there anything else I should also be doing? Any other
> resources I should be looking at?
>
> I just want to make sure that I know what I'm getting into and that you
> guys aren't making a blind bet - anything I can do to prove to you and me
> that I'm actually capable of handling this task would be immensely helpful.
>
>
>> > - In the proposals, I've left some tasks about the x86_64 rtems-tools
>> > highlighted in red because I'm hoping to test the tools before the
> proposal
>> > deadline to have a clearer idea for the timeline. The ticket[1] lists
> some
>> > tasks regarding the tools, but I'm not sure what the status of them is
> yet,
>> > or how to carry the tasks out quite yet. I aim to tackle this as soon as
>> > possible, but if you can provide any guidance, I'd appreciate that.
>> >
>
>> The x86_64 tools have a recipe in RSB, you can give it a try. The
>> tasks identified there are in two categories:
>> 1. GCC multilib support for FPU -- You should ask Joel to look into
>> this for you. :)
>
> @Joel (cc'd) would you mind doing this? If you're busy / don't want to
> (:P), would you mind letting me know how I can do it myself?
>
> I'd like to dig into the tools as soon as possible because it seems like it
> has the potential to significantly influence my timeline for this project,
> and knowing in advance I'll be better equipped to commit the right amount.
>

The reason I suggest Joel might look is because touching GCC code is a
bit of a hassle (the first time).

>>

Re: x86_64 port and BSP (GSoC 2018)

On Sat, Mar 17, 2018 at 1:09 PM, Gedare Bloom  wrote:

> On Sat, Mar 17, 2018 at 11:58 AM, Amaan Cheval 
> wrote:
> > First off, thank you so much for the prompt and detailed response! I
> really
> > appreciate the help!
> >
> > On Sat, Mar 17, 2018 at 6:46 PM Gedare Bloom  wrote:
> >
> >> On Sat, Mar 17, 2018 at 2:24 AM, Amaan Cheval 
> > wrote:
> >> > Hey everyone!
> >> >
> >> > Here's a link to a draft of my proposal (also shared through the GSoC
> >> > website, and linked to on the wiki):
> >> >
> > https://docs.google.com/document/d/1X79Yj0DNqvaDFqpJMUX4gF3WC550G
> DvVDS5QufvAnFE/edit?usp=sharing
> >> >
> >> > I'd appreciate all comments - even if you're just skimming, let me
> know
> > if
> >> > you have something to say!
> >> >
> >> > I have a few questions too, which I'd appreciate help with:
> >> >
> >> > Regarding the proposal:
> >> >
> >> > - Does it seem like I'm committing too little / too much?
> >
> >> I don't think you have work planned in a good way. The scope of the
> >> second half is light, while the first half may be heavy. It is OK to
> >> have schedule slip, but it is better if you can try to balance the
> >> work over the phases. Also, note that GSoC is now a three-thirds
> >> instead of two-halves timeline.
> >
> > Noted. I've revised it a bit (same link). Would you mind having another
> > look?
>
>
I have always thought the first part of this project would be to get
an UEFI "hello world" running on Qemu. That is the entry point to the
BSP and as Chris pointed out, there is a fair amount of work just
to ensure you can do prints to the optional video and later serial port.

Then that can be hooked to initialize RTEMS. Implement the context
switch code using setjmp/longjmp as guides.

With the idle thread that simulates a clock tick, you can run a lot of
the tests.

Then deal with the interrupt controller and clock tick.

Then add COM1.

All that should be doable and testable on qemu.


> >> > - Are there any issues I've completely overlooked? Something I've
> >> > oversimplified / that I may not realize the scope / difficulty of?
> >
> >> Getting boot to work properly may be harder than you anticipate.
> >
> > That's a good point. I've made the target for phase 1 about getting stub
> > code there, boot/init code started, and patching the x86_64 tools up to
> > have them be feature-complete. (It's hard to gauge if that's a
> satisfactory
> > goal given that I'm not quite sure of the current status of the tools -
> > this is why I'm hoping to resolve this ASAP.)
> >
> > Would you let me know if the deliverables seem more evenly distributed
> and
> > realistic now?
> >
>
> It does. I think Phase 3 remains light. I'd encourage you to flesh out
> the plan for one of the "bonus" areas for this phase. That way, if you
> reach it, you will be prepared to undertake it without having to think
> too hard about the design aspects.
>
> >> Doing the ISR right means implementing the APIC support in a proper way.
> >> I think it will be a good idea for you to address SMP issues together
> >> with the UP implementation.
> >
> >
> > I agree, but I'd rather not commit to SMP support since that sounds like
> it
> > might be too much - I can't know that, of course, but I think I'd rather
> > keep it a bonus activity that I'll be able to pull in when I'm more in
> the
> > swing of things and better able to gauge the effort required.
>
>
+1


> >> > - It seems like Chris (cc'd) owns the x86_64 ticket - would Chris be a
> >> > potential mentor, or is ticket ownership not indicative of who the
> > mentor
> >> > might be?
> >
> >> Yes, Chris or Joel are likely mentors, unless another interested party
> > pops up.
>
> This project will likely require help from multiple mentors with Chris
and I being the official mentor pair.


> > I see! Do mentors usually mentor more than one student?
> >
>
> Some do.
>
> >> >
> >> > Misc:
> >> >
> >> > - I noticed that this project has been proposed in the past, at least
> >> > twice. Is there any constructive criticism from the proposals back
> then
> >> > that I could learn from?
> >
> >> Not really. The previous proposals were weak, and this project was not
> >> a high priority back then.
> >
> > Ah. Is there anything I can do to strengthen my proposal, in that case,
> > besides the feedback you've already provided? I do already plan to tackle
> > more tickets as time permits / get a head start on fixing / verifying the
> > x86_64 tools up. Is there anything else I should also be doing? Any other
> > resources I should be looking at?
> >
> > I just want to make sure that I know what I'm getting into and that you
> > guys aren't making a blind bet - anything I can do to prove to you and me
> > that I'm actually capable of handling this task would be immensely
> helpful.
> >
> >
> >> > - In the proposals, I've left some tasks about the x86_64 rtems-tools
> >> > highlighted in red because I'm hoping to test the tools before the
> > proposal
> >> > deadline to have a clearer

Query regarding libbsd update

2018-03-17 Thread Udit agarwal

Hi Sebastian, Hi all,
One part of my GSoC project consists of importing SDIO driver from FreeBSD
head (as on july 2017 or later). As far as importing is concerned there is
a lot of information in libbsd.txt or on previous GSoC student's blogs
which can help me understand the process. However, before importing i also
need to update libbsd base to FreeBSD head(as on july 2017 or later). I
couldn't find much information regarding this update process. It would be
really helpful if you point me towards its relevant documentation or give
me a gist of the whole process. That would again help me understand the
process better, and thus propose a more elaborated and realistic time-line.

Thanks and Regards
Udit agarwal
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Improve coverage analysis toolset

2018-03-17 Thread Cillian O'Donnell

If you run just one test by itself without rtems-test

qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M
leon3_generic -kernel
$HOME/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe

Does the hello world print out?

On 17 March 2018 at 14:46, Vijay Kumar Banerjee 
wrote:

> I built it manually
>
> the environment variable PATH looks like this
> /home/lunatic/qemu/install/bin:/home/lunatic/development/
> rtems/5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/
> sbin:/home/lunatic/.local/bin:/home/lunatic/bin
>
> I tried to run rtems-test again without --coverage , it gives the same
> result
> I have attached the log.
>
> -- vijay
>
> On 17 March 2018 at 00:55, Cillian O'Donnell 
> wrote:
>
>> Yes this is something more than my build, I'll need someone a bit more
>> expert in the RSB to step in there. In the meantime, lets just build
>> couverture-qemu manually so we can see is everything else working.
>>
>> git clone https://github.com/AdaCore/qemu
>>
>> cd qemu
>>
>> ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
>> --disable-docs --disable-virtfs --disable-werror
>>
>> make
>>
>> make install
>>
>> then add the prefix to $PATH in .bashrc as well like before.
>>
>> export PATH=$HOME/qemu/install/bin:$PATH
>>
>> Then run rtem-test and see what happens
>>
>>
>> On 16 March 2018 at 19:13, Vijay Kumar Banerjee > > wrote:
>>
>>> the same error comes when I try to build qemu from the
>>> RTEMS/rtems-source-builder as well
>>>
>>> is the issue coming from my system ? I'm using fedora 27 64bit
>>>
>>> On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 yes , the same thing happens

 On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" 
 wrote:

> If you build regular qemu with the RSB, does the same thing happen?
>
> Try
>
> ../source-builder/sb-set-builder --log=qemu_log.txt
> --prefix=$HOME/development/5 devel/qemu
>
>
> On 16 March 2018 at 16:48, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> still the same error
>>
>> -- vijay
>>
>> On 16 March 2018 at 21:39, Cillian O'Donnell 
>> wrote:
>>
>>> Just checked and the build was failing because one of the patches
>>> needed its hash to be updated to sha256. Just pushed that change. The 
>>> build
>>> finishes successfully on my end. Pull that change into couverture-build
>>> branch and try it again. I'm not seeing any automake stuff here, so just
>>> check that and let me know.
>>>
>>> On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 building couverture-qemu from rtems-source-builder (
 https://github.com/cillianodonnell/rtems-source-builder/tr
 ee/couverture-build )
 gives error building auromake-1.12.6-x86_64-linux-gnu-1 .

 I have attached the error report .

 -- vijay

 On 15 March 2018 at 19:17, Cillian O'Donnell >>> > wrote:

>
>
> On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> It runs with a bunch of errors . I have attached the log file
>>
>
> Ok, I'm guessing you didn't set up Couverture-Qemu (special
> version of qemu designed for generating extra trace data for coverage
> analysis). That's what those errors are about. I have an RSB build 
> for that.
>
> https://github.com/cillianodonnell/rtems-source-builder/tree
> /couverture-build
>
> and the instructions for building it are
>
> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin
> gCouverture-QemuwiththeRSB
>
> I know what the other problem is too. I have a specific
> environment variable defined for the path, sorry I can't even remember
> putting it there, I thought that was automatically generated (probably
> should be, another thing to add to the list :)... ). So wherever you 
> stuck
> the export path for where the rsb built the tools, in .bashrc or 
> whatever
> you're using. Also put something like:
>
> export PATH=$HOME/development/rtems/5
> /bin:$PATH
> export PATH=$HOME/development/rtems/t
> est/rtems-tools/build/tester/covoar:$PATH
>
> or you could just copy covoar into the /bin directory with all the
> other rsb tools gcc and all that, it'll find it either way.
>
>
>
>>
>> -- vijay
>>
>> On 15 March 2018 at 16:58, Cillian O'Donnell <
>> cpodonne...@gmail.com> wrote:
>>
>>> Looks good. If you run the samples without coverage is
>>> everything ok?
>>>
>>> So re

Fwd: Re: regarding application

Just thought I would pass this along for the GSoC students.

Remember no application means no consideration.

--joel
-- Forwarded message --
From: "'Stephanie Taylor' via Google Summer of Code Discuss" <
google-summer-of-code-disc...@googlegroups.com>
Date: Mar 17, 2018 3:41 PM
Subject: Re: regarding application
To: "Google Summer of Code" 
Cc:

You can edit your proposal until March 27 at 16:00 UTC. Remember, you must
> submit a Final PDF and your proof of enrollment before the deadline to have
> a complete application.  You can submit the Final PDF multiple times if you
> keep making changes to it up until the March 27 16:00 UTC deadline.
>
> *Google Summer of Code 2018, is a program where university students spend
> their 3 month summer break coding on an open source project.
> Visit g.co/gsoc  for more information. The s**tudent
> application is open from March 12-27. Coding begins May 14.*
>
>  Stephanie Taylor
>  Open Source Programs, Google
>  sttay...@google.com
>
>
>
>
> On Sat, Mar 17, 2018 at 6:43 PM, shreya singhai  > wrote:
>
>> Can I edit my application even after submission in GSoC 2018?
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google Summer of Code Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-summer-of-code-discuss+unsubscr...@googlegroups.com.
>> To post to this group, send email to google-summer-of-code-discuss@
>> googlegroups.com.
>> Visit this group at https://groups.google.com/grou
>> p/google-summer-of-code-discuss.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Summer of Code Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-summer-of-code-discuss+unsubscr...@googlegroups.com.
> To post to this group, send email to google-summer-of-code-discuss@
> googlegroups.com.
> Visit this group at https://groups.google.com/group/google-summer-of-code-
> discuss.
> For more options, visit https://groups.google.com/d/optout.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Improve coverage analysis toolset

2018-03-17 Thread Cillian O'Donnell

On 17 March 2018 at 20:08, Vijay Kumar Banerjee 
wrote:

> yes it prints hello world
>

Alright I've added an .ini for leon3-qemu to the current rtems-tools. Pull
this branch

https://github.com/cillianodonnell/rtems-tools/tree/ini-update

and try

$HOME/development/rtems/test/rtems-tools/tester/rtems-test
--rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
--rtems-bsp=leon3_qemu
$HOME/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples

>
> -- vijay
>
> On 18 March 2018 at 01:31, Cillian O'Donnell 
> wrote:
>
>> If you run just one test by itself without rtems-test
>>
>> qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M
>> leon3_generic -kernel $HOME/development/rtems/leon3/
>> sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
>>
>> Does the hello world print out?
>>
>> On 17 March 2018 at 14:46, Vijay Kumar Banerjee > > wrote:
>>
>>> I built it manually
>>>
>>> the environment variable PATH looks like this
>>> /home/lunatic/qemu/install/bin:/home/lunatic/development/rte
>>> ms/5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/
>>> home/lunatic/.local/bin:/home/lunatic/bin
>>>
>>> I tried to run rtems-test again without --coverage , it gives the same
>>> result
>>> I have attached the log.
>>>
>>> -- vijay
>>>
>>> On 17 March 2018 at 00:55, Cillian O'Donnell 
>>> wrote:
>>>
 Yes this is something more than my build, I'll need someone a bit more
 expert in the RSB to step in there. In the meantime, lets just build
 couverture-qemu manually so we can see is everything else working.

 git clone https://github.com/AdaCore/qemu

 cd qemu

 ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
 --disable-docs --disable-virtfs --disable-werror

 make

 make install

 then add the prefix to $PATH in .bashrc as well like before.

 export PATH=$HOME/qemu/install/bin:$PATH

 Then run rtem-test and see what happens


 On 16 March 2018 at 19:13, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> the same error comes when I try to build qemu from the
> RTEMS/rtems-source-builder as well
>
> is the issue coming from my system ? I'm using fedora 27 64bit
>
> On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
> vijaykumar9...@gmail.com> wrote:
>
>> yes , the same thing happens
>>
>> On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" 
>> wrote:
>>
>>> If you build regular qemu with the RSB, does the same thing happen?
>>>
>>> Try
>>>
>>> ../source-builder/sb-set-builder --log=qemu_log.txt
>>> --prefix=$HOME/development/5 devel/qemu
>>>
>>>
>>> On 16 March 2018 at 16:48, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 still the same error

 -- vijay

 On 16 March 2018 at 21:39, Cillian O'Donnell >>> > wrote:

> Just checked and the build was failing because one of the patches
> needed its hash to be updated to sha256. Just pushed that change. The 
> build
> finishes successfully on my end. Pull that change into 
> couverture-build
> branch and try it again. I'm not seeing any automake stuff here, so 
> just
> check that and let me know.
>
> On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> building couverture-qemu from rtems-source-builder (
>> https://github.com/cillianodonnell/rtems-source-builder/tr
>> ee/couverture-build )
>> gives error building auromake-1.12.6-x86_64-linux-gnu-1 .
>>
>> I have attached the error report .
>>
>> -- vijay
>>
>> On 15 March 2018 at 19:17, Cillian O'Donnell <
>> cpodonne...@gmail.com> wrote:
>>
>>>
>>>
>>> On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 It runs with a bunch of errors . I have attached the log file

>>>
>>> Ok, I'm guessing you didn't set up Couverture-Qemu (special
>>> version of qemu designed for generating extra trace data for 
>>> coverage
>>> analysis). That's what those errors are about. I have an RSB build 
>>> for that.
>>>
>>> https://github.com/cillianodonnell/rtems-source-builder/tree
>>> /couverture-build
>>>
>>> and the instructions for building it are
>>>
>>> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin
>>> gCouverture-QemuwiththeRSB
>>>
>>> I know what the other problem is too. I have a specific
>>> environment variable defined for the path, sorry I can't even 
>>> remember
>>> putting it there, I thought that was automa

Re: Query regarding libbsd update

2018-03-17 Thread Christian Mauderer

Am 17.03.2018 um 19:40 schrieb Udit agarwal:
> Hi Sebastian, Hi all,
> One part of my GSoC project consists of importing SDIO driver from
> FreeBSD head (as on july 2017 or later). As far as importing is
> concerned there is a lot of information in libbsd.txt or on previous
> GSoC student's blogs which can help me understand the process. However,
> before importing i also need to update libbsd base to FreeBSD head(as on
> july 2017 or later). I couldn't find much information regarding this
> update process. It would be really helpful if you point me towards its
> relevant documentation or give me a gist of the whole process. That
> would again help me understand the process better, and thus propose a
> more elaborated and realistic time-line.
> 
> Thanks and Regards
> Udit agarwal
> 

Hello Udit,

there is no step-by-step guide (or any other guide) regarding a complete
FreeBSD update. That has to do with the fact that there is no standard
way to do it. Each update is quite unique.

The basic steps are the following ones:

- Use the freebsd-to-rtems.py script to move the changes to freebsd-org
folder.

- Rebase the changes in freebsd-org to the latest head.

- Re-Import the files with freebsd-to-rtems.py.

- Take a look at what changed in FreeBSD and fix everything.

The first three are easy. The last one is really hard if you don't know
the code.

I have seen that you are able to search through code quite quickly. But
I also have seen that you had some trouble with the mutex in the
getentropy patch. Although I'm sure you don't have problems learning the
necessary basics I think that it is quite likely that it will use up too
much time of the project. So I would suggest to plan the alternative
solution: Backport the driver. Although with that there will be no patch
that we can integrate into the current libbsd, it is a solution that is
doable in the scope of your GSoC project.

If you prefer to produce code that will be integrated quickly, you can
still think about the other libbsd projects.

Regards

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

Re: Query regarding libbsd update

2018-03-17 Thread Udit agarwal

Hi,
Thanks for pointing that out. I think back porting the driver would be the
most viable option. So, i'll move ahead with that.
Since, my proposal is almost ready, considering other libbsd projects at
this time, would be a bit difficult.

Thanks and regards,
Udit agarwal

On Sun, Mar 18, 2018 at 2:39 AM, Christian Mauderer 
wrote:

> Am 17.03.2018 um 19:40 schrieb Udit agarwal:
> > Hi Sebastian, Hi all,
> > One part of my GSoC project consists of importing SDIO driver from
> > FreeBSD head (as on july 2017 or later). As far as importing is
> > concerned there is a lot of information in libbsd.txt or on previous
> > GSoC student's blogs which can help me understand the process. However,
> > before importing i also need to update libbsd base to FreeBSD head(as on
> > july 2017 or later). I couldn't find much information regarding this
> > update process. It would be really helpful if you point me towards its
> > relevant documentation or give me a gist of the whole process. That
> > would again help me understand the process better, and thus propose a
> > more elaborated and realistic time-line.
> >
> > Thanks and Regards
> > Udit agarwal
> >
>
> Hello Udit,
>
> there is no step-by-step guide (or any other guide) regarding a complete
> FreeBSD update. That has to do with the fact that there is no standard
> way to do it. Each update is quite unique.
>
> The basic steps are the following ones:
>
> - Use the freebsd-to-rtems.py script to move the changes to freebsd-org
> folder.
>
> - Rebase the changes in freebsd-org to the latest head.
>
> - Re-Import the files with freebsd-to-rtems.py.
>
> - Take a look at what changed in FreeBSD and fix everything.
>
> The first three are easy. The last one is really hard if you don't know
> the code.
>
> I have seen that you are able to search through code quite quickly. But
> I also have seen that you had some trouble with the mutex in the
> getentropy patch. Although I'm sure you don't have problems learning the
> necessary basics I think that it is quite likely that it will use up too
> much time of the project. So I would suggest to plan the alternative
> solution: Backport the driver. Although with that there will be no patch
> that we can integrate into the current libbsd, it is a solution that is
> doable in the scope of your GSoC project.
>
> If you prefer to produce code that will be integrated quickly, you can
> still think about the other libbsd projects.
>
> Regards
>
> Christian Mauderer
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RSB build failure

2018-03-17 Thread Chris Johns

On 17/3/18 9:00 pm, Amaan Cheval wrote:
>> checking for python...
> /Library/Frameworks/Python.framework/Versions/2.7/bin/python
>> checking for python2.7... no
>> configure: error: python is missing or unusable
> 
> That looks like the problem (at least on the surface). macOS does come with
> Python built-in, but I don't believe that's good enough for development

The default Python is fine for use with GDB and the RSB. There is no problem
with the default provided by Apple on MacOS.

$ uname -a
Darwin huia 17.4.0 Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017;
root:xnu-4570.41.2~1/RELEASE_X86_64 x86_64
$ type python
python is /usr/bin/python
$ python --version
Python 2.7.10
$ python
Python 2.7.10 (default, Jul 15 2017, 17:16:57)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.31)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D

Finally this a recent build result on a Mac Mini I have set up to check RTEMS
builds:

https://lists.rtems.org/pipermail/build/2018-February/000521.html

I have XCode installed with the command line package.

> (vague memories only of issues) 

I have been testing on a range of MacOS versions over the years and I have not
seen any issues report. If you have seen issues or you know of reports please
let me know.

> - have you installed Python separately too?

If yo do this or you are using homebrew, mscports or something else then you may
have issues and you will need to look for support with those packaging projects.

I do not have any packages from homebrew or macports so we know the RSB is 
working.

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

Re: RSB build failure

>I have been testing on a range of MacOS versions over the years and I have
not
seen any issues report. If you have seen issues or you know of reports
please
let me know.

I was able to setup the environment successfully yesterday. Though in the
process I had another error which I managed to deal with. PFA the attached
report. Its about the relocation of the libexpat to github. I manually
downloaded the tar file and put it in the required sources folder.

>I have XCode installed with the command line package.

I also have this. I had python packages installed using homebrew too which
weren't in the PATH variable. Adding them to the path solved the issue.



On Sun, Mar 18, 2018 at 8:41 AM, Chris Johns  wrote:

> On 17/3/18 9:00 pm, Amaan Cheval wrote:
> >> checking for python...
> > /Library/Frameworks/Python.framework/Versions/2.7/bin/python
> >> checking for python2.7... no
> >> configure: error: python is missing or unusable
> >
> > That looks like the problem (at least on the surface). macOS does come
> with
> > Python built-in, but I don't believe that's good enough for development
>
> The default Python is fine for use with GDB and the RSB. There is no
> problem
> with the default provided by Apple on MacOS.
>
> $ uname -a
> Darwin huia 17.4.0 Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST
> 2017;
> root:xnu-4570.41.2~1/RELEASE_X86_64 x86_64
> $ type python
> python is /usr/bin/python
> $ python --version
> Python 2.7.10
> $ python
> Python 2.7.10 (default, Jul 15 2017, 17:16:57)
> [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.31)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> ^D
>
> Finally this a recent build result on a Mac Mini I have set up to check
> RTEMS
> builds:
>
> https://lists.rtems.org/pipermail/build/2018-February/000521.html
>
> I have XCode installed with the command line package.
>
> > (vague memories only of issues)
>
> I have been testing on a range of MacOS versions over the years and I have
> not
> seen any issues report. If you have seen issues or you know of reports
> please
> let me know.
>
> > - have you installed Python separately too?
>
> If yo do this or you are using homebrew, mscports or something else then
> you may
> have issues and you will need to look for support with those packaging
> projects.
>
> I do not have any packages from homebrew or macports so we know the RSB is
> working.
>
> Chris
>
RTEMS Tools Project - Source Builder Error Report
 Build: error: downloading 
https://github.com/libexpat/libexpat/releases/download/R_2_1_0/expat-2.1.0.tar.gz:
 all paths have failed, giving up
 Command Line: ../source-builder/sb-set-builder 
--prefix=/Users/vidushi/development/rtems/5 5/rtems-sparc
 Python: 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 12:01:12) [GCC 4.2.1 (Apple 
Inc. build 5666) (dot 3)]
 
git://git.rtems.org/rtems-source-builder.git/origin/4b3e0f8e3d6998b84a2503dd2e11578989b1672b
 Darwin Vidushis-MacBook-Air.local 16.7.0 Darwin Kernel Version 16.7.0: Thu Jan 
11 22:59:40 PST 2018; root:xnu-3789.73.8~1/RELEASE_X86_64 x86_64
Tail of the build log:
x automake-1.12.6/t/libobj4.sh
x automake-1.12.6/t/check4-w.sh
x automake-1.12.6/t/libtoo10.sh
x automake-1.12.6/t/pr72.sh
x automake-1.12.6/t/dejagnu6.sh
x automake-1.12.6/t/override-html.sh
x automake-1.12.6/t/check-tests-in-builddir.sh
x automake-1.12.6/t/am-missing-prog.sh
x automake-1.12.6/t/aclocal7.sh
x automake-1.12.6/t/cygnus-no-installinfo.sh
x automake-1.12.6/t/pr266.sh
x automake-1.12.6/t/auxdir8.sh
x automake-1.12.6/t/self-check-is_newest.tap
x automake-1.12.6/t/cygnus-dependency-tracking.sh
x automake-1.12.6/t/parallel-tests-interrupt.tap
x automake-1.12.6/t/badline.sh
x automake-1.12.6/t/ar3.sh
x automake-1.12.6/t/location.sh
x automake-1.12.6/t/substtarg.sh
x automake-1.12.6/t/instsh3.sh
x automake-1.12.6/automake.in
x automake-1.12.6/doc/
x automake-1.12.6/doc/amhello/
x automake-1.12.6/doc/amhello/Makefile.am
x automake-1.12.6/doc/amhello/README
x automake-1.12.6/doc/amhello/src/
x automake-1.12.6/doc/amhello/src/Makefile.am
x automake-1.12.6/doc/amhello/src/main.c
x automake-1.12.6/doc/amhello/configure.ac
x automake-1.12.6/doc/automake.info-2
x automake-1.12.6/doc/automake.info
x automake-1.12.6/doc/amhello-1.0.tar.gz
x automake-1.12.6/doc/automake.info-3
x automake-1.12.6/doc/automake-history.info
x automake-1.12.6/doc/fdl.texi
x automake-1.12.6/doc/automake.info-1
x automake-1.12.6/doc/automake.texi
x automake-1.12.6/doc/automake-history.texi
x automake-1.12.6/doc/version.texi
x automake-1.12.6/doc/stamp-vti
x automake-1.12.6/doc/help2man
x automake-1.12.6/aclocal.m4
x automake-1.12.6/NEWS
+ cd automake-1.12.6
+ /bin/chmod -R a+rX,g-w,o-w .
+ /bin/cat 
/Users/vidushi/development/rtems/rsb/rtems/patches/automake-1.12.6-bugzilla.redhat.com-1239379.diff
+ /usr/bin/patch -p1
patching file automake.in
+ cd 
/Users/vidushi/development/rtems/rsb/rtems/build/automake-1.12.6-x86_64-apple-darwin16.7.0-1
+ SB_CXC=no
==> clean %{buildroot}: 
/Users/vi

Re: RSB build failure

2018-03-17 Thread Chris Johns

On 18/3/18 2:31 pm, Vidushi Vashishth wrote:
>>I have been testing on a range of MacOS versions over the years and I have not
> seen any issues report. If you have seen issues or you know of reports please
> let me know. 
> 
> I was able to setup the environment successfully yesterday. Though in the
> process I had another error which I managed to deal with. PFA the attached
> report. Its about the relocation of the libexpat to github. I manually
> downloaded the tar file and put it in the required sources folder.
> 

Interesting. Please raise a ticket, set the component to rsb and assign to me. I
will take a look next week. I cannot remember if I deleted the source tarball on
MacOS and tested this.

>>I have XCode installed with the command line package.
> 
> I also have this. I had python packages installed using homebrew too which
> weren't in the PATH variable. Adding them to the path solved the issue.
> 

Thanks for reporting this. That clears up what was happening.

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

Re: RSB build failure

>Interesting. Please raise a ticket, set the component to rsb and assign to
me. I
will take a look next week. I cannot remember if I deleted the source
tarball on
MacOS and tested this.

Done. The ticket is #3355

Best,
Vidushi

On Sun, Mar 18, 2018 at 9:07 AM, Chris Johns  wrote:

> On 18/3/18 2:31 pm, Vidushi Vashishth wrote:
> >>I have been testing on a range of MacOS versions over the years and I
> have not
> > seen any issues report. If you have seen issues or you know of reports
> please
> > let me know.
> >
> > I was able to setup the environment successfully yesterday. Though in the
> > process I had another error which I managed to deal with. PFA the
> attached
> > report. Its about the relocation of the libexpat to github. I manually
> > downloaded the tar file and put it in the required sources folder.
> >
>
> Interesting. Please raise a ticket, set the component to rsb and assign to
> me. I
> will take a look next week. I cannot remember if I deleted the source
> tarball on
> MacOS and tested this.
>
> >>I have XCode installed with the command line package.
> >
> > I also have this. I had python packages installed using homebrew too
> which
> > weren't in the PATH variable. Adding them to the path solved the issue.
> >
>
> Thanks for reporting this. That clears up what was happening.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Improve coverage analysis toolset

It worked !
It's great to see it running ! I have attached the result .

-- vijay

On 18 March 2018 at 02:31, Cillian O'Donnell  wrote:

>
>
> On 17 March 2018 at 20:08, Vijay Kumar Banerjee 
> wrote:
>
>> yes it prints hello world
>>
>
> Alright I've added an .ini for leon3-qemu to the current rtems-tools. Pull
> this branch
>
> https://github.com/cillianodonnell/rtems-tools/tree/ini-update
>
> and try
>
> $HOME/development/rtems/test/rtems-tools/tester/rtems-test
> --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
> --rtems-bsp=leon3_qemu $HOME/development/rtems/leon3/sparc-rtems5/c/leon3/
> testsuites/samples
>
>>
>> -- vijay
>>
>> On 18 March 2018 at 01:31, Cillian O'Donnell 
>> wrote:
>>
>>> If you run just one test by itself without rtems-test
>>>
>>> qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M
>>> leon3_generic -kernel $HOME/development/rtems/leon3/
>>> sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
>>>
>>> Does the hello world print out?
>>>
>>> On 17 March 2018 at 14:46, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 I built it manually

 the environment variable PATH looks like this
 /home/lunatic/qemu/install/bin:/home/lunatic/development/rte
 ms/5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/
 home/lunatic/.local/bin:/home/lunatic/bin

 I tried to run rtems-test again without --coverage , it gives the same
 result
 I have attached the log.

 -- vijay

 On 17 March 2018 at 00:55, Cillian O'Donnell 
 wrote:

> Yes this is something more than my build, I'll need someone a bit more
> expert in the RSB to step in there. In the meantime, lets just build
> couverture-qemu manually so we can see is everything else working.
>
> git clone https://github.com/AdaCore/qemu
>
> cd qemu
>
> ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
> --disable-docs --disable-virtfs --disable-werror
>
> make
>
> make install
>
> then add the prefix to $PATH in .bashrc as well like before.
>
> export PATH=$HOME/qemu/install/bin:$PATH
>
> Then run rtem-test and see what happens
>
>
> On 16 March 2018 at 19:13, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> the same error comes when I try to build qemu from the
>> RTEMS/rtems-source-builder as well
>>
>> is the issue coming from my system ? I'm using fedora 27 64bit
>>
>> On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> yes , the same thing happens
>>>
>>> On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" <
>>> cpodonne...@gmail.com> wrote:
>>>
 If you build regular qemu with the RSB, does the same thing happen?

 Try

 ../source-builder/sb-set-builder --log=qemu_log.txt
 --prefix=$HOME/development/5 devel/qemu


 On 16 March 2018 at 16:48, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> still the same error
>
> -- vijay
>
> On 16 March 2018 at 21:39, Cillian O'Donnell <
> cpodonne...@gmail.com> wrote:
>
>> Just checked and the build was failing because one of the patches
>> needed its hash to be updated to sha256. Just pushed that change. 
>> The build
>> finishes successfully on my end. Pull that change into 
>> couverture-build
>> branch and try it again. I'm not seeing any automake stuff here, so 
>> just
>> check that and let me know.
>>
>> On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> building couverture-qemu from rtems-source-builder (
>>> https://github.com/cillianodonnell/rtems-source-builder/tr
>>> ee/couverture-build )
>>> gives error building auromake-1.12.6-x86_64-linux-gnu-1 .
>>>
>>> I have attached the error report .
>>>
>>> -- vijay
>>>
>>> On 15 March 2018 at 19:17, Cillian O'Donnell <
>>> cpodonne...@gmail.com> wrote:
>>>


 On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> It runs with a bunch of errors . I have attached the log file
>

 Ok, I'm guessing you didn't set up Couverture-Qemu (special
 version of qemu designed for generating extra trace data for 
 coverage
 analysis). That's what those errors are about. I have an RSB build 
 for that.

 https://github.com/cillianodonnell/rtems-source-builder/tree
 /couverture-build

 and the instructions

Re: Improve coverage analysis toolset