Re: x86_64 gcc missing crti/n

[Sebastian Huber]

I already checked it in, it did build fine.

- Joel Sherrill  schrieb:
> Definitely fixes. Posting patch now.
> 
> On Thu, Mar 14, 2019 at 1:49 PM Joel Sherrill  wrote:
> 
> > LOL. I thought i would fix it while you were asleep. I have a build now.
> >
> > On Thu, Mar 14, 2019 at 1:46 PM Sebastian Huber <
> > sebastian.hu...@embedded-brains.de> wrote:
> >
> >> - Am 14. Mrz 2019 um 19:15 schrieb joel j...@rtems.org:
> >>
> >> > On Thu, Mar 14, 2019 at 1:11 PM Sebastian Huber <
> >> > sebastian.hu...@embedded-brains.de> wrote:
> >> >
> >> >> - Am 14. Mrz 2019 um 18:29 schrieb Amaan Cheval
> >> amaan.che...@gmail.com
> >> >> :
> >> >>
> >> >> > Quick note; I'm not at the computer, but I haven't tested with the
> >> RTEMS
> >> >> 6
> >> >> > buildsets - I can do that tomorrow too.
> >> >>
> >> >> The RTEMS 6 tool chain should not use patches. It is intended to test
> >> the
> >> >> upstream versions.
> >> >>
> >> >> Why can't we use GCC 9 for x86_64 just like for riscv and or1k?
> >> >>
> >> >
> >> > That sounds reasonable to me. It won't be an outlier and we have no
> >> > deployed systems on
> >> > x86_64 to worry about..
> >>
> >> Ok, I changed it to GCC 9. I hope this fixes the BSP build issues.
> >>
> >

-- 
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: Query Regarding Old Projects, for GSoC 2019

[Vaibhav Gupta]

On Fri, 15 Mar, 2019, 12:27 AM Joel Sherrill  It's always good to discuss old project ideas and make sure they are still
> sane and useful.
>
Yes I agree, I meant for GSoC I am focusing on "POSIX Compilance"
But any project ideas, old/new, always trigger my curiosity, the reason I
asked it in the query, we can work on it.

>
> On the POSIX Compliance, I am make sure it is said publicly that methods
> included in
> FACE Technical Standard profiles that are missing are the highest priority
> to add. And
> this is documented in the Compliance document.
>
Yah it was clear. I am following the steps you said.
-Have got FACE Technical Standard pdf.
-I found that aio.h has got its palce in newlib.
-Still exploring and analysing.

>
> On Thu, Mar 14, 2019 at 12:34 AM Vaibhav Gupta 
> wrote:
>
>> After having off-list discussion with Dr Joel, I have already got a
>> direction in project "POSIX Compilance" and I am giving my all time,
>> solely, on that only.
>> .
>> But I am thankful to community that they gave their attention on this
>> query, of mine.
>>
>> On Tue, Mar 12, 2019 at 3:56 PM Vaibhav Gupta 
>> wrote:
>>
>>>
>>> On Mon, Mar 11, 2019 at 3:24 AM Joel Sherrill  wrote:
>>>


 On Sun, Mar 10, 2019, 3:57 PM Chris Johns  wrote:

> On 11/3/19 9:06 am, Joel Sherrill wrote:
> > On Sun, Mar 10, 2019, 2:29 PM Chris Johns  > > wrote:
> >
> > On 6/3/19 10:23 pm, Amaan Cheval wrote:
> > > I'm not sure if the project is open, but if it is, I'd be
> willing to
> > co-mentor.
> >
> > Thanks.
> >
> > >
> > > On Wed, Mar 6, 2019, 2:45 PM Vaibhav Gupta <
> vaibhavgupt...@gmail.com
> > 
> > > >> wrote:
> > >
> > > I was exploring for more open projects and found the
> following one.
> > >
> > > - Port V8 Javascript Engine :
> > > https://devel.rtems.org/wiki/Developer/Projects/Open/V8
> > >
> > > Not much information is given about it and even the above
> link was
> > modified
> > > in 2015. I want to know if the project is open for GSOC
> 2019?
> > > If it is open, then It would be great to know if someone
> would like to
> > > mentor it. I would like to discuss further on it.
> >
> > I suggest you create a ticket for this project like the other
> GSoC tickets we
> > have and add some additional details ..
> >
> > - Please list the archs supported, this is viewable in the src
> tree.
> > - Add something about needing Chromium's depot_tools. I see
> FreeBSD is not
> >   listed but chromium is available on FreeBSD.
> > - Investigate the build system and if it is possible to
> cross-compile.
> >
> > I'm a bit concerned that it may require things RTEMS does not have.
>
> If it cannot be cross-compiled it would be hard to maintain long term.
>
> > Does it mmap in ways we don't support?
>
> I also wondered. There is an abstraction in the POSIX platform code
> for mmap so
> a grep would let us know.
>
> > I doubt it forks new processes but that has to be answered.
>
> Yeap.
>
> > Some basic research plus an attempt to compile it for RTEMS with
> > problem sections disabled is a good first step of any porting
> evaluation.
>
> Yes.
>
> > FWIW I looked at porting the PDF viewer from chromium to RTEMS.
> Their build
> > system seemed quite complex.
>
> Firefox uses a js project held in github (
> https://github.com/mozilla/pdf.js/).
>

 +1

 Just to be clear, I am not discouraging this as a project. I just think
 it needs some homework to.make sure it is feasible.

>>> I will check the things.
>>>

> Chris
>

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

Re: x86_64 gcc missing crti/n

[Joel Sherrill]

Definitely fixes. Posting patch now.

On Thu, Mar 14, 2019 at 1:49 PM Joel Sherrill  wrote:

> LOL. I thought i would fix it while you were asleep. I have a build now.
>
> On Thu, Mar 14, 2019 at 1:46 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> - Am 14. Mrz 2019 um 19:15 schrieb joel j...@rtems.org:
>>
>> > On Thu, Mar 14, 2019 at 1:11 PM Sebastian Huber <
>> > sebastian.hu...@embedded-brains.de> wrote:
>> >
>> >> - Am 14. Mrz 2019 um 18:29 schrieb Amaan Cheval
>> amaan.che...@gmail.com
>> >> :
>> >>
>> >> > Quick note; I'm not at the computer, but I haven't tested with the
>> RTEMS
>> >> 6
>> >> > buildsets - I can do that tomorrow too.
>> >>
>> >> The RTEMS 6 tool chain should not use patches. It is intended to test
>> the
>> >> upstream versions.
>> >>
>> >> Why can't we use GCC 9 for x86_64 just like for riscv and or1k?
>> >>
>> >
>> > That sounds reasonable to me. It won't be an outlier and we have no
>> > deployed systems on
>> > x86_64 to worry about..
>>
>> Ok, I changed it to GCC 9. I hope this fixes the BSP build issues.
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] rtems-x86_64.bset: Bump to gcc 9 to have crti/n

[Joel Sherrill]

---
 rtems/config/5/rtems-x86_64.bset | 9 +
 1 file changed, 9 insertions(+)

diff --git a/rtems/config/5/rtems-x86_64.bset b/rtems/config/5/rtems-x86_64.bset
index 2d6ff5f..bbcd7ca 100644
--- a/rtems/config/5/rtems-x86_64.bset
+++ b/rtems/config/5/rtems-x86_64.bset
@@ -3,3 +3,12 @@
 %define with_libgomp
 
 %include 5/rtems-default.bset
+
+5/rtems-autotools
+
+devel/expat-2.1.0-1
+tools/rtems-gdb-8.2.1-1
+tools/rtems-binutils-2.32
+tools/rtems-gcc-89338f04ee3-newlib-1d35a003f
+tools/rtems-tools-5-1
+tools/rtems-kernel-5
-- 
1.8.3.1

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

Re: [PATCH] leon2-sis.ini, leon3-sis.ini: Correct run arguments

[Joel Sherrill]

I will double check that it works without.

Thanks.

On Thu, Mar 14, 2019 at 8:44 AM Jiri Gaisler  wrote:

> I don't think this patch is necessary, the -r option is already present
> and does not need to be duplicated.
>
> Jiri.
>
> On 2019-03-14 14:21, Joel Sherrill wrote:
> > ---
> >   tester/rtems/testing/bsps/leon2-sis.ini | 2 +-
> >   tester/rtems/testing/bsps/leon3-sis.ini | 2 +-
> >   2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tester/rtems/testing/bsps/leon2-sis.ini
> b/tester/rtems/testing/bsps/leon2-sis.ini
> > index 61205ad..d0dd315 100644
> > --- a/tester/rtems/testing/bsps/leon2-sis.ini
> > +++ b/tester/rtems/testing/bsps/leon2-sis.ini
> > @@ -36,4 +36,4 @@ bsp  = leon2
> >   arch = sparc
> >   tester   = %{_rtscripts}/run.cfg
> >   bsp_run_cmd  = %{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-sis
> > -bsp_run_opts = -leon2 -nouartrx -r -tlim 200 s
> > +bsp_run_opts = -r -leon2 -nouartrx -r -tlim 200 s
> > diff --git a/tester/rtems/testing/bsps/leon3-sis.ini
> b/tester/rtems/testing/bsps/leon3-sis.ini
> > index 2f933a7..9e8111f 100644
> > --- a/tester/rtems/testing/bsps/leon3-sis.ini
> > +++ b/tester/rtems/testing/bsps/leon3-sis.ini
> > @@ -36,4 +36,4 @@ bsp  = leon3
> >   arch = sparc
> >   tester   = %{_rtscripts}/run.cfg
> >   bsp_run_cmd  = %{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-sis
> > -bsp_run_opts = -leon3 -nouartrx -r -tlim 200 s -m 4
> > +bsp_run_opts = -r -leon3 -nouartrx -r -tlim 200 s -m 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: Query Regarding Old Projects, for GSoC 2019

[Joel Sherrill]

It's always good to discuss old project ideas and make sure they are still
sane and useful.

On the POSIX Compliance, I am make sure it is said publicly that methods
included in
FACE Technical Standard profiles that are missing are the highest priority
to add. And
this is documented in the Compliance document.

On Thu, Mar 14, 2019 at 12:34 AM Vaibhav Gupta 
wrote:

> After having off-list discussion with Dr Joel, I have already got a
> direction in project "POSIX Compilance" and I am giving my all time,
> solely, on that only.
> .
> But I am thankful to community that they gave their attention on this
> query, of mine.
>
> On Tue, Mar 12, 2019 at 3:56 PM Vaibhav Gupta 
> wrote:
>
>>
>> On Mon, Mar 11, 2019 at 3:24 AM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Sun, Mar 10, 2019, 3:57 PM Chris Johns  wrote:
>>>
 On 11/3/19 9:06 am, Joel Sherrill wrote:
 > On Sun, Mar 10, 2019, 2:29 PM Chris Johns >>> > > wrote:
 >
 > On 6/3/19 10:23 pm, Amaan Cheval wrote:
 > > I'm not sure if the project is open, but if it is, I'd be
 willing to
 > co-mentor.
 >
 > Thanks.
 >
 > >
 > > On Wed, Mar 6, 2019, 2:45 PM Vaibhav Gupta <
 vaibhavgupt...@gmail.com
 > 
 > > >> vaibhavgupt...@gmail.com>>> wrote:
 > >
 > > I was exploring for more open projects and found the
 following one.
 > >
 > > - Port V8 Javascript Engine :
 > > https://devel.rtems.org/wiki/Developer/Projects/Open/V8
 > >
 > > Not much information is given about it and even the above
 link was
 > modified
 > > in 2015. I want to know if the project is open for GSOC
 2019?
 > > If it is open, then It would be great to know if someone
 would like to
 > > mentor it. I would like to discuss further on it.
 >
 > I suggest you create a ticket for this project like the other
 GSoC tickets we
 > have and add some additional details ..
 >
 > - Please list the archs supported, this is viewable in the src
 tree.
 > - Add something about needing Chromium's depot_tools. I see
 FreeBSD is not
 >   listed but chromium is available on FreeBSD.
 > - Investigate the build system and if it is possible to
 cross-compile.
 >
 > I'm a bit concerned that it may require things RTEMS does not have.

 If it cannot be cross-compiled it would be hard to maintain long term.

 > Does it mmap in ways we don't support?

 I also wondered. There is an abstraction in the POSIX platform code for
 mmap so
 a grep would let us know.

 > I doubt it forks new processes but that has to be answered.

 Yeap.

 > Some basic research plus an attempt to compile it for RTEMS with
 > problem sections disabled is a good first step of any porting
 evaluation.

 Yes.

 > FWIW I looked at porting the PDF viewer from chromium to RTEMS. Their
 build
 > system seemed quite complex.

 Firefox uses a js project held in github (
 https://github.com/mozilla/pdf.js/).

>>>
>>> +1
>>>
>>> Just to be clear, I am not discouraging this as a project. I just think
>>> it needs some homework to.make sure it is feasible.
>>>
>> I will check the things.
>>
>>>
 Chris

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

Re: x86_64 gcc missing crti/n

[Amaan Cheval]

Quick note; I'm not at the computer, but I haven't tested with the RTEMS 6
buildsets - I can do that tomorrow too.

On Thu, Mar 14, 2019, 10:52 PM Amaan Cheval  wrote:

> Hey!
>
> It seems like the RSB patch for crt[i/n] was mistakenly taken out
> along with other stuff:
>
> https://git.rtems.org/rtems-source-builder/commit/?id=258129e140a2f0c7f579492bda2a86c6c1b93080
>
> I'm on a new computer where I'll have to compile git from source to
> use `send-email` to send the patch, so I've just attached it here -
> hope that's okay! (I can send it properly tomorrow if we want the
> community to review it.)
>
> I've tested that with this patch, the RTEMS kernel does successfully build.
>
>
> On Thu, Mar 14, 2019 at 8:52 PM Joel Sherrill  wrote:
> >
> > Hi
> >
> > Sebastian mentioned that x86_64 gcc is missing crti/n. I looked on the
> > GCC master and the code is in libgcc/config.host. This is in
> > libgcc/config.host on the master. I am assuming it  isn't in gcc 7.4.0
> > and the RSB is missing a patch.
> >
> > x86_64-*-elf* | x86_64-*-rtems*)
> > tmake_file="$tmake_file i386/t-crtstuff t-crtstuff-pic
> t-libgcc-pic"
> > case ${host} in
> >   x86_64-*-rtems*)
> > extra_parts="$extra_parts crti.o crtn.o"
> > ;;
> > esac
> > ;;
> >
> > Thanks to git blame, the code is from Amaan and the github URL
> > for the patch is:
> >
> >
> https://github.com/gcc-mirror/gcc/commit/ab55f7db3694293e4799d58f7e1a556c0eae863a
> >
> > Amaan.. care to prepare an RSB patch so crti/n is included in the tools
> from the
> > RSB. Please and thank you.
> >
> > --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 gcc missing crti/n

[Amaan Cheval]

Hey!

It seems like the RSB patch for crt[i/n] was mistakenly taken out
along with other stuff:
https://git.rtems.org/rtems-source-builder/commit/?id=258129e140a2f0c7f579492bda2a86c6c1b93080

I'm on a new computer where I'll have to compile git from source to
use `send-email` to send the patch, so I've just attached it here -
hope that's okay! (I can send it properly tomorrow if we want the
community to review it.)

I've tested that with this patch, the RTEMS kernel does successfully build.


On Thu, Mar 14, 2019 at 8:52 PM Joel Sherrill  wrote:
>
> Hi
>
> Sebastian mentioned that x86_64 gcc is missing crti/n. I looked on the
> GCC master and the code is in libgcc/config.host. This is in
> libgcc/config.host on the master. I am assuming it  isn't in gcc 7.4.0
> and the RSB is missing a patch.
>
> x86_64-*-elf* | x86_64-*-rtems*)
> tmake_file="$tmake_file i386/t-crtstuff t-crtstuff-pic t-libgcc-pic"
> case ${host} in
>   x86_64-*-rtems*)
> extra_parts="$extra_parts crti.o crtn.o"
> ;;
> esac
> ;;
>
> Thanks to git blame, the code is from Amaan and the github URL
> for the patch is:
>
> https://github.com/gcc-mirror/gcc/commit/ab55f7db3694293e4799d58f7e1a556c0eae863a
>
> Amaan.. care to prepare an RSB patch so crti/n is included in the tools from 
> the
> RSB. Please and thank you.
>
> --joel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
From edd8d1090eaf35a56346af8130b1d1a73fcb2d56 Mon Sep 17 00:00:00 2001
From: Amaan Cheval 
Date: Thu, 14 Mar 2019 22:26:48 +0530
Subject: [PATCH] 5: Fix x86_64 GCC build to include crt[in].o

This was mistakenly removed in commit 258129e, but is still required.
---
 rtems/config/5/rtems-x86_64.bset | 4 
 1 file changed, 4 insertions(+)

diff --git a/rtems/config/5/rtems-x86_64.bset b/rtems/config/5/rtems-x86_64.bset
index 2d6ff5f..fef043d 100644
--- a/rtems/config/5/rtems-x86_64.bset
+++ b/rtems/config/5/rtems-x86_64.bset
@@ -3,3 +3,7 @@
 %define with_libgomp
 
 %include 5/rtems-default.bset
+
+# 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
-- 
2.21.0

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

x86_64 gcc missing crti/n

[Joel Sherrill]

Hi

Sebastian mentioned that x86_64 gcc is missing crti/n. I looked on the
GCC master and the code is in libgcc/config.host. This is in
libgcc/config.host on the master. I am assuming it  isn't in gcc 7.4.0
and the RSB is missing a patch.

x86_64-*-elf* | x86_64-*-rtems*)
tmake_file="$tmake_file i386/t-crtstuff t-crtstuff-pic t-libgcc-pic"
case ${host} in
  x86_64-*-rtems*)
extra_parts="$extra_parts crti.o crtn.o"
;;
esac
;;

Thanks to git blame, the code is from Amaan and the github URL
for the patch is:

https://github.com/gcc-mirror/gcc/commit/ab55f7db3694293e4799d58f7e1a556c0eae863a

Amaan.. care to prepare an RSB patch so crti/n is included in the tools
from the
RSB. Please and thank you.

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

Re: [PATCH] shell: Correct argument order of `mfill`

[Gedare Bloom]

Thank you Jonathan patches applied and tickets have closed properly.


On Tue, Mar 12, 2019 at 11:12 PM Jonathan Brandmeyer <
jbrandme...@planetiq.com> wrote:

> I apologize for the vagueness - It isn't clear which one is supposed
> to go against which branch.  The only distinguishing feature is the
> affected ticket number.  ticket 3723 is against the 4.10 branch, while
> 3722 is against the 4.11 branch.
>
> On Tue, Mar 12, 2019 at 9:04 PM Jonathan Brandmeyer
>  wrote:
> >
> > Close #3722.
> >
> > (cherry picked from commit 2e8a66d13f04015c0024a084578f720ceb15ea00)
> > ---
> >  cpukit/libmisc/shell/main_mfill.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/cpukit/libmisc/shell/main_mfill.c
> b/cpukit/libmisc/shell/main_mfill.c
> > index d8e2fcf74c..47a55d3a2f 100644
> > --- a/cpukit/libmisc/shell/main_mfill.c
> > +++ b/cpukit/libmisc/shell/main_mfill.c
> > @@ -60,7 +60,7 @@ static int rtems_shell_main_mfill(
> >/*
> > *  Now fill the memory.
> > */
> > -  memset(addr, size, value);
> > +  memset(addr, value, size);
> >
> >return 0;
> >  }
> > --
> > 2.11.0
> >
>
>
> --
> Jonathan Brandmeyer
> Engineering Director
> PlanetiQ
> ___
> 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 0/1] eng: Add software test framework chapter

[Gedare Bloom]

On Thu, Mar 14, 2019 at 9:42 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 14/03/2019 14:31, Gedare Bloom wrote:
> > Do we also want to document the adhoc testsuite here?
>
> For our pre-qualification project we need also a documentation about the
> test suites. I think this should go into a separate chapter or document.
>
>
Alright. If t-test framework is the expected way to do things moving
forward, then this is good to me.


> --
> 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 2/3] fifo.c: Eliminate logically dead code (Coverity 1437635)

[Gedare Bloom]

On Thu, Mar 14, 2019 at 9:22 AM Joel Sherrill  wrote:

> ---
>  cpukit/libfs/src/pipe/fifo.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/cpukit/libfs/src/pipe/fifo.c b/cpukit/libfs/src/pipe/fifo.c
> index 71d5f85..3275e5f 100644
> --- a/cpukit/libfs/src/pipe/fifo.c
> +++ b/cpukit/libfs/src/pipe/fifo.c
> @@ -149,18 +149,15 @@ static int pipe_new(
>pipe = *pipep;
>if (pipe == NULL) {
>  err = pipe_alloc();
> -if (err)
> -  goto out;
> +if (err) {
> +  pipe_unlock();
> +  return err;
> +}
>}
>
>PIPE_LOCK(pipe);
>
> -  if (*pipep == NULL) {
> -if (err)
> -  pipe_free(pipe);
> -else
> -  *pipep = pipe;
> -  }
> +  *pipep = pipe;
>
>  out:
>pipe_unlock();
>

you can also remove the 'out:' label, and probably return 0?


> --
> 1.8.3.1
>
> ___
> 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 3/3] main_edit.c: Use strncpy() to eliminate potential buffer overflow.

[Gedare Bloom]

On Thu, Mar 14, 2019 at 9:22 AM Joel Sherrill  wrote:

> ---
>  cpukit/libmisc/shell/main_edit.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/cpukit/libmisc/shell/main_edit.c
> b/cpukit/libmisc/shell/main_edit.c
> index 079e9ff..e43ff68 100644
> --- a/cpukit/libmisc/shell/main_edit.c
> +++ b/cpukit/libmisc/shell/main_edit.c
> @@ -286,7 +286,7 @@ static struct editor *find_editor(struct env *env,
> char *filename) {
>struct editor *ed = env->current;
>struct editor *start = ed;
>
> -  if (!realpath(filename, fn)) strcpy(fn, filename);
> +  if (!realpath(filename, fn)) strncpy(fn, filename, FILENAME_MAX);
>
>do {
>  if (strcmp(fn, ed->filename) == 0) return ed;
> @@ -297,7 +297,7 @@ static struct editor *find_editor(struct env *env,
> char *filename) {
>
>  static int new_file(struct editor *ed, char *filename) {
>if (*filename) {
> -strcpy(ed->filename, filename);
> +strncpy(ed->filename, filename, FILENAME_MAX);
>

if strlen(filename) > FILENAME_MAX, ed->filename will not be NUL-terminated.


>} else {
>  sprintf(ed->filename, "Untitled-%d", ++ed->env->untitled);
>  ed->newfile = 1;
>

Unrelated: why doesn't 'ed->newfile = 1;' happen down the other code path
(when a filename is given)?


> @@ -1752,7 +1752,7 @@ static void read_from_stdin(struct editor *ed) {
>  insert(ed, pos, (unsigned char*) buffer, n);
>  pos += n;
>}
> -  strcpy(ed->filename, "");
> +  strncpy(ed->filename, "", FILENAME_MAX);
>

overkill -- "" has a fixed known size.


>ed->newfile = 1;
>ed->dirty = 0;
>  }
> @@ -1775,7 +1775,8 @@ static void save_editor(struct editor *ed) {
>  return;
>}
>  }
> -strcpy(ed->filename, (const char*) ed->env->linebuf);
> +strncpy(
> +  ed->filename, (const char*) ed->env->linebuf, FILENAME_MAX);
>  ed->newfile = 0;
>}
>
> --
> 1.8.3.1
>
> ___
> 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] leon2-sis.ini, leon3-sis.ini: Correct run arguments

[Jiri Gaisler]

I don't think this patch is necessary, the -r option is already present 
and does not need to be duplicated.


Jiri.

On 2019-03-14 14:21, Joel Sherrill wrote:

---
  tester/rtems/testing/bsps/leon2-sis.ini | 2 +-
  tester/rtems/testing/bsps/leon3-sis.ini | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tester/rtems/testing/bsps/leon2-sis.ini 
b/tester/rtems/testing/bsps/leon2-sis.ini
index 61205ad..d0dd315 100644
--- a/tester/rtems/testing/bsps/leon2-sis.ini
+++ b/tester/rtems/testing/bsps/leon2-sis.ini
@@ -36,4 +36,4 @@ bsp  = leon2
  arch = sparc
  tester   = %{_rtscripts}/run.cfg
  bsp_run_cmd  = %{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-sis
-bsp_run_opts = -leon2 -nouartrx -r -tlim 200 s
+bsp_run_opts = -r -leon2 -nouartrx -r -tlim 200 s
diff --git a/tester/rtems/testing/bsps/leon3-sis.ini 
b/tester/rtems/testing/bsps/leon3-sis.ini
index 2f933a7..9e8111f 100644
--- a/tester/rtems/testing/bsps/leon3-sis.ini
+++ b/tester/rtems/testing/bsps/leon3-sis.ini
@@ -36,4 +36,4 @@ bsp  = leon3
  arch = sparc
  tester   = %{_rtscripts}/run.cfg
  bsp_run_cmd  = %{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-sis
-bsp_run_opts = -leon3 -nouartrx -r -tlim 200 s -m 4
+bsp_run_opts = -r -leon3 -nouartrx -r -tlim 200 s -m 4

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

Re: [PATCH 0/1] eng: Add software test framework chapter

[Sebastian Huber]

On 14/03/2019 14:31, Gedare Bloom wrote:

Do we also want to document the adhoc testsuite here?


For our pre-qualification project we need also a documentation about the 
test suites. I think this should go into a separate chapter or document.


--
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: BSP Basics in Doxygen Recommendations?

[Gedare Bloom]

On Thu, Mar 14, 2019 at 9:39 AM Gedare Bloom  wrote:

>
>
> On Thu, Mar 14, 2019 at 8:53 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello,
>>
>> I am about to update the Doxygen Recommendations in the RTEMS Software
>> Engineering handbook. Currently, there is a lot of other content mixed
>> in such as "BSP Basics". We should really try to avoid all the
>> duplication across the documentation set which is simply not
>> maintainable. What is the right spot for information relevant to a BSP
>> writer/maintainer (source tree layout, expected driver, documentation,
>> etc.)? Should this be
>>
>> * a section in the RTEMS Software Engineering handbook, or
>>
>> * a section in the RTEMS BSP and Driver Guide?
>>
>> Should the RTEMS BSP and Driver Guide be merged into the RTEMS Software
>> Engineering handbook?
>>
>>
> I don't think they entirely fit together. The SwE book is about processes
> and policies for RTEMS (along the path toward pre-qualification). The
> BSP/Driver guide includes some suggestions along those lines, but is mostly
> about implementation details and how to use certain driver/BSP frameworks
> we have in place. I think that maybe there should be a short
> section/chapter in the SwE that might provide the specific expectations
> (requirements, BSP-specific processes to follow, etc.) we have about BSPs,
> with the pointer to the BSP guide for implementers to follow.
>
> My two cents.
>
>
P.S. I'd just merge the '4.3.4 Doxygen Recommendations for BSPs' into the
BSP manual. It will need some editing too. (It was copied from the wiki
instructions intended for GCI students.)


> Gedare
>
> --
>> 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: BSP Basics in Doxygen Recommendations?

[Gedare Bloom]

On Thu, Mar 14, 2019 at 8:53 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> I am about to update the Doxygen Recommendations in the RTEMS Software
> Engineering handbook. Currently, there is a lot of other content mixed
> in such as "BSP Basics". We should really try to avoid all the
> duplication across the documentation set which is simply not
> maintainable. What is the right spot for information relevant to a BSP
> writer/maintainer (source tree layout, expected driver, documentation,
> etc.)? Should this be
>
> * a section in the RTEMS Software Engineering handbook, or
>
> * a section in the RTEMS BSP and Driver Guide?
>
> Should the RTEMS BSP and Driver Guide be merged into the RTEMS Software
> Engineering handbook?
>
>
I don't think they entirely fit together. The SwE book is about processes
and policies for RTEMS (along the path toward pre-qualification). The
BSP/Driver guide includes some suggestions along those lines, but is mostly
about implementation details and how to use certain driver/BSP frameworks
we have in place. I think that maybe there should be a short
section/chapter in the SwE that might provide the specific expectations
(requirements, BSP-specific processes to follow, etc.) we have about BSPs,
with the pointer to the BSP guide for implementers to follow.

My two cents.

Gedare

-- 
> 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: [PATCH 0/1] eng: Add software test framework chapter

[Gedare Bloom]

Do we also want to document the adhoc testsuite here?

On Thu, Mar 14, 2019 at 6:23 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> This patch adds a "Software Test Framework" to the "RTEMS Software
> Engineering" handbook.  A PDF document with this patch can be viewed here:
>
> https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf
>
> An example test report can be viewed here:
>
> https://ftp.rtems.org/pub/rtems/people/sebh/test-report.pdf
>
> This is just a proof of concept. For an example runtime measurement see
> "1.5 Test Suite - ClockTick".
>
> Sebastian Huber (1):
>   eng: Add software test framework chapter
>
>  eng/index.rst  |3 +
>  eng/test-framework.rst | 2077
> 
>  2 files changed, 2080 insertions(+)
>  create mode 100644 eng/test-framework.rst
>
> --
> 2.16.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: [PATCH 1/3] z85c30.c: Do not process 0 baud and return an error (CID 1399713)

[Sebastian Huber]

On 14/03/2019 14:22, Joel Sherrill wrote:

_Assert( baud_number != 0 );
  
+  /*

+   * POSIX says baud rate of zero is a request to hang up or disconnect.
+   * This is not supported by this driver.
+   */
+  _Assert( baud_number != 0 );


Duplicate assert.

--
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 2/3] fifo.c: Eliminate logically dead code (Coverity 1437635)

[Joel Sherrill]

---
 cpukit/libfs/src/pipe/fifo.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/cpukit/libfs/src/pipe/fifo.c b/cpukit/libfs/src/pipe/fifo.c
index 71d5f85..3275e5f 100644
--- a/cpukit/libfs/src/pipe/fifo.c
+++ b/cpukit/libfs/src/pipe/fifo.c
@@ -149,18 +149,15 @@ static int pipe_new(
   pipe = *pipep;
   if (pipe == NULL) {
 err = pipe_alloc();
-if (err)
-  goto out;
+if (err) {
+  pipe_unlock();
+  return err;
+}
   }
 
   PIPE_LOCK(pipe);
 
-  if (*pipep == NULL) {
-if (err)
-  pipe_free(pipe);
-else
-  *pipep = pipe;
-  }
+  *pipep = pipe;
 
 out:
   pipe_unlock();
-- 
1.8.3.1

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

[PATCH 1/3] z85c30.c: Do not process 0 baud and return an error (CID 1399713)

[Joel Sherrill]

---
 bsps/shared/dev/serial/z85c30.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/bsps/shared/dev/serial/z85c30.c b/bsps/shared/dev/serial/z85c30.c
index 55df9d3..d1f4a6f 100644
--- a/bsps/shared/dev/serial/z85c30.c
+++ b/bsps/shared/dev/serial/z85c30.c
@@ -456,6 +456,15 @@ Z85C30_STATIC int z85c30_set_attributes(
   baud_number = (uint32_t) rtems_termios_baud_to_number( baud_requested );
   _Assert( baud_number != 0 );
 
+  /*
+   * POSIX says baud rate of zero is a request to hang up or disconnect.
+   * This is not supported by this driver.
+   */
+  _Assert( baud_number != 0 );
+  if (baud_number == 0) {
+return -1;
+  }
+
   ulBaudDivisor = Z85C30_Baud(
 (uint32_t) Console_Port_Tbl[minor]->ulClock,
 baud_number
-- 
1.8.3.1

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

[PATCH 3/3] main_edit.c: Use strncpy() to eliminate potential buffer overflow.

[Joel Sherrill]

---
 cpukit/libmisc/shell/main_edit.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/cpukit/libmisc/shell/main_edit.c b/cpukit/libmisc/shell/main_edit.c
index 079e9ff..e43ff68 100644
--- a/cpukit/libmisc/shell/main_edit.c
+++ b/cpukit/libmisc/shell/main_edit.c
@@ -286,7 +286,7 @@ static struct editor *find_editor(struct env *env, char 
*filename) {
   struct editor *ed = env->current;
   struct editor *start = ed;
 
-  if (!realpath(filename, fn)) strcpy(fn, filename);
+  if (!realpath(filename, fn)) strncpy(fn, filename, FILENAME_MAX);
 
   do {
 if (strcmp(fn, ed->filename) == 0) return ed;
@@ -297,7 +297,7 @@ static struct editor *find_editor(struct env *env, char 
*filename) {
 
 static int new_file(struct editor *ed, char *filename) {
   if (*filename) {
-strcpy(ed->filename, filename);
+strncpy(ed->filename, filename, FILENAME_MAX);
   } else {
 sprintf(ed->filename, "Untitled-%d", ++ed->env->untitled);
 ed->newfile = 1;
@@ -1752,7 +1752,7 @@ static void read_from_stdin(struct editor *ed) {
 insert(ed, pos, (unsigned char*) buffer, n);
 pos += n;
   }
-  strcpy(ed->filename, "");
+  strncpy(ed->filename, "", FILENAME_MAX);
   ed->newfile = 1;
   ed->dirty = 0;
 }
@@ -1775,7 +1775,8 @@ static void save_editor(struct editor *ed) {
 return;
   }
 }
-strcpy(ed->filename, (const char*) ed->env->linebuf);
+strncpy(
+  ed->filename, (const char*) ed->env->linebuf, FILENAME_MAX);
 ed->newfile = 0;
   }
 
-- 
1.8.3.1

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

[PATCH] leon2-sis.ini, leon3-sis.ini: Correct run arguments

[Joel Sherrill]

---
 tester/rtems/testing/bsps/leon2-sis.ini | 2 +-
 tester/rtems/testing/bsps/leon3-sis.ini | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tester/rtems/testing/bsps/leon2-sis.ini 
b/tester/rtems/testing/bsps/leon2-sis.ini
index 61205ad..d0dd315 100644
--- a/tester/rtems/testing/bsps/leon2-sis.ini
+++ b/tester/rtems/testing/bsps/leon2-sis.ini
@@ -36,4 +36,4 @@ bsp  = leon2
 arch = sparc
 tester   = %{_rtscripts}/run.cfg
 bsp_run_cmd  = %{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-sis
-bsp_run_opts = -leon2 -nouartrx -r -tlim 200 s
+bsp_run_opts = -r -leon2 -nouartrx -r -tlim 200 s
diff --git a/tester/rtems/testing/bsps/leon3-sis.ini 
b/tester/rtems/testing/bsps/leon3-sis.ini
index 2f933a7..9e8111f 100644
--- a/tester/rtems/testing/bsps/leon3-sis.ini
+++ b/tester/rtems/testing/bsps/leon3-sis.ini
@@ -36,4 +36,4 @@ bsp  = leon3
 arch = sparc
 tester   = %{_rtscripts}/run.cfg
 bsp_run_cmd  = %{rtems_tools}/%{bsp_arch}-rtems%{rtems_version}-sis
-bsp_run_opts = -leon3 -nouartrx -r -tlim 200 s -m 4
+bsp_run_opts = -r -leon3 -nouartrx -r -tlim 200 s -m 4
-- 
1.8.3.1

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

BSP Basics in Doxygen Recommendations?

[Sebastian Huber]

Hello,

I am about to update the Doxygen Recommendations in the RTEMS Software 
Engineering handbook. Currently, there is a lot of other content mixed 
in such as "BSP Basics". We should really try to avoid all the 
duplication across the documentation set which is simply not 
maintainable. What is the right spot for information relevant to a BSP 
writer/maintainer (source tree layout, expected driver, documentation, 
etc.)? Should this be


* a section in the RTEMS Software Engineering handbook, or

* a section in the RTEMS BSP and Driver Guide?

Should the RTEMS BSP and Driver Guide be merged into the RTEMS Software 
Engineering handbook?


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: [rtems-bsp-builder] 2019-03-13 12:11:40: Profile(s): everything

[Sebastian Huber]

It seems that the BSP builder doesn't build the x86_64 architecture. If 
I build it by hand, on my system it fails with:


gmake[5]: Entering directory 
'/build/git-build/b-all-x86_64-5/x86_64-rtems5/c/amd64/testsuites/samples'
x86_64-rtems5-gcc  -mno-red-zone -mcmodel=large -Werror=return-type -O2 
-g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes 
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs 
-B./../../lib/libbsp/x86_64/amd64 
-B/home/EB/sebastian_h/git-rtems-5/bsps/x86_64/amd64/start -specs 
bsp_specs -qrtems -L./../../cpukit 
-L/home/EB/sebastian_h/git-rtems-5/bsps/x86_64/shared/start 
-Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -Wl,--gc-sections 
-o base_sp.exe base_sp/base_sp-init.o base_sp/base_sp-apptask.o 
./../../lib/libbsp/x86_64/amd64/librtemsbsp.a 
./../../cpukit/librtemscpu.a ./../../cpukit/librtemstest.a
/build/rtems/5/lib/gcc/x86_64-rtems5/7.4.0/../../../../x86_64-rtems5/bin/ld: 
cannot find crti.o: No such file or directory

collect2: error: ld returned 1 exit status

--
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 3/3] ttest01: New test

[Sebastian Huber]

This is an example test using the T Test Framework.  It tests also the
framework itself.

Add T_FILE_NAME command line define to get rid of the full file path.
This is important to reduce the read-only data of test files and make
them build system independent.

Update #3199.
---
 testsuites/automake/compile.am |   1 +
 testsuites/libtests/Makefile.am|  10 ++
 testsuites/libtests/configure.ac   |   1 +
 testsuites/libtests/ttest01/init.c | 164 +
 testsuites/libtests/ttest01/t-self-test.h  |  46 
 testsuites/libtests/ttest01/test-example.c |  57 ++
 testsuites/libtests/ttest01/ttest01.doc|  19 
 testsuites/libtests/ttest01/ttest01.scn|  26 +
 8 files changed, 324 insertions(+)
 create mode 100644 testsuites/libtests/ttest01/init.c
 create mode 100644 testsuites/libtests/ttest01/t-self-test.h
 create mode 100644 testsuites/libtests/ttest01/test-example.c
 create mode 100644 testsuites/libtests/ttest01/ttest01.doc
 create mode 100644 testsuites/libtests/ttest01/ttest01.scn

diff --git a/testsuites/automake/compile.am b/testsuites/automake/compile.am
index 83d4ab111c..66ea9a8421 100644
--- a/testsuites/automake/compile.am
+++ b/testsuites/automake/compile.am
@@ -11,6 +11,7 @@ STRIP = @STRIP@
 TEST_LD_FLAGS = -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar
 
 AM_CPPFLAGS = $(TEST_FLAGS) @RTEMS_CPPFLAGS@ @RTEMS_BSP_CPPFLAGS@
+AM_CPPFLAGS += -DT_FILE_NAME='"$(notdir $<)"'
 AM_CFLAGS   = $(TEST_C_FLAGS)
 AM_CXXFLAGS = $(TEST_CXX_FLAGS)
 
diff --git a/testsuites/libtests/Makefile.am b/testsuites/libtests/Makefile.am
index 789380ce72..3952979228 100644
--- a/testsuites/libtests/Makefile.am
+++ b/testsuites/libtests/Makefile.am
@@ -1448,6 +1448,16 @@ top_SOURCES = top/init.c top/task1.c top/task2.c 
top/task3.c \
 top_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_top) $(support_includes)
 endif
 
+if TEST_ttest01
+lib_tests += ttest01
+lib_screens += ttest01/ttest01.scn
+lib_docs += ttest01/ttest01.doc
+ttest01_SOURCES = ttest01/init.c
+ttest01_SOURCES += ttest01/test-example.c
+ttest01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_ttest01) \
+   $(support_includes)
+endif
+
 if TEST_tztest
 lib_tests += tztest
 lib_screens += tztest/tztest.scn
diff --git a/testsuites/libtests/configure.ac b/testsuites/libtests/configure.ac
index 3bcc0ec5c4..015f9eafa0 100644
--- a/testsuites/libtests/configure.ac
+++ b/testsuites/libtests/configure.ac
@@ -225,6 +225,7 @@ RTEMS_TEST_CHECK([termios07])
 RTEMS_TEST_CHECK([termios08])
 RTEMS_TEST_CHECK([termios09])
 RTEMS_TEST_CHECK([top])
+RTEMS_TEST_CHECK([ttest01])
 RTEMS_TEST_CHECK([tztest])
 RTEMS_TEST_CHECK([uid01])
 RTEMS_TEST_CHECK([unlink])
diff --git a/testsuites/libtests/ttest01/init.c 
b/testsuites/libtests/ttest01/init.c
new file mode 100644
index 00..141b89c93f
--- /dev/null
+++ b/testsuites/libtests/ttest01/init.c
@@ -0,0 +1,164 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2018, 2019 embedded brains GmbH
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+
+#include "t-self-test.h"
+
+#include 
+
+const char rtems_test_name[] = "TTEST 1";
+
+#define test_assert(e) (e) ? (void)0 : test_failed(__LINE__, #e)
+
+RTEMS_LINKER_ROSET(t_self_test, const char *);
+
+typedef struct {
+   const char *c;
+   BSP_output_char_function_type output_char;
+   size_t case_begin_count;
+   size_t case_end_count;
+} test_context;
+
+static test_context test_instance;
+
+static void
+test_failed(int line, const char *e)
+{
+   BSP_output_char = test_instance.output_char;
+   printk("FAILED:%i:%s\n", line, e);
+   

[PATCH 1/3] build: Move test support to librtemstest.a

[Sebastian Huber]

One reason to move the test support into a dedicated library are the
standard output __wrap_*() functions.  They may conflict with
application level wrappers.

Update #3199.
---
 cpukit/Makefile.am  | 14 +-
 cpukit/{libmisc/testsupport => libtest}/testbeginend.c  |  0
 cpukit/{libmisc/testsupport => libtest}/testbusy.c  |  0
 cpukit/{libmisc/testsupport => libtest}/testextension.c |  0
 cpukit/{libmisc/testsupport => libtest}/testparallel.c  |  0
 cpukit/{libmisc/testsupport => libtest}/testwrappers.c  |  0
 testsuites/ada/ada.am   |  2 +-
 testsuites/automake/compile.am  |  1 +
 8 files changed, 11 insertions(+), 6 deletions(-)
 rename cpukit/{libmisc/testsupport => libtest}/testbeginend.c (100%)
 rename cpukit/{libmisc/testsupport => libtest}/testbusy.c (100%)
 rename cpukit/{libmisc/testsupport => libtest}/testextension.c (100%)
 rename cpukit/{libmisc/testsupport => libtest}/testparallel.c (100%)
 rename cpukit/{libmisc/testsupport => libtest}/testwrappers.c (100%)

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 51ab18ca05..0081bb77cd 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -322,11 +322,6 @@ librtemscpu_a_SOURCES += 
libmisc/stringto/stringtounsignedchar.c
 librtemscpu_a_SOURCES += libmisc/stringto/stringtounsignedint.c
 librtemscpu_a_SOURCES += libmisc/stringto/stringtounsignedlong.c
 librtemscpu_a_SOURCES += libmisc/stringto/stringtounsignedlonglong.c
-librtemscpu_a_SOURCES += libmisc/testsupport/testbeginend.c
-librtemscpu_a_SOURCES += libmisc/testsupport/testbusy.c
-librtemscpu_a_SOURCES += libmisc/testsupport/testextension.c
-librtemscpu_a_SOURCES += libmisc/testsupport/testparallel.c
-librtemscpu_a_SOURCES += libmisc/testsupport/testwrappers.c
 librtemscpu_a_SOURCES += libmisc/untar/untar.c
 librtemscpu_a_SOURCES += libmisc/untar/untar_tgz.c
 librtemscpu_a_SOURCES += libmisc/untar/untar_txz.c
@@ -1834,6 +1829,15 @@ project_lib_LIBRARIES += librtemsdefaultconfig.a
 librtemsdefaultconfig_a_SOURCES =
 librtemsdefaultconfig_a_SOURCES += libmisc/dummy/default-configuration.c
 
+project_lib_LIBRARIES += librtemstest.a
+
+librtemstest_a_SOURCES =
+librtemstest_a_SOURCES += libtest/testbeginend.c
+librtemstest_a_SOURCES += libtest/testbusy.c
+librtemstest_a_SOURCES += libtest/testextension.c
+librtemstest_a_SOURCES += libtest/testparallel.c
+librtemstest_a_SOURCES += libtest/testwrappers.c
+
 project_lib_LIBRARIES += libftpd.a
 
 libftpd_a_SOURCES =
diff --git a/cpukit/libmisc/testsupport/testbeginend.c 
b/cpukit/libtest/testbeginend.c
similarity index 100%
rename from cpukit/libmisc/testsupport/testbeginend.c
rename to cpukit/libtest/testbeginend.c
diff --git a/cpukit/libmisc/testsupport/testbusy.c b/cpukit/libtest/testbusy.c
similarity index 100%
rename from cpukit/libmisc/testsupport/testbusy.c
rename to cpukit/libtest/testbusy.c
diff --git a/cpukit/libmisc/testsupport/testextension.c 
b/cpukit/libtest/testextension.c
similarity index 100%
rename from cpukit/libmisc/testsupport/testextension.c
rename to cpukit/libtest/testextension.c
diff --git a/cpukit/libmisc/testsupport/testparallel.c 
b/cpukit/libtest/testparallel.c
similarity index 100%
rename from cpukit/libmisc/testsupport/testparallel.c
rename to cpukit/libtest/testparallel.c
diff --git a/cpukit/libmisc/testsupport/testwrappers.c 
b/cpukit/libtest/testwrappers.c
similarity index 100%
rename from cpukit/libmisc/testsupport/testwrappers.c
rename to cpukit/libtest/testwrappers.c
diff --git a/testsuites/ada/ada.am b/testsuites/ada/ada.am
index 33d0c3ae2f..83260687c2 100644
--- a/testsuites/ada/ada.am
+++ b/testsuites/ada/ada.am
@@ -9,7 +9,7 @@ GNATCOMPILE = $(GNATMAKE) \
 -bargs -Mgnat_main \
 -margs $(AM_ADAFLAGS) $(ADAFLAGS) \
 -cargs $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) \
--largs $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) init.o
+-largs $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -lrtemstest init.o
 
 CLEANFILES += *.ali *.o b~*.adb b~*.ads
 
diff --git a/testsuites/automake/compile.am b/testsuites/automake/compile.am
index f7f0fb623f..83d4ab111c 100644
--- a/testsuites/automake/compile.am
+++ b/testsuites/automake/compile.am
@@ -24,5 +24,6 @@ AM_LDFLAGS += $(TEST_LD_FLAGS)
 LDADD =
 LDADD += $(RTEMS_ROOT)lib/libbsp/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@/librtemsbsp.a
 LDADD += $(RTEMS_ROOT)cpukit/librtemscpu.a
+LDADD += $(RTEMS_ROOT)cpukit/librtemstest.a
 
 CLEANFILES = *.num *.nxe *.elf *.srec* *.bin *.bt *.ralf
-- 
2.16.4

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