Re: GSOC POSIX Compliance: Stuck trying to build Newlib

[Vaibhav Gupta]

Hello Matthew,

On Wed, Jun 16, 2021 at 12:58 AM Joel Sherrill  wrote:
>
> @RTEMS_TOOLS_BIN@ should have been replaced with the real directory where 
> your RTEMS tools are located. Something like this:

Exactly. I was wondering the same when I saw his output of 'echo $PATH'.
Matthew, the newlib and autoconf relationship is a bit messy. But you
can simplify it if you use $PATH carefully.
Have a look at this
https://medium.com/my-gsoc-2019-journey/how-to-handle-two-versions-of-autoconf-b1e28de8617b,
the path should expand and should point to the correct binaries.

The blog should give you an idea of how the $PATH works and how it
should be modified.


-- Vaibhav Gupta
>
> $ export PATH=${HOME}/rtems-work/tools/6/bin:$PATH
>
> And to check you have the PATH right, do something like this:
>
> $ type sparc-rtems6-gcc
> sparc-rtems6-gcc is /home/joel/rtems-work/tools/6/bin/sparc-rtems6-gcc
>
> On Tue, Jun 15, 2021 at 1:23 PM Eshan Dhawan  wrote:
>>
>> Hi matt
>> It would work if run inside newlib instead of newlib-cygwin
>> run command inside of ../newlib-cygwin/newlib
>> instead of ../newlib-cygwin
>>
>>
>> On Tue, Jun 15, 2021 at 10:59 PM Matthew Joyce  wrote:
>>>
>>> Ah, ok will do! Thank you for the tip.
>>>
>>> On Tue, Jun 15, 2021 at 7:17 PM Gedare Bloom  wrote:
>>> >
>>> > Just a note, it's more efficient to capture your terminal dump into a
>>> > text file and attach that, rather than put a screenshot up.
>>> >
>>> > On Tue, Jun 15, 2021 at 11:14 AM Matthew Joyce  
>>> > wrote:
>>> > >
>>> > > Hi Gentlemen,
>>> > >
>>> > > Thanks very much for your quick replies!
>>> > >
>>> > > I just tried both, but perhaps I'm misinterpreting your suggestions.
>>> > > (Could you please see the attached commands / errors!)
>>> > >
>>> > > Eshan,
>>> > >
>>> > > I did see that link, but it wasn't clear to me what the solution 
>>> > > was...Sorry!
>>> > >
>>> > > Sincerely,
>>> > >
>>> > > Matt
>>> > >
>>> > > On Tue, Jun 15, 2021 at 6:52 PM Eshan Dhawan  
>>> > > wrote:
>>> > > >
>>> > > > Hi Matt,
>>> > > > Try running the command with autoconf version 2.69 that's shipped 
>>> > > > with RTEMS in the rtems bin
>>> > > > That works as well.
>>> > > >
>>> > > > Also From a quick google search this is what I found : 
>>> > > > https://superuser.com/questions/617872/cant-locate-autom4te-channeldefs-pm-in-inc-when-it-definitely-is-there
>>> > > >
>>> > > > On Tue, Jun 15, 2021 at 9:12 PM Matthew Joyce  
>>> > > > wrote:
>>> > > >>
>>> > > >> Hello Dr. Joel and Eshan,
>>> > > >>
>>> > > >> I have a patch ready to send to Newlib for the sig function 
>>> > > >> prototypes
>>> > > >> and STR2SIG_MAX.
>>> > > >>
>>> > > >> But to do that, I think I need to have Newlib built, which I must
>>> > > >> still be doing wrong. The error that I am getting is attached below.
>>> > > >>
>>> > > >> I’ve been trying to follow the steps here:
>>> > > >> https://medium.com/my-gsoc-2019-journey/apply-newlib-patch-to-rtems-source-builder-6873b0fb31b8
>>> > > >> and 
>>> > > >> https://medium.com/my-gsoc-2019-journey/build-newlib-for-sparc-and-arm-architecture-6b3287d4c6f2
>>> > > >>
>>> > > >> I even had rebuilt everything from scratch to see if that would help,
>>> > > >> but I still get the same error. Maybe I cloned the newlib source into
>>> > > >> the wrong directory?
>>> > > >>
>>> > > >> I was hoping to get the patch off to Newlib for review as a first 
>>> > > >> step
>>> > > >> while I work on writing the actual methods. When you get a moment,
>>> > > >> could you please advise? Thank you very much!
>>> > > >>
>>> > > >> Sincerely,
>>> > > >>
>>> > > >> Matt
>>> > > ___
>>> > > 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New coding style for new files?

[Vaibhav Gupta]

On Mon, Sep 07, 2020 at 08:06:41AM +0200, Sebastian Huber wrote:
> Hello,
> 
> I think we waste too much time to address coding style issues on newly
> contributed code, for example GSoC. I don't know a source code formatting
> tool which supports the RTEMS coding style and I think it is not worth the
> time to write and maintain such a tool specifically for RTEMS. Why don't we
> simply allow an alternative coding style which has a good code formatter for
> new source files? I don't propose to reformat the existing files.
> 
> I would simply pick up one of the standard styles supported by clang-format
> and declare it as an acceptable coding style for RTEMS. Then students can
> pipe their code through it before they send it for review. This helps to
> concentrate on the important things to review and not the white space.
> 
Hello Sebastian,
I agree with your point. A few months back, I posted an issue regarding
formatting style for nested conditional directives. And I guess the existing
standard solve it too.

Thanks
Vaibhav Gupta
> ___
> 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: Proposal to add rule for nested CPP Directives in RTEMS coding conventions

[Vaibhav Gupta]

On Sat, 4 Apr 2020 at 01:44, Vaibhav Gupta  wrote:
>
>
>
> On Sat, Apr 4, 2020, 1:41 AM Vijay Kumar Banerjee  wrote:
>>
>>
>>
>> On Sat, Apr 4, 2020 at 1:22 AM Vaibhav Gupta  
>> wrote:
>>>
>>> CPP directives like:
>>> 1) #if
>>> 2) #ifdef
>>> 3) #ifndef
>>> 4) #elif
>>> 5) #else
>>> 6) #endif
>>>
>>> do form code blocks. Since, they don't make use of brackets,
>>> as a part of C language rule, their nested and repeated use
>>> can make the code very hard to read. Can even result it
>>> spaghetti code.
>>>
>>> This can be understood by this patch:
>>> https://lists.rtems.org/pipermail/devel/2020-April/058964.html
>>>
>>> The proposed idea is:
>>> 1) Nested CPP directives should follow same indentation rules
>>> as of nested conditional statements like 'if' and loops.
>>>
>>> 2) To mark which closing CPP directive (#endif) pairs with which
>>> opening CPP directive (#if or #ifdef or #ifndef), make use of comments.
>>> ex:
>>> #ifdef  /* To test/verify/enable xyz */
>>>   .
>>>   
>>> #endif /* To test/verify/enable xyz */
>>>
>> There's a rule like this in the FreeBSD
>
> Yes, and when I ported APIs, last year, as a part of my
> Project, the ported headers follow same rule.
>>
>> and we follow it in RTEMS-libbsd.
>> It is nicely explained in the FreeBSD style guide so I'm pasting an excerpt
>> below:
>
> Thanks!
>
> --Vaibhav Gupta
>>
>>
>> "
>> The comment for #endif should match the expression used in the corre-
>>  sponding #if or #ifdef.  The comment for #else and #elif should match 
>> the
>>  inverse of the expression(s) used in the preceding #if and/or #elif
>>  statements.  In the comments, the subexpression "defined(FOO)" is abbre-
>>  viated as "FOO".  For the purposes of comments, "#ifndef FOO" is treated
>>  as "#if !defined(FOO)".
>>
>>  #ifdef KTRACE
>>  #include 
>>  #endif
>>
>>  #ifdef COMPAT_43
>>  /* A large region here, or other conditional code. */
>>  #else /* !COMPAT_43 */
>>  /* Or here. */
>>  #endif /* COMPAT_43 */
>>
>>  #ifndef COMPAT_43
>>  /* Yet another large region here, or other conditional code. */
>>  #else /* COMPAT_43 */
>>  /* Or here. */
>>  #endif /* !COMPAT_43 */
>>
>> "
>>
>> It would be nice to have a rule like this for RTEMS codes as well.
>>
>>
>>> --Vaibhav Gupta

Should it be included then?

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

Re: Proposal to add rule for nested CPP Directives in RTEMS coding conventions

[Vaibhav Gupta]

On Sat, Apr 4, 2020, 1:41 AM Vijay Kumar Banerjee  wrote:

>
>
> On Sat, Apr 4, 2020 at 1:22 AM Vaibhav Gupta 
> wrote:
>
>> CPP directives like:
>> 1) #if
>> 2) #ifdef
>> 3) #ifndef
>> 4) #elif
>> 5) #else
>> 6) #endif
>>
>> do form code blocks. Since, they don't make use of brackets,
>> as a part of C language rule, their nested and repeated use
>> can make the code very hard to read. Can even result it
>> spaghetti code.
>>
>> This can be understood by this patch:
>> https://lists.rtems.org/pipermail/devel/2020-April/058964.html
>>
>> The proposed idea is:
>> 1) Nested CPP directives should follow same indentation rules
>> as of nested conditional statements like 'if' and loops.
>>
>> 2) To mark which closing CPP directive (#endif) pairs with which
>> opening CPP directive (#if or #ifdef or #ifndef), make use of comments.
>> ex:
>> #ifdef  /* To test/verify/enable xyz */
>>   .
>>   
>> #endif /* To test/verify/enable xyz */
>>
>> There's a rule like this in the FreeBSD
>
Yes, and when I ported APIs, last year, as a part of my
Project, the ported headers follow same rule.

> and we follow it in RTEMS-libbsd.
> It is nicely explained in the FreeBSD style guide so I'm pasting an excerpt
> below:
>
Thanks!

--Vaibhav Gupta

>
> "
> The comment for #endif should match the expression used in the corre-
>  sponding #if or #ifdef.  The comment for #else and #elif should match
> the
>  inverse of the expression(s) used in the preceding #if and/or #elif
>  statements.  In the comments, the subexpression "defined(FOO)" is
> abbre-
>  viated as "FOO".  For the purposes of comments, "#ifndef FOO" is
> treated
>  as "#if !defined(FOO)".
>
>  #ifdef KTRACE
>  #include 
>  #endif
>
>  #ifdef COMPAT_43
>  /* A large region here, or other conditional code. */
>  #else /* !COMPAT_43 */
>  /* Or here. */
>  #endif /* COMPAT_43 */
>
>  #ifndef COMPAT_43
>  /* Yet another large region here, or other conditional code. */
>  #else /* COMPAT_43 */
>  /* Or here. */
>  #endif /* !COMPAT_43 */
>
> "
>
> It would be nice to have a rule like this for RTEMS codes as well.
>
>
> --Vaibhav Gupta
>> ___
>> 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

Proposal to add rule for nested CPP Directives in RTEMS coding conventions

[Vaibhav Gupta]

CPP directives like:
1) #if
2) #ifdef
3) #ifndef
4) #elif
5) #else
6) #endif

do form code blocks. Since, they don't make use of brackets,
as a part of C language rule, their nested and repeated use
can make the code very hard to read. Can even result it
spaghetti code.

This can be understood by this patch:
https://lists.rtems.org/pipermail/devel/2020-April/058964.html

The proposed idea is:
1) Nested CPP directives should follow same indentation rules
as of nested conditional statements like 'if' and loops.

2) To mark which closing CPP directive (#endif) pairs with which
opening CPP directive (#if or #ifdef or #ifndef), make use of comments.
ex:
#ifdef  /* To test/verify/enable xyz */
  .
  
#endif /* To test/verify/enable xyz */

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

Re: [PATCH v11] tests for fenv.h functions

[Vaibhav Gupta]

On Sat, Apr 4, 2020, 1:01 AM Gedare Bloom  wrote:

> On Fri, Apr 3, 2020 at 1:11 PM Vaibhav Gupta 
> wrote:
> >
> > IMO we should have a rule for nested CPP directives.
> > And also the commenting. It makes the code more readable
> > as a part of good coding style.
> >
> > Specially if the directives are nested, because they don't
> > use brackets, too many opening-closing pair can make
> > the code hard to read.
> >
>
> We do have some precedent for aligning the #ifdef with the surrounding
> code when it is in a scoped block. I can at least get on board with
> that, and the commenting. The discussion should be had in a separate
> thread though. Would you care to present the proposal?
>
Sure!

--Vaibhav Gupta

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

Re: [PATCH v11] tests for fenv.h functions

[Vaibhav Gupta]

IMO we should have a rule for nested CPP directives.
And also the commenting. It makes the code more readable
as a part of good coding style.

Specially if the directives are nested, because they don't
use brackets, too many opening-closing pair can make
the code hard to read.

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

Re: [PATCH v11] tests for fenv.h functions

[Vaibhav Gupta]

> Good advice,
Thanks!
> although I'm not sure if we have these 2 things in our
> conventions yet: nesting CPP conditional blocks, and comments on CPP
> conditional blocks?
>
Well in that case I guess Eshan should re-work on patch and also
make changes in wiki.

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

Re: [PATCH v11] tests for fenv.h functions

[Vaibhav Gupta]

On Fri, 27 Mar 2020 at 22:35, Eshan dhawan  wrote:
>
> ---
>  testsuites/psxtests/psxfenv01/init.c| 88 -
>  testsuites/psxtests/psxfenv01/psxfenv01.doc |  9 ++-
>  testsuites/psxtests/psxfenv01/psxfenv01.scn |  4 -
>  3 files changed, 76 insertions(+), 25 deletions(-)
>
> diff --git a/testsuites/psxtests/psxfenv01/init.c 
> b/testsuites/psxtests/psxfenv01/init.c
> index cdb0fa596e..cfa31d6a16 100644
> --- a/testsuites/psxtests/psxfenv01/init.c
> +++ b/testsuites/psxtests/psxfenv01/init.c
> @@ -6,6 +6,7 @@
>  /*
>   * SPDX-License-Identifier: BSD-2-Clause
>   *
> + * Copyright (C) 2020 Eshan Dhawan
>   * Copyright (C) 2019 Vaibhav Gupta
>   *
>   * Redistribution and use in source and binary forms, with or without
> @@ -46,11 +47,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  const char rtems_test_name[] = "PSXFENV 01";
>
>  /* forward declarations to avoid warnings */
> -rtems_task Init(rtems_task_argument ignored);
> +rtems_task Init( rtems_task_argument ignored );
>
>  /* Test Function Begins */
>  rtems_task Init(rtems_task_argument ignored)
> @@ -62,40 +64,90 @@ rtems_task Init(rtems_task_argument ignored)
>
>/*
> * 'FE_ALL_EXCEPT' will be defined only when 'feclearexcept()',
> -   * 'fegetexceptflag()', 'feraiseexcept()', 'fesetexceptflag()' and
> -   * 'fetestexcept()' functions are supported by the architecture.
> +   * fegetexceptflag() , feraiseexcept(), fesetexceptflag() and
> +   * fetestexcept() functions are supported by the architecture.
> * Hence their testcases can be wrapped under #ifdef and #endif.
> */
>#ifdef FE_ALL_EXCEPT /* floating-point exceptions */
This line is referred below.
> -puts( "fesetenv(FE_DFL_ENV)." );
> -r = fesetenv(FE_DFL_ENV);
> -if (r)
> -  printf("fesetenv ==> %d\n", r);
> +r = fesetenv( FE_DFL_ENV );
> +if ( r ) {
> +  printf( "fesetenv ==> %d\n", r);
> +}
>  rtems_test_assert( r == 0 );
>
> -/* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
> -puts( "feclearexcept(FE_ALL_EXCEPT)." );
> -r = feclearexcept(FE_ALL_EXCEPT);
> -if (r)
> -  printf("feclearexcept ==> 0x%x\n", r);
> +/* Test feclearexcept() and fetestexcept() in one go. */
> +r = feclearexcept( FE_ALL_EXCEPT );
> +if ( r ) {
> +  printf( "feclearexcept ==> 0x%x\n", r );
> +}
>  rtems_test_assert( r == 0 );
>
>  r = fetestexcept( FE_ALL_EXCEPT );
> -if (r)
> -  printf("fetestexcept ==> 0x%x\n", r);
> +if ( r ) {
> +  printf( "fetestexcept ==> 0x%x\n", r );
> +}
>  rtems_test_assert( r == 0 );
>
> -/* Test 'FE_DIVBYZERO' */
> -puts( "Divide by zero and confirm fetestexcept()" );
> +/* Test 'FE_DIVBYZERO'
> + *Divide by zero and confirm fetestexcept() */
>  a = 0.0;
>  b = 1.0;
>  c = b/a;
>  (void) c;
> +/* Test fegetexceptflag() and fesetexceptflag() */
> +r = fegetexceptflag( &excepts, FE_ALL_EXCEPT );
> +if ( r ) {
> +  printf( "fegetexceptflag ==> 0x%x\n", r );
> +}
> +rtems_test_assert( r == 0 );
>
> -fegetexceptflag(&excepts,FE_ALL_EXCEPT);
> +r = fesetexceptflag( &excepts, FE_ALL_EXCEPT );
> +if ( r ) {
> +  printf( "fesetexceptflag ==> 0x%x\n", r );
> +}
> +rtems_test_assert( r == 0 );
>
> +/* Test for fegetround() and fesetround()
> + * They have four main macros to be tested separated by ifdef
> + * Since not all architectures support them
> + * The test case gets and sets the rounding directions */
> +#ifdef FE_TONEAREST
Correct the Indentation. This and below conditional directives are
contained inside above #ifdef directive.
Also, like above, the best practice is to provide a
comment for the both opening and closing conditional directives.
(#ifdef and #endif).
Ex: When you open-
#ifdef xyz /* 3-5 words description */
..

#endif /* same description */

This helps developers to understand which closing directive
belongs to which opening directive. Easy to understand.
Indentation too for same reason.

--Vaibhav Gupta
> +rtems_test_assert( fegetround() == FE_TONEAREST );
> +#endif
> +#ifdef FE_TOWARDZERO
> +  r = fesetround( FE_TOWARDZERO );
> +  if ( r ) {
> +  printf( "fesetround ==> 0x%x\n", r );
> +}
> +  rtems_test_assert( r == 0 );
> +  rtems_test_assert( fegetround() == FE_TOWARDZERO );
> +#endif
> +#if

[PATCH v1] RTEMS Docs: Add steps for sphinxcontrib-bibtex

[Vaibhav Gupta]

Add step to install sphinxcontrib-bibtex
together with the steps mentioned for ArcLinux,
to install sphinx and dependencies.

Signed-off-by: Vaibhav Gupta 
---
 README.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README.txt b/README.txt
index 9fd2165..ce30505 100644
--- a/README.txt
+++ b/README.txt
@@ -286,6 +286,7 @@ Arch Linux
 Sphinx:
 
   # pacman -S python-sphinx
+  # pacman -S python-sphinxcontrib-bibtex
 
 PDF:
 
-- 
2.26.0

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

Re: applying a patch

[Vaibhav Gupta]

> At #2 I also have the option to download a file. Then you can skip to
> 4 and provide the filename on the git-am command line and be done.

Yeah! Its just that I got used to copying to clipboard
and providing it to git-am via stdin. We can of course
do it both the ways.

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

Re: applying a patch

[Vaibhav Gupta]

On Sun, 22 Mar 2020 at 01:23, Eshan Dhawan  wrote:
>
> Hello everyone
> I tried to apply this patch but it fails.
> Since I have done this before so I might be doing something wrong.
> if you all could guide me
>
> patch : https://lists.rtems.org/pipermail/devel/2020-March/058516.html
>
Its just few simple steps:

1- As you use gmail, just open the patch-mail. Click option
and select 'Show Original'.
2- Copy the content written in monospace/raw-format.
 There is also a button 'Copy to Clipboard'.
3- Get to your terminal, switch to master branch.
You might wanna 'git pull' to load recent
changes (if any).
4- type 'git am' and hit enter key.
5- Since no mailbox given, it will read from stdin, hence
 wait for your input.
6- Paste the content (ctrl+shift+v).
7- Press (ctrl+D)

Patch will be applied

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

Re: Ticket #2974 Enable search.h functionality in newlib

[Vaibhav Gupta]

On Mon, 23 Mar 2020 at 06:47, Gedare Bloom  wrote:

> On Sun, Mar 22, 2020 at 8:46 AM Joel Sherrill  wrote:
> >
> >
> >
> > On Sun, Mar 22, 2020, 1:58 AM Vaibhav Gupta 
> wrote:
> >>>
> >>>
> >>> > My very quick review shows that this may all be present and then it
> is a matter
> >>> > of test cases and the compliance document. And that's a good result.
> Sometimes
> >>> > people do work and don't update tickets.
> >>> >
> >>> My hazy recollection is that someone looked into this. Maybe in prior
> >>> POSIX Compliance projects?
> >>
> >>
> >> Last year when I was porting ndbm.h I made several queries regarding
> this directory.
> >> Even after doing all the changes correctly, the port was not
> successful. Later I found
> >> out that the ndbm was calling a hash function from search.h.
> >>
> >> The headers in this directory need to be updated first. Me and Joel
> even had
> >> discussion about this in newlib mailing list but got no positive
> response from them.
> >>
> >> https://sourceware.org/pipermail/newlib/2019/017046.html
> >>
> >> https://lists.rtems.org/pipermail/devel/2019-June/026205.html
> >
> >
> > The newlib link doesn't work after the sourceware upgrade :(
> >
> > Let's assume this code needs to be updated to the latest freebsd and
> then freebsd ndbm brought over.
>
> Vaibhav, can you help Eshan to understand what you discovered last
> year, and work on a plan for this summer to address this challenge?
>
Sure,

1) Eshan, I would strongly suggest you to go through my threads in rtems
mailing
list as well as newlib mailing list, of last year.

2) Keep the task of updating search.h, secondary because last year newlib
community didn't show much interest in this. Hence while porting ndbm,
I changed the ndbm code from BSD, rather than updating search.

3) I saw you query regarding ftw.h also.

> Go through my logs of weekly meetings:
https://devel.rtems.org/wiki/GSoC/2019#VaibhavGupta .
Last year while porting ftw, I saw it requires fts.h, the functions of
fts.h are defined in fts.c which
requires mount.h, again this header requires multiple other headers, and
dependency chain is formed.
So, in simple words, porting one header was leading to porting of 10-20
other headers.
So when you try to port ftw, first discover all the dependencies and plan
it.

4) Last year Joel mentioned that compliance to FACE GPP is of atmost
priority,
so start working with them you will find the missing functions here:
https://docs.rtems.org/branches/master/posix-compliance/posix-compliance.html#face-3-0-general-purpose

5) fenv.h is also at same priority level. Joel made things very easy.
He made a dummy model of fenv port at newlib-cygwin/newlib/libm/fenv
He defined how fenv should be ported for other architectures.
Just go through those non-functional codes, and you will get idea
how to port fenv for a specific architecture and the location of their port.

6) For writing testsuites, I used to write them for linux first, since both
rtems and linux
follow POSIX. So I could easily run in on my system  like any regular C
program
and debug it for syntactical, semantic and logical error. then port it to
RTEMS and look
for run-time errors.

-- Vaibhav Gupta

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

Re: Sources to port fenv.h to ARM and AARCH64

[Vaibhav Gupta]

>
> >>
>> >> I have cloned this NetBSD Sources. As I can see those
>> >> architecture-specific implemented methods here. Please correct me if I
>> >> am looking into different than what you are looking for.
>> >>
>> >> ./lib/libm/arch/powerpc/fenv.c
>> >> ./lib/libm/arch/sh/fenv.c
>> >> ./lib/libm/arch/mips64/fenv.c
>> >> ./lib/libm/arch/amd64/fenv.c
>> >> ./lib/libm/arch/arm/fenv.c
>> >> ./lib/libm/arch/i387/fenv.c
>> >> ./lib/libm/arch/hppa/fenv.c
>> >> ./lib/libm/arch/m88k/fenv.c
>> >> ./lib/libm/arch/alpha/fenv.c
>> >> ./lib/libm/arch/sparc64/fenv.c
>> >> ./lib/libm/arch/aarch64/fenv.c
>> >> ./regress/lib/libm/fenv/fenv.c
>> >
>> >
>> > That's what I see browsing the repo.
>> >
>> > The single file NetBSD looks easy to integrate. Would be similar to the
>> x86_64 or i386 there now on file layout.
>> >
>> > Does the freebsd support more hardware variants?
>>
>> FreeBSD does not have fenv support for some architecture like RISCV,
>> M88k, alpha architecture, I can see netbsd support more
>> hardware variants. NetBSD includes fenv support for these architecture
>> also.
>>
>
> +1
>
> NetBSD has more architectures and looks easier to integrate. But we need
> to be
> sure the NetBSD implementation for an specific architecture covers all the
> cases
> that FreeBSD does. If equal, pick the more that is easier to integrate.
>
> --joel
>
Last year I found various sources:
https://lists.rtems.org/pipermail/devel/2019-July/026580.html

https://lists.rtems.org/pipermail/devel/2019-July/054391.html

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

Re: Ticket #2974 Enable search.h functionality in newlib

[Vaibhav Gupta]

>
>
> > My very quick review shows that this may all be present and then it is a
> matter
> > of test cases and the compliance document. And that's a good result.
> Sometimes
> > people do work and don't update tickets.
> >
> My hazy recollection is that someone looked into this. Maybe in prior
> POSIX Compliance projects?
>

Last year when I was porting ndbm.h I made several queries regarding this
directory.
Even after doing all the changes correctly, the port was not successful.
Later I found
out that the ndbm was calling a hash function from search.h.

The headers in this directory need to be updated first. Me and Joel even had
discussion about this in newlib mailing list but got no positive response
from them.

https://sourceware.org/pipermail/newlib/2019/017046.html

https://lists.rtems.org/pipermail/devel/2019-June/026205.html

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

Re: ANN: New Maintainer Vijay Kumar Bannerjee

[Vaibhav Gupta]

Congrats Vijay!!

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

Re: Project proposal for GSOC 2020

[Vaibhav Gupta]

On Thu, 12 Mar 2020 at 11:28, Eshan Dhawan  wrote:

> I am sorry for the confusion.
> By mistake, I sent the wrong link.
> Here is the link of the Google Docx format of the proposal.
>
> Link:
> https://drive.google.com/open?id=1lGgcngtHeDadC-_uGojclv7KDSLWnxqCgc9AUV8sxQ4
>
There is no edit access. File should be editable through the link and
should have comment access. Also, update same on
https://devel.rtems.org/wiki/GSoC/2020 .

-- Vaibhav Gupta

>
>
> I have worked on a few suggestions from Dr Gedare.
> I also wanted to know who could be the mentors and co-mentors of the
> project?
>
> thanks
> -Eshan
>
> On Thu, Mar 12, 2020 at 1:36 AM Eshan Dhawan 
> wrote:
>
>>
>>
>>
>> On Thu, Mar 12, 2020 at 12:48 AM Gedare Bloom  wrote:
>>
>>> You should convert this from Word (docx) to a Google Doc
>>>
>>
>> Here is the google docs link
>> link: https://drive.google.com/open?id=1LhbYgsx_1gU3ZWj7nz4FH_nYzlbAS4s2
>>
>>>
>>> On Wed, Mar 11, 2020 at 12:30 PM Eshan Dhawan 
>>> wrote:
>>> >
>>> > Hello everyone,
>>> >
>>> > I have added the first proposal draft at the GSOC tracking page as
>>> well as added the link in this email. It's a little crude currently and
>>> requires a lot of refinement.
>>> > This requires discussion with the mentors and their reviews.
>>> >
>>> > Link to the draft :
>>> https://drive.google.com/file/d/1LhbYgsx_1gU3ZWj7nz4FH_nYzlbAS4s2/view?usp=sharing
>>> >
>>> >
>>> > Thanks
>>> > Eshan
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Review for my GSOC proposal: Static analysis integration

[Vaibhav Gupta]

On Mon, Mar 9, 2020, 10:40 AM suyash singh  wrote:

> Please review my proposal. Thank you
>
> This project is inspired by https://devel.rtems.org/ticket/3710 and from
> the mail thread with subject
> "Improve Coverity Scan Integration: GSOC project details"
>
>
> https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing
>
Please add the link to https://devel.rtems.org/wiki/GSoC/2020.

-- Vaibhav

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

GSoC organizations list announced

[Vaibhav Gupta]

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

Re: Status of implementation of fenv.h test suites

[Vaibhav Gupta]

On Thu, Feb 20, 2020, 12:47 PM Eshan Dhawan  wrote:

> Hello
>  The current fenv.h test suite  supports only basic functions that check
> that fenv.h environment is present or not
> I would like to extend the test suite further
> What more functions can be added to it.
>
Test all the functions of fenv.h:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fenv.h.html

-- Vaibhav Gupta

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

Re: GSOC: Call for Mentors

[Vaibhav Gupta]

Hello Gedare,
I also want to Co-mentor a project.

--Vaibhav Gupta


On Tue, Feb 18, 2020, 11:21 AM Amaan Cheval  wrote:

> Hey! I'd like to co-mentor a project too. Thanks!
>
> On Tue, Feb 18, 2020 at 8:56 AM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Hi Gedare,
>>
>> Please add me to the list of co-mentors.
>> Looking forward to a great experience. :)
>>
>> Best regards,
>> Vijay
>>
>>
>> On Tue, Feb 18, 2020, 1:28 AM Gedare Bloom  wrote:
>>
>>> Assuming we get accepted on 2/20, I will be able to start adding mentors
>>> shortly after. Please let me know if you're interested to mentor this
>>> summer, either in a primary or co-mentor capacity. As usual, I will provide
>>> "backup" mentoring and high-level organization of all projects with weekly
>>> contact to each student. Primary mentors are responsible for multiple
>>> interactions per week (daily is best) with their student and providing
>>> strong technical guidance. Co-mentors should stay in the loop, and possibly
>>> step in if the primary mentor needs a break or other emergency comes up.
>>>
>>> Gedare
>>> ___
>>> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Status of fenv.h header and floating point environment support in newlib

[Vaibhav Gupta]

On Mon, 17 Feb 2020 at 21:06, Joel Sherrill  wrote:

> Ayush please add yourself to  https://devel.rtems.org/wiki/GSoC/2020.
>
> Vaibhav.. we haven't asked others to add themselves to the table.
> Please ping anyone we missed.
>
Sure, I will inform them.

>
> On the fenv.h side, there are some basic guidelines on how to provide
> the fenv functionality and subtleties from the POSIX requirements.
>
And Dr Joel have already re-structured fenv implementation of RISCV
last summer. I would recommend everyone to study that structure for
once, those who are planning to work on fenv.
Porting fenv for other architectures under same structure will make
thing simple.
Also, check the weekly updates of
last year https://devel.rtems.org/wiki/GSoC/2019#VaibhavGupta
and go through the discussions done on mailing list. Check archives.
They will be of lot help to get to know the work done till now.

--Vaibhav Gupta

>
> First, the preferred origin of the implementation is another open source
> project with FreeBSD and NetBSD being at the top of the list. For example,
> here is the NetBSD implementation for the m68k:
>
> https://github.com/NetBSD/src/blob/trunk/sys/arch/m68k/include/fenv.h
>
> But there are differences between vanilla m68k and coldfire so that may
> not support all CPU variations. Would have to be determined.
>
> I have not found a SPARC implementation with an appropriate license.
> Jiri may have a better source.
>
> I would put ARM, PowerPC, and MIPS at the top of the desired list that we
> should be able to find BSD implementations for. We don't have an aarch64
> port yet but I wouldn't stop a GSoC student from adding it to newlib. Just
> can't
> be tested with RTEMS yet. Beyond that, architectures like the m68k where it
> is porting, not writing from scratch are priorities. Covering as many
> architectures
> that are popular with RTEMS is the goal. SPARC64 would be down the list
> based on that.
>
> Next POSIX allows an implementation to not support much if it isn't there
> in hardware.
>
>
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fenv.h.html#tag_13_12
>
>
> The fact that an architecture may not support a feature is challenging to
> testing.
>
> --joel
>
> On Mon, Feb 17, 2020 at 5:54 AM Jiri Gaisler  wrote:
>
>>
>> On 2/17/20 11:16 AM, Vaibhav Gupta wrote:
>>
>>
>>
>> On Mon, Feb 17, 2020, 3:07 PM Ayush Dwivedi <21cencturyay...@gmail.com>
>> wrote:
>>
>>> Hello Joel,
>>> This is regarding the open project #2966 POSIX-Compliance #2971( Add
>>> fenv.h to newlib). The task is about adding the floating point environment
>>> header to the newlib library but the source code of the library already has
>>> the header with the listed function declarations and data struct as needed.
>>> The implementations for the following architectures are available in the
>>> newlib-cygwin repository:
>>> >RISCV
>>> >i386
>>> >x86_64
>>> As pointed out in the POSIX Compliance project sub-task page the
>>> implementations for following architectures are yet to be added:
>>> >ARM(software float implementation for this exists but no fenv
>>> implementation)
>>> >AArch64(software float implementation for this exists but no fenv
>>> implementation)
>>> >SPARC and SPARC64(directories for these architectures are missing from
>>> libm/machine/ so no implementation of any sort)
>>>
>>> I would like to try and implement the functions declared in the header
>>> using BSD libc of FreeBSD as reference for the ARM and SPARC architectures.
>>>
>>> Following is the output after running test for posix fenv
>>> header(psxfenv01.exe) for SPARC using sparc-rtems5-sis and
>>> sparc-rtems5-gdb.(The Test failed)
>>>
>> Yes because testsuite needs modifications and moreover fenv on SPARC is
>> not yet supported. Since the support for RISCV and x86_64 is present, you
>> can make a testsuite for them. You can use qemu for running riscv files.
>>
>> Note that sis (riscv-rtems5-sis) also supports RISCV32 using the griscv
>> BSP in RTEMS.
>>
>> Jiri.
>>
>> ___
>> 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: Status of fenv.h header and floating point environment support in newlib

[Vaibhav Gupta]

On Mon, Feb 17, 2020, 3:07 PM Ayush Dwivedi <21cencturyay...@gmail.com>
wrote:

> Hello Joel,
> This is regarding the open project #2966 POSIX-Compliance #2971( Add
> fenv.h to newlib). The task is about adding the floating point environment
> header to the newlib library but the source code of the library already has
> the header with the listed function declarations and data struct as needed.
> The implementations for the following architectures are available in the
> newlib-cygwin repository:
> >RISCV
> >i386
> >x86_64
> As pointed out in the POSIX Compliance project sub-task page the
> implementations for following architectures are yet to be added:
> >ARM(software float implementation for this exists but no fenv
> implementation)
> >AArch64(software float implementation for this exists but no fenv
> implementation)
> >SPARC and SPARC64(directories for these architectures are missing from
> libm/machine/ so no implementation of any sort)
>
> I would like to try and implement the functions declared in the header
> using BSD libc of FreeBSD as reference for the ARM and SPARC architectures.
>
> Following is the output after running test for posix fenv
> header(psxfenv01.exe) for SPARC using sparc-rtems5-sis and
> sparc-rtems5-gdb.(The Test failed)
>
Yes because testsuite needs modifications and moreover fenv on SPARC is not
yet supported. Since the support for RISCV and x86_64 is present, you can
make a testsuite for them. You can use qemu for running riscv files.

--Vaibhav

>
> Regards,
> Ayush Dwivedi
> ___
> 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: Watch Solar Orbiter Launch

[Vaibhav Gupta]

This is very exciting!

--Vaibhav

On Mon, Feb 10, 2020, 8:32 AM Joel Sherrill  wrote:

> Hi
>
> If all goes well, the Solar Orbiter will launch late tonight New York time
> or early Monday Europe time.
>
>
> https://www.space.com/solar-orbiter-cygnus-ng-13-rocket-launch-double-header-webcasts.html
>
>
> This has RTEMS based software onboard and I am hoping that someone from
> one of those projects can share some details.
>
> Congratulations!
>
> --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: Need help with proof submission for Contribution Eligibilty

[Vaibhav Gupta]

On Thu, Feb 6, 2020, 4:15 PM Ayush Dwivedi <21cencturyay...@gmail.com>
wrote:

> Hello everyone,
>
> I am new to RTEMS community. I wish to contribute to the RTEMS project. I
> read on the RTEMS gsoc getting started page that I am required to submit a
> proof that I can contribute. Modifying the sample executable hello.exe
> source code along with the screenshot of it being tested on gdb is needed
> so I changed the print statement of the sample and ran it on gdb. I have
> took the screenshot as asked and made a patch file as required. I need to
> know where and how to send it.
>
Use 'git send-email' to send patches. You will need to set up smtp for this
in gitconfig file.

--Vaibhav

>
> Regards,
> Ayush Dwivedi
>
>
> ___
> 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: sparc-erc32 testsuites failures

[Vaibhav Gupta]

On Mon, Nov 18, 2019, 12:52 PM Niteesh  wrote:

> I have updated the doc to use erc32-sis, and attached the patch file in
> this mail. Can someone review it.
>
Use "git send-email" for sending patches.

>
> On Mon, Nov 18, 2019 at 12:07 PM Niteesh  wrote:
>
>> I know this, but the docs are not updated so should I send a pull request?
>>
>>
>> On Mon, Nov 18, 2019 at 12:06 PM Vaibhav Gupta 
>> wrote:
>>
>>>
>>>
>>> On Mon, Nov 18, 2019, 11:12 AM Niteesh  wrote:
>>>
>>>> On Mon, Nov 18, 2019 at 3:17 AM Joel Sherrill  wrote:
>>>>
>>>>> The instructions are out of date by a couple of months. The SPARC
>>>>> Instruction Simulator (sis) has seen significant enhancements and it's now
>>>>> a standalone program. It is not enabled as a built-in with gdb because
>>>>> that's some very old version of sis. The new version has symmetric
>>>>> multiprocessing and support for the RISC-V.
>>>>>
>>>>> Those instructions worked for a LONG time but need to be updated to
>>>>> reflect the recent changes with SIS.
>>>>>
>>>>> If you used rtems-tester, it should work. And looking at the .ini file
>>>>> for this bsp will sure you have to just run programs with the simulator. 
>>>>> My
>>>>> recollection is that by adding -gdb argument, you can attached to it as a
>>>>> remote debugger.
>>>>>
>>>> Yes. And I also faced this problem (in my case it was riscv)and i guess
>>> this question was asked by others also on devel.
>>> I simply used these steps:
>>>
>>> Open Terminal 1:
>>>
>>> $ sparc-rtems5-sis -gdb
>>>
>>> # It will print 'gdb: listening on port 1234'.
>>>
>>> # Note you can define port number with '-port' option.
>>>
>>> Open Terminal 2:
>>>
>>> $ sparc-rtems5-gdb hello.exe
>>>
>>> # gdb asks for several inputs
>>>
>>> $ target extended-remote localhost:1234
>>>
>>> $ load
>>>
>>> $ r
>>>
>>> You will see output in Terminal 1.
>>>
>>>> I would like to update the docs for this, Can I proceed? I am planning
>>>> to change the cmd to use erc-sis instead of erc. And also the build your
>>>> application section is incomplete, can I add the instruction to modify a
>>>> test program and build it in this section?
>>>>
>>>>> BTW I know it's a way too early for GSOC but I have anyway attached
>>>>>> the patch for hello world.
>>>>>>
>>>>>
>>>>> What type projects are you interested in?
>>>>>
>>>> I am interested in driver development and BSP support.
>>>>
>>>>> ___
>>>>>> 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: sparc-erc32 testsuites failures

[Vaibhav Gupta]

On Mon, Nov 18, 2019, 11:12 AM Niteesh  wrote:

> On Mon, Nov 18, 2019 at 3:17 AM Joel Sherrill  wrote:
>
>> The instructions are out of date by a couple of months. The SPARC
>> Instruction Simulator (sis) has seen significant enhancements and it's now
>> a standalone program. It is not enabled as a built-in with gdb because
>> that's some very old version of sis. The new version has symmetric
>> multiprocessing and support for the RISC-V.
>>
>> Those instructions worked for a LONG time but need to be updated to
>> reflect the recent changes with SIS.
>>
>> If you used rtems-tester, it should work. And looking at the .ini file
>> for this bsp will sure you have to just run programs with the simulator. My
>> recollection is that by adding -gdb argument, you can attached to it as a
>> remote debugger.
>>
> Yes. And I also faced this problem (in my case it was riscv)and i guess
this question was asked by others also on devel.
I simply used these steps:

Open Terminal 1:

$ sparc-rtems5-sis -gdb

# It will print 'gdb: listening on port 1234'.

# Note you can define port number with '-port' option.

Open Terminal 2:

$ sparc-rtems5-gdb hello.exe

# gdb asks for several inputs

$ target extended-remote localhost:1234

$ load

$ r

You will see output in Terminal 1.

> I would like to update the docs for this, Can I proceed? I am planning to
> change the cmd to use erc-sis instead of erc. And also the build your
> application section is incomplete, can I add the instruction to modify a
> test program and build it in this section?
>
>> BTW I know it's a way too early for GSOC but I have anyway attached the
>>> patch for hello world.
>>>
>>
>> What type projects are you interested in?
>>
> I am interested in driver development and BSP support.
>
>> ___
>>> 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: sparc-rtems-gdb doesn't recognize target "sim"

[Vaibhav Gupta]

You can also use "sis"

1- Open Terminal 1 and write:

$ sparc-rtems5-sis -gdb
# It will print 'gdb: listening on port 1234'.
# Note you can define port number with '-port' option.

2-Open Terminal 2 and write:

$ sparc-rtems5-gdb hello.exe
# gdb asks for several inputs
$ target extended-remote localhost:1234
$ load
$ r

Use the notes here:
https://github.com/VARoDeK/MyNotes/blob/master/RTEMS/run_a_testsuite.md

On Wed, Nov 13, 2019, 1:06 PM Vijay Kumar Banerjee 
wrote:

>
>
> On Wed, Nov 13, 2019 at 12:39 AM Shubham Bhagat <
> shubhambhagat...@yahoo.com> wrote:
>
>> Hello everyone,
>> I've been trying to run the hello world example in source tree
>>  to get
>> started with sparc/erc32 but after building all that is required ( followed 
>> POSIX
>> Compliance (Getting started challenge for RTEMS beginners)
>> ). I
>> followed all the commands. But, when gdb starts and I set "tar sim" it
>> says:
>>
>> Undefined target command: "sim".  Try "help target".
>>
>> I also tried running hello.exe from the testsuites sample using
>> sparc-rtems5-run but it doesn't recognize the command.
>> NOTE: The make and make install steps didn't finish with a "SUCCESS" or
>> anything. They exited without showing any error.
>>
>> Am I missing out anything here?
>>
>> I guess this thread will be helpful for you:
> https://lists.rtems.org/pipermail/devel/2019-September/055671.html
>
>> POSIX Compliance (Getting started challenge for RTEMS beginners)
>>
>> Ravindra Kumar Meena
>>
>> POSIX stands for Portable Operating System Interface for uni-X. POSIX
>> Compliance allows us to port the source co...
>> 
>>
>>
>> ___
>> 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: Add chapter for newib build in RTEMS Docs

[Vaibhav Gupta]

On Fri, Nov 1, 2019 at 11:14 PM Gedare Bloom  wrote:

> On Thu, Oct 31, 2019 at 5:14 AM Joel Sherrill  wrote:
> >
> >
> >
> > On Thu, Oct 31, 2019, 1:30 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >>
> >> On 30/10/2019 10:35, Vaibhav Gupta wrote:
> >> > So what's the final stand on this?
> >> >
> >> > Should be working on standalone guide or add the contents to RTEMS
> >> > Software Engineering guide as suggested by Sebastian?
> >>
> >> I think nobody was in favour of adding a new document. I would place it
> >> in the RTEMS Software Engineering guide. I think we need a chapter for
> >> tool and 3rd party software maintenance topics.
> >
> >
> > Yes.
> >
> > And another section on tool selection requirements. But this is beyond
> this patch.
> +1
>
> Mainly, the content just needs to be written, then we can integrate it.
>
Sure then, I will proceed with it.

>
> >>
> >>
> >> --
> >> Sebastian Huber, embedded brains GmbH
> >>
> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> >> Phone   : +49 89 189 47 41-16
> >> Fax : +49 89 189 47 41-09
> >> E-Mail  : sebastian.hu...@embedded-brains.de
> >> PGP : Public key available on request.
> >>
> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Add chapter for newib build in RTEMS Docs

[Vaibhav Gupta]

So what's the final stand on this?

Should be working on standalone guide or add the contents to RTEMS Software
Engineering guide as suggested by Sebastian?

--Vaibhav


On Fri, Sep 13, 2019, 5:40 PM Vaibhav Gupta 
wrote:

> Well I have no problem in working on standalone guide or adding it to
> Software Engineering Manual. I saw that most of the development related
> work,
> even about patches, were in User Manual, so I proposed it at first place.
>
> - Vaibhav
>
> On Fri, Sep 13, 2019 at 10:40 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 13/09/2019 03:34, Chris Johns wrote:
>> > On 13/9/19 8:42 am, Joel Sherrill wrote:
>> >> On Thu, Sep 12, 2019 at 2:09 PM Gedare Bloom  wrote:
>> >>> Hello Vaibhav,
>> >>>
>> >>> It would be nice to provide such documentation, but I don't know that
>> >>> we have an existing location that would be an ideal fit. I think the
>> >>> topic is out of scope for User Manual. If you are motivated to write
>> >>> something though, you could prepare it first as a standalone guide.
>> >> If we have a name for the document like "Maintainers Guide" or
>> something,
>> >> it could have a focus on procedures that only core developers would
>> need.
>> >>
>> >> + bootstrapping newlib and building it independently
>> >> + modifying gcc, running tests,
>> >> + submitting Coverity runs
>> >> + running Doxygen
>> >> + ...
>> > These are all valid and important however can these reside in the
>> Software
>> > Engineering manual?
>> >
>> > We current have ...
>> >
>> >   1. RTEMS Software Engineering
>> >   2. RTEMS Filesystem Design Guide
>> >   3. RTEMS Development Environment Guide
>> >   4. RTEMS BSP and Driver Guide
>> >
>> > plus 'RTEMS BSP and Driver Guide' which I am not sure about. All these
>> cover
>> > some aspect of maintaining and developing RTEMS. Should we be
>> considering
>> > consolidation rather than expansion?
>>
>> Yes, we should definitely aim to consolidate the documentation set and
>> not add new documents. I would put this topic into the RTEMS Software
>> Engineering.
>>
>> --
>> 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: RTEMS Google Code-In 2019

[Vaibhav Gupta]

Hello everyone!

I am interested in mentoring for Google Code-In 2019.

-- Vaibhav Gupta

On Fri, Oct 25, 2019, 1:28 AM Vijay Kumar Banerjee 
wrote:

>
>
>
> On Fri, Oct 25, 2019 at 12:58 AM Himanshu Sekhar Nayak <
> himanshuwindows...@gmail.com> wrote:
>
>> Hi guys,
>>
>> So the Org. application submission is still going on and the last date is
>> 28th Oct. As far as I know, we have collected 3 mentors and we gonna need
>> more for mentoring students. Also mentoring and organizing the tasks for
>> young generations is amazing and it will benefit the Org. too. So if anyone
>> interested then let we know us so that we can participate in this
>> competition.
>>
>> Hi Himanshu,
>
> It's really nice that you're so enthusiastic about GCI. This year, not
> many people
> showed interest in mentoring for GCI and the deadline to collect them is
> very close.
> We have only two days.
>
> Himanshu contacted me privately and I can try to devote some time to GCI
> even if
> I will be having exams at that time. But only a few of us can't handle all
> the
> students. We need more mentors!
>
> If anyone is interested in mentoring High School students during GCI,
> please
> let us know here. The deadline is 28th Oct.
>
> Best regards,
> Vijay
>
>> Thanks
>> Himanshu
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Add chapter for newib build in RTEMS Docs

[Vaibhav Gupta]

Well I have no problem in working on standalone guide or adding it to
Software Engineering Manual. I saw that most of the development related
work,
even about patches, were in User Manual, so I proposed it at first place.

- Vaibhav

On Fri, Sep 13, 2019 at 10:40 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 13/09/2019 03:34, Chris Johns wrote:
> > On 13/9/19 8:42 am, Joel Sherrill wrote:
> >> On Thu, Sep 12, 2019 at 2:09 PM Gedare Bloom  wrote:
> >>> Hello Vaibhav,
> >>>
> >>> It would be nice to provide such documentation, but I don't know that
> >>> we have an existing location that would be an ideal fit. I think the
> >>> topic is out of scope for User Manual. If you are motivated to write
> >>> something though, you could prepare it first as a standalone guide.
> >> If we have a name for the document like "Maintainers Guide" or
> something,
> >> it could have a focus on procedures that only core developers would
> need.
> >>
> >> + bootstrapping newlib and building it independently
> >> + modifying gcc, running tests,
> >> + submitting Coverity runs
> >> + running Doxygen
> >> + ...
> > These are all valid and important however can these reside in the
> Software
> > Engineering manual?
> >
> > We current have ...
> >
> >   1. RTEMS Software Engineering
> >   2. RTEMS Filesystem Design Guide
> >   3. RTEMS Development Environment Guide
> >   4. RTEMS BSP and Driver Guide
> >
> > plus 'RTEMS BSP and Driver Guide' which I am not sure about. All these
> cover
> > some aspect of maintaining and developing RTEMS. Should we be considering
> > consolidation rather than expansion?
>
> Yes, we should definitely aim to consolidate the documentation set and
> not add new documents. I would put this topic into the RTEMS Software
> Engineering.
>
> --
> 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: Add chapter for newib build in RTEMS Docs

[Vaibhav Gupta]

On Fri, Sep 13, 2019 at 4:12 AM Joel Sherrill  wrote:

> On Thu, Sep 12, 2019 at 2:09 PM Gedare Bloom  wrote:
> >
> > Hello Vaibhav,
> >
> > It would be nice to provide such documentation, but I don't know that
> > we have an existing location that would be an ideal fit. I think the
> > topic is out of scope for User Manual. If you are motivated to write
> > something though, you could prepare it first as a standalone guide.
>
Standalone guide sounds good because I am also confused which manual will
be the ideal fit.

>
> If we have a name for the document like "Maintainers Guide" or something,
> it could have a focus on procedures that only core developers would need.
>
> + bootstrapping newlib and building it independently
> + modifying gcc, running tests,
> + submitting Coverity runs
> + running Doxygen
> + ...
>
> Yes, for now I have not much content as other docs are having. But the
content
I proposed are important ones.
It will save enough time of future developers.
And I am sure that content will be generated with development of newlib,
other third party libraries, and RTEMS.

- Vaibhav

> --joel
>
> >
> > On Tue, Aug 27, 2019 at 9:48 AM Vaibhav Gupta 
> wrote:
> > >
> > > Hello,
> > > As RTEMS is using "Newlib" as its C library, sometimes RTEMS
> > > developers need to contribute codes directly to it. For example in
> > > my GSoC Project, I have to port various headers to Newlib.
> > >
> > > This requires building Newlib on local system, making changes,
> > > using right autoconf-tools version, creating patches, etc.
> > >
> > > In my case I referred to the blogs of Aditya. Hesham gave me few advice
> > > during weekly meeting.
> > >
> > > I was hoping if we can provide a separate chapter for this in RTEMS
> Docs User Manual.
> > > It will be helpful for new developers and also new GSoC and GCI
> students.
> > >
> > > Is it okay to proceed with ?
> > >
> > > Vaibhav Gupta
> > > ___
> > > 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

Add chapter for newib build in RTEMS Docs

[Vaibhav Gupta]

Hello,
As RTEMS is using "Newlib" as its C library, sometimes RTEMS
developers need to contribute codes directly to it. For example in
my GSoC Project, I have to port various headers to Newlib.

This requires building Newlib on local system, making changes,
using right autoconf-tools version, creating patches, etc.

In my case I referred to the blogs of Aditya. Hesham gave me few advice
during weekly meeting.

I was hoping if we can provide a separate chapter for this in RTEMS Docs
User Manual.
It will be helpful for new developers and also new GSoC and GCI students.

Is it okay to proceed with ?

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

Re: GSoC 2019 : POSIX Complaince - Fenv methods not returning expected outputs.

[Vaibhav Gupta]

Hello,
Since this fenv environment is not working as expected,
The testsuite I made in Linux environment is yet to be ported to RTEMS.

Vaibhav Gupta

On Thu, Aug 15, 2019 at 3:26 PM Vaibhav Gupta 
wrote:

> Hello,
> In yesterday's weekly meeting I mentioned about fenv problems I faced while
> developing testsuite.
> .
> Here is a very raw patch of my code as testsuite is still in development.
> .
> ==
> Error 1
> ==
> I took three float values:
> a = 0.0
> b = 1.0
> c = b/a
> This should have automatically raised FE_DIVBYZERO exception, which does
> not happens.
> No exception flag is set.
> .
> .
> ==
> Error 2
> ==
> Then I tried to raise an exception manually using feraiseexcept(), but this
> operation was also unsuccessful .
> The method returned 1 on execution, but it should return 0 on successful
> operation.
> .
> .
> ==
> Warning
> ==
> As mentioned in opengroup I tried to define a pragma
> https://pubs.opengroup.org/onlinepubs/009696799/basedefs/fenv.h.html
> .
> #pragma STDC FENV_ACCESS ON
> .
> But this pragma is ignored while 'make -j 2'
> /home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:50:
> warning: ignoring #pragma STDC FENV_ACCESS [-Wunknown-pragmas]
>
> .
> .
>
> --Vaibhav Gupta
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2019 : POSIX Compliance - Final Report

[Vaibhav Gupta]

Here is the final report, published in my Blog. Please review it.

https://medium.com/my-gsoc-2019-journey/gsoc-2019-posix-compliance-74571990c32a

Vaibhav Gupta

On Wed, Aug 21, 2019 at 12:21 AM Vaibhav Gupta 
wrote:

>
>
> On Wed, Aug 21, 2019 at 12:15 AM Vaibhav Gupta 
> wrote:
>
>>
>>
>> On Tue, Aug 20, 2019 at 9:31 PM Joel Sherrill  wrote:
>>
>>> I am late to the party.
>>
>> The party is still on :D
>>
>>> I made a couple of small changes directly to
>>> the document.
>>>
>> Thanks.
>>
>>>
>>> I encourage you continue to pick at getting the other fenv ports into
>>> newlib.
>>
>> This is on top of my priority list.
>>
>>> As you
>>> hopefully saw from me adding the stubs for fenv methods and
>>> documentation,
>>> things moving slowly were not a reflection on you personally. I
>>> certainly went through
>>> a number of rounds. :)
>>>
>> Yes, I am on it. It would be more easy if RISCV fenv works well. I can
>> get a testsuite
>> which will be of lot help.
>>
>>>
>>> Could you add a complete list of POSIX methods that you added? I need to
>>> update
>>> the spreadsheet and .csv file in the POSIX Compliance document.
>>>
>> Sure. I added two testsuites, ndbm and inttypes.
>> Only one header - "ndbm.h".
>>
>
>-
>
>int dbm_clearerr(DBM *);
>-
>
>voiddbm_close(DBM *);
>-
>
>int dbm_delete(DBM *, datum);
>-
>
>int dbm_error(DBM *);
>-
>
>datum   dbm_fetch(DBM *, datum);
>-
>
>datum   dbm_firstkey(DBM *);
>-
>
>datum   dbm_nextkey(DBM *);
>-
>
>DBM*dbm_open(const char *, int, mode_t);
>-
>
>int dbm_store(DBM *, datum, datum, int);
>-
>
>int dbm_dirfno(DBM *);
>
> Updated in report too.
>
>
>> I will update this in my report.
>>
>> --Vaibhav Gupta
>>
>>>
>>> --joel
>>>
>>> On Fri, Aug 16, 2019 at 10:48 PM Vaibhav Gupta 
>>> wrote:
>>> >
>>> > Made the changes as suggested :)
>>> > Please have a look at this now. If every thing is fine.
>>> > I will publish it in my blog.
>>> >
>>> > -Vaibhav Gupta
>>> >
>>> > On Fri, Aug 16, 2019 at 7:57 PM Gedare Bloom  wrote:
>>> >>
>>> >> Vaibhav,
>>> >>
>>> >> Please add a subsection near the top that consolidates links to all
>>> >> the code you wrote during the summer. It is great to have them in
>>> >> context, but it should also be easy (~10 seconds) to find what code
>>> >> you wrote.
>>> >>
>>> >> On Thu, Aug 15, 2019 at 1:27 PM Vaibhav Gupta <
>>> vaibhavgupt...@gmail.com> wrote:
>>> >> >
>>> >> > Hello,
>>> >> > I have made the draft of my project report on google docs.
>>> >> > I have mentioned about each and every task completed
>>> >> > and which are in progress.
>>> >> > .
>>> >> > It would be very helpful for me If I can get reviews on this,
>>> >> > will also make required changes.
>>> >> > .
>>> >> >
>>> https://docs.google.com/document/d/1I3FsA0whd2AcLKdagUzins-JmWv1QTC6-0v0uvS1_7k/edit?usp=sharing
>>> >> > .
>>> >> > .
>>> >> > Thank You
>>> >> > Vaibhav Gupta
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Project Wrap Up Activities

[Vaibhav Gupta]

On Tue, Aug 20, 2019, 7:45 PM Joel Sherrill  wrote:

> Hi
>
> This has been a fantastic and productive GSoC. As part of wrapping
> things up, we would like to make sure the following get taken care of:
>
> + Make sure all code and documentation is submitted, cleaned up and merged.
>Ping mentors if needed. Focus on reproducibility. Is your work
> documented and
>easily publicly accessible? Can it be rebuilt and tests run without
> issues?
>
> + GSoC Lightning Slides: I have shared a Google presentation with as some
> of the
>students and mentors. Please add 1-2 slides on your project. The
> presentation
>we are starting from is last year's. The slide deck will be used
> for two purposes:
>  - 3 minute presentation at GSoC Mentor Summit
>  - part of RTEMS State of the World at Flight Software Workshop
> (http://flightsoftware.jhuapl.edu/)
>
Hello,
I need the edit access and link to the slides. Thank you

--Vaibhav Gupta

>
> + GSoC Project Summary: We usually do a blog/report/news item about GSoC.
>1-3 paragraphs on your project is appreciated for this. I created a
> Google doc
>for this.
>
> I know I missed some mentors and students having permission to the
> files. If you
> don't have access, ping me.
>
> We do really appreciate the work you all did and the wrap up is to
> ensure the work
> is (1) available and usable and (2) know to the community.
>
> Thanks.
>
> --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: [PATCH v2] Add steps to test Newlib patch.

[Vaibhav Gupta]

Thanks for considering it!!

On Wed, Aug 21, 2019, 12:29 AM Joel Sherrill 
wrote:

> Finally pushed.
>
> Thanks
>
> On Tue, Aug 20, 2019 at 8:37 AM Joel Sherrill 
> wrote:
>
>> Can you compress it and send it to me privately as an attachment?
>> Something along the email chain is messing it up.
>>
>> Thanks.
>>
>> --joel
>>
>> On Mon, Aug 19, 2019 at 8:57 AM Vaibhav Gupta 
>> wrote:
>>
>>> Is it okay to push it??
>>>
>>> --Vaibhav Gupta
>>>
>>> On Fri, Aug 16, 2019 at 8:14 PM Vaibhav Gupta 
>>> wrote:
>>>
>>>> Update the checksum to be used for the Newlib patches.
>>>> Earlier it was msd5, but it is depreciated for security
>>>> reasons. Now RSB accepts sha512.
>>>> ---
>>>>  user/rsb/project-sets.rst | 41 +--
>>>>  1 file changed, 35 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/user/rsb/project-sets.rst b/user/rsb/project-sets.rst
>>>> index 5ffce26..b01857e 100644
>>>> --- a/user/rsb/project-sets.rst
>>>> +++ b/user/rsb/project-sets.rst
>>>> @@ -261,17 +261,46 @@ in the ``source-builder/config`` template
>>>> configuration files.
>>>>  To test a patch simply copy it to your local ``patches`` directory.
>>>> The RSB
>>>>  will see the patch is present and will not attempt to download it.
>>>> Once you are
>>>>  happy with the patch submit it to the project and a core developer
>>>> will review
>>>> -it and add it to the RTEMS Tools git repository.  For example, to test
>>>> a local
>>>> -patch for newlib, add the following two lines to the .cfg file in
>>>> -``rtems/config/tools/`` that is included by the bset you use:
>>>> +it and add it to the RTEMS Tools git repository.
>>>> +
>>>> +Testing a Newlib Patch
>>>> +~~
>>>> +
>>>> +To test a local patch for newlib, you need to add the following
>>>> +two lines to the ``.cfg`` file in ``rsb/rtems/config/tools/`` that is
>>>> included
>>>> +by the bset you use:
>>>> +
>>>> +.. topic:: Steps:
>>>> +
>>>> +  1. Create patches for the changes you want to test. (Note: For RSB,
>>>> before
>>>> + creating Newlib patch, you must run ``autoreconf -fvi`` in the
>>>> required
>>>> + directory after you make changes to the code. This is not
>>>> required when
>>>> + you create patch to send to ``newlib-devel``. But if you want RSB
>>>> to
>>>> + address your changes, your patch should also include regenerated
>>>> files.)
>>>> +
>>>> +  2. Calculate ``sha512`` of your patch.
>>>> +
>>>> +  3. Place the patches in ``rsb/rtems/patches`` directory.
>>>> +
>>>> +  4. Open the ``.bset`` file used by your BSP in ``rsb/rtems/config``.
>>>> + For example, for ``rtems5``, ``SPARC``, the file will be
>>>> + ``rsb/rtems/config/5/rtems-sparc.bset``.
>>>> +
>>>> +  5. Inside it you will find the name of ``.cfg`` file for Newlib,
>>>> used by
>>>> + your BSP.
>>>> + For example, I found ``tools/rtems-gcc-7.4.0-newlib-1d35a003f``.
>>>> +
>>>> +  6. Edit your ``.cfg`` file. In my case it will be,
>>>> + ``rsb/rtems/config/tools/rtems-gcc-7.4.0-newlib-1d35a003f.cfg``.
>>>> And
>>>> + add the information about your patch as mentioned below.
>>>>
>>>>  .. code-block:: spec
>>>>
>>>> -%patch add newlib file://0001-this-is-a-newlib-patch.patch   <1>
>>>> -%hash md5 0001-this-is-a-newlib-patch.diff
>>>> 77d070878112783292461bd6e7db17fb <2>
>>>> +%patch add newlib -p1 file://0001-Port-ndbm.patch <1>
>>>> +%hash sha512 0001-Port-ndbm.patch
>>>> 7d999ceeea4f3dc82e8e0aadc09d983a7a68b44470da8a3d61ab6fc558fdba6f2c2de3acc2f32c0b0b97fcc9ab799c27e87afe046544a69519881f947e7881d1
>>>> <2>
>>>>
>>>>  .. topic:: Items:
>>>>
>>>>1. The diff file prepended with ``file://`` to tell RSB this is a
>>>> local file.
>>>>
>>>> -  2. The output from md5sum on the diff file.
>>>> +  2. The output from sha512sum on the patch file.
>>>>
>>>> --
>>>> 2.21.0
>>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2019 : POSIX Compliance - Final Report

[Vaibhav Gupta]

On Wed, Aug 21, 2019 at 12:15 AM Vaibhav Gupta 
wrote:

>
>
> On Tue, Aug 20, 2019 at 9:31 PM Joel Sherrill  wrote:
>
>> I am late to the party.
>
> The party is still on :D
>
>> I made a couple of small changes directly to
>> the document.
>>
> Thanks.
>
>>
>> I encourage you continue to pick at getting the other fenv ports into
>> newlib.
>
> This is on top of my priority list.
>
>> As you
>> hopefully saw from me adding the stubs for fenv methods and documentation,
>> things moving slowly were not a reflection on you personally. I
>> certainly went through
>> a number of rounds. :)
>>
> Yes, I am on it. It would be more easy if RISCV fenv works well. I can get
> a testsuite
> which will be of lot help.
>
>>
>> Could you add a complete list of POSIX methods that you added? I need to
>> update
>> the spreadsheet and .csv file in the POSIX Compliance document.
>>
> Sure. I added two testsuites, ndbm and inttypes.
> Only one header - "ndbm.h".
>

   -

   int dbm_clearerr(DBM *);
   -

   voiddbm_close(DBM *);
   -

   int dbm_delete(DBM *, datum);
   -

   int dbm_error(DBM *);
   -

   datum   dbm_fetch(DBM *, datum);
   -

   datum   dbm_firstkey(DBM *);
   -

   datum   dbm_nextkey(DBM *);
   -

   DBM*dbm_open(const char *, int, mode_t);
   -

   int dbm_store(DBM *, datum, datum, int);
   -

   int dbm_dirfno(DBM *);

Updated in report too.


> I will update this in my report.
>
> --Vaibhav Gupta
>
>>
>> --joel
>>
>> On Fri, Aug 16, 2019 at 10:48 PM Vaibhav Gupta 
>> wrote:
>> >
>> > Made the changes as suggested :)
>> > Please have a look at this now. If every thing is fine.
>> > I will publish it in my blog.
>> >
>> > -Vaibhav Gupta
>> >
>> > On Fri, Aug 16, 2019 at 7:57 PM Gedare Bloom  wrote:
>> >>
>> >> Vaibhav,
>> >>
>> >> Please add a subsection near the top that consolidates links to all
>> >> the code you wrote during the summer. It is great to have them in
>> >> context, but it should also be easy (~10 seconds) to find what code
>> >> you wrote.
>> >>
>> >> On Thu, Aug 15, 2019 at 1:27 PM Vaibhav Gupta <
>> vaibhavgupt...@gmail.com> wrote:
>> >> >
>> >> > Hello,
>> >> > I have made the draft of my project report on google docs.
>> >> > I have mentioned about each and every task completed
>> >> > and which are in progress.
>> >> > .
>> >> > It would be very helpful for me If I can get reviews on this,
>> >> > will also make required changes.
>> >> > .
>> >> >
>> https://docs.google.com/document/d/1I3FsA0whd2AcLKdagUzins-JmWv1QTC6-0v0uvS1_7k/edit?usp=sharing
>> >> > .
>> >> > .
>> >> > Thank You
>> >> > Vaibhav Gupta
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2019 : POSIX Compliance - Final Report

[Vaibhav Gupta]

On Tue, Aug 20, 2019 at 9:31 PM Joel Sherrill  wrote:

> I am late to the party.

The party is still on :D

> I made a couple of small changes directly to
> the document.
>
Thanks.

>
> I encourage you continue to pick at getting the other fenv ports into
> newlib.

This is on top of my priority list.

> As you
> hopefully saw from me adding the stubs for fenv methods and documentation,
> things moving slowly were not a reflection on you personally. I
> certainly went through
> a number of rounds. :)
>
Yes, I am on it. It would be more easy if RISCV fenv works well. I can get
a testsuite
which will be of lot help.

>
> Could you add a complete list of POSIX methods that you added? I need to
> update
> the spreadsheet and .csv file in the POSIX Compliance document.
>
Sure. I added two testsuites, ndbm and inttypes.
Only one header - "ndbm.h".
I will update this in my report.

--Vaibhav Gupta

>
> --joel
>
> On Fri, Aug 16, 2019 at 10:48 PM Vaibhav Gupta 
> wrote:
> >
> > Made the changes as suggested :)
> > Please have a look at this now. If every thing is fine.
> > I will publish it in my blog.
> >
> > -Vaibhav Gupta
> >
> > On Fri, Aug 16, 2019 at 7:57 PM Gedare Bloom  wrote:
> >>
> >> Vaibhav,
> >>
> >> Please add a subsection near the top that consolidates links to all
> >> the code you wrote during the summer. It is great to have them in
> >> context, but it should also be easy (~10 seconds) to find what code
> >> you wrote.
> >>
> >> On Thu, Aug 15, 2019 at 1:27 PM Vaibhav Gupta 
> wrote:
> >> >
> >> > Hello,
> >> > I have made the draft of my project report on google docs.
> >> > I have mentioned about each and every task completed
> >> > and which are in progress.
> >> > .
> >> > It would be very helpful for me If I can get reviews on this,
> >> > will also make required changes.
> >> > .
> >> >
> https://docs.google.com/document/d/1I3FsA0whd2AcLKdagUzins-JmWv1QTC6-0v0uvS1_7k/edit?usp=sharing
> >> > .
> >> > .
> >> > Thank You
> >> > Vaibhav Gupta
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Add steps to test Newlib patch.

[Vaibhav Gupta]

Is it okay to push it??

--Vaibhav Gupta

On Fri, Aug 16, 2019 at 8:14 PM Vaibhav Gupta 
wrote:

> Update the checksum to be used for the Newlib patches.
> Earlier it was msd5, but it is depreciated for security
> reasons. Now RSB accepts sha512.
> ---
>  user/rsb/project-sets.rst | 41 +--
>  1 file changed, 35 insertions(+), 6 deletions(-)
>
> diff --git a/user/rsb/project-sets.rst b/user/rsb/project-sets.rst
> index 5ffce26..b01857e 100644
> --- a/user/rsb/project-sets.rst
> +++ b/user/rsb/project-sets.rst
> @@ -261,17 +261,46 @@ in the ``source-builder/config`` template
> configuration files.
>  To test a patch simply copy it to your local ``patches`` directory. The
> RSB
>  will see the patch is present and will not attempt to download it. Once
> you are
>  happy with the patch submit it to the project and a core developer will
> review
> -it and add it to the RTEMS Tools git repository.  For example, to test a
> local
> -patch for newlib, add the following two lines to the .cfg file in
> -``rtems/config/tools/`` that is included by the bset you use:
> +it and add it to the RTEMS Tools git repository.
> +
> +Testing a Newlib Patch
> +~~
> +
> +To test a local patch for newlib, you need to add the following
> +two lines to the ``.cfg`` file in ``rsb/rtems/config/tools/`` that is
> included
> +by the bset you use:
> +
> +.. topic:: Steps:
> +
> +  1. Create patches for the changes you want to test. (Note: For RSB,
> before
> + creating Newlib patch, you must run ``autoreconf -fvi`` in the
> required
> + directory after you make changes to the code. This is not required
> when
> + you create patch to send to ``newlib-devel``. But if you want RSB to
> + address your changes, your patch should also include regenerated
> files.)
> +
> +  2. Calculate ``sha512`` of your patch.
> +
> +  3. Place the patches in ``rsb/rtems/patches`` directory.
> +
> +  4. Open the ``.bset`` file used by your BSP in ``rsb/rtems/config``.
> + For example, for ``rtems5``, ``SPARC``, the file will be
> + ``rsb/rtems/config/5/rtems-sparc.bset``.
> +
> +  5. Inside it you will find the name of ``.cfg`` file for Newlib, used by
> + your BSP.
> + For example, I found ``tools/rtems-gcc-7.4.0-newlib-1d35a003f``.
> +
> +  6. Edit your ``.cfg`` file. In my case it will be,
> + ``rsb/rtems/config/tools/rtems-gcc-7.4.0-newlib-1d35a003f.cfg``. And
> + add the information about your patch as mentioned below.
>
>  .. code-block:: spec
>
> -%patch add newlib file://0001-this-is-a-newlib-patch.patch   <1>
> -%hash md5 0001-this-is-a-newlib-patch.diff
> 77d070878112783292461bd6e7db17fb <2>
> +%patch add newlib -p1 file://0001-Port-ndbm.patch <1>
> +%hash sha512 0001-Port-ndbm.patch
> 7d999ceeea4f3dc82e8e0aadc09d983a7a68b44470da8a3d61ab6fc558fdba6f2c2de3acc2f32c0b0b97fcc9ab799c27e87afe046544a69519881f947e7881d1
> <2>
>
>  .. topic:: Items:
>
>1. The diff file prepended with ``file://`` to tell RSB this is a local
> file.
>
> -  2. The output from md5sum on the diff file.
> +  2. The output from sha512sum on the patch file.
>
> --
> 2.21.0
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1] Add steps to test Newlib patch.

[Vaibhav Gupta]

Awesome, thanks!

On Fri, Aug 16, 2019 at 8:52 PM Joel Sherrill  wrote:

> Ignoring the v1 vs v2, Jeff Johnson sent me a script to bootstrap newlib
> from the top. I updated it for the addition of fenv.
>
> And you need specifically automake 1.11.6 and autoconf 2.68 per him.
>
> --joel
>
> On Fri, Aug 16, 2019 at 10:03 AM Vaibhav Gupta 
> wrote:
> >
> >
> >
> > On Fri, Aug 16, 2019 at 8:16 PM Gedare Bloom  wrote:
> >>
> >> Vaibhav,
> >>
> >> The use of the -vX is to differentiate patches that are sent to review
> >> on the mailing list.
> >
> > Yeah, actually I assumed that working on different branch may
> > allow us to send patches like this.
> >>
> >> If this is not clear in our contributing
> >> guidelines, we probably need to improve the description...
> >>
> >> On Fri, Aug 16, 2019 at 8:32 AM Vaibhav Gupta 
> wrote:
> >> >
> >> > Sure,
> >> > Actually made this patch on different branch so used -v1.
> >> > Sending a new one with -v2.
> >> >
> >> > -Vaibhav
> >> >
> >> > On Fri, Aug 16, 2019, 7:58 PM Gedare Bloom  wrote:
> >> >>
> >> >> Then this should be sent with -v2.
> >> >>
> >> >> On Thu, Aug 15, 2019 at 1:33 PM Vaibhav Gupta <
> vaibhavgupt...@gmail.com> wrote:
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Thu, Aug 15, 2019 at 8:51 PM Gedare Bloom 
> wrote:
> >> >> >>
> >> >> >> Is this a duplicate of the other "patch v1 Add steps to test
> Newlib patch." or this one replaces it?
> >> >> >
> >> >> > This one replaces it. Actually I replaced all the previous ones
> with mine.
> >> >> > The commands, steps I have written are based on what worked for me
> for number of times.
> >> >> > I build the toolchain twice when RSB got updated, but my changes
> were not pushed so had to
> >> >> > use patches in RSB. And these steps worked perfectly both times.
> >> >> >
> >> >> > -Vaibhav
> >> >> >>
> >> >> >>
> >> >> >> On Wed, Aug 14, 2019 at 11:45 PM Vaibhav Gupta <
> vaibhavgupt...@gmail.com> wrote:
> >> >> >>>
> >> >> >>> Update the checksum to be used for the Newlib patches.
> >> >> >>> Earlier it was msd5, but it is depreciated for security
> >> >> >>> reasons. Now RSB accepts sha512.
> >> >> >>> ---
> >> >> >>>  user/rsb/project-sets.rst | 41
> +--
> >> >> >>>  1 file changed, 35 insertions(+), 6 deletions(-)
> >> >> >>>
> >> >> >>> diff --git a/user/rsb/project-sets.rst
> b/user/rsb/project-sets.rst
> >> >> >>> index 5ffce26..b01857e 100644
> >> >> >>> --- a/user/rsb/project-sets.rst
> >> >> >>> +++ b/user/rsb/project-sets.rst
> >> >> >>> @@ -261,17 +261,46 @@ in the ``source-builder/config`` template
> configuration files.
> >> >> >>>  To test a patch simply copy it to your local ``patches``
> directory. The RSB
> >> >> >>>  will see the patch is present and will not attempt to download
> it. Once you are
> >> >> >>>  happy with the patch submit it to the project and a core
> developer will review
> >> >> >>> -it and add it to the RTEMS Tools git repository.  For example,
> to test a local
> >> >> >>> -patch for newlib, add the following two lines to the .cfg file
> in
> >> >> >>> -``rtems/config/tools/`` that is included by the bset you use:
> >> >> >>> +it and add it to the RTEMS Tools git repository.
> >> >> >>> +
> >> >> >>> +Testing a Newlib Patch
> >> >> >>> +~~
> >> >> >>> +
> >> >> >>> +To test a local patch for newlib, you need to add the following
> >> >> >>> +two lines to the ``.cfg`` file in ``rsb/rtems/config/tools/``
> that is included
> >> >> >>> +by the bset you use:
> >> >> >>> +
> >> >> >>> +.. topic:: Steps:
> >> >> >>> +
> >> 

Re: GSoC 2019 : POSIX Compliance - Final Report

[Vaibhav Gupta]

Made the changes as suggested :)
Please have a look at this now. If every thing is fine.
I will publish it in my blog.

-Vaibhav Gupta

On Fri, Aug 16, 2019 at 7:57 PM Gedare Bloom  wrote:

> Vaibhav,
>
> Please add a subsection near the top that consolidates links to all
> the code you wrote during the summer. It is great to have them in
> context, but it should also be easy (~10 seconds) to find what code
> you wrote.
>
> On Thu, Aug 15, 2019 at 1:27 PM Vaibhav Gupta 
> wrote:
> >
> > Hello,
> > I have made the draft of my project report on google docs.
> > I have mentioned about each and every task completed
> > and which are in progress.
> > .
> > It would be very helpful for me If I can get reviews on this,
> > will also make required changes.
> > .
> >
> https://docs.google.com/document/d/1I3FsA0whd2AcLKdagUzins-JmWv1QTC6-0v0uvS1_7k/edit?usp=sharing
> > .
> > .
> > Thank You
> > Vaibhav Gupta
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1] Add steps to test Newlib patch.

[Vaibhav Gupta]

On Fri, Aug 16, 2019 at 8:16 PM Gedare Bloom  wrote:

> Vaibhav,
>
> The use of the -vX is to differentiate patches that are sent to review
> on the mailing list.

Yeah, actually I assumed that working on different branch may
allow us to send patches like this.

> If this is not clear in our contributing
> guidelines, we probably need to improve the description...
>
> On Fri, Aug 16, 2019 at 8:32 AM Vaibhav Gupta 
> wrote:
> >
> > Sure,
> > Actually made this patch on different branch so used -v1.
> > Sending a new one with -v2.
> >
> > -Vaibhav
> >
> > On Fri, Aug 16, 2019, 7:58 PM Gedare Bloom  wrote:
> >>
> >> Then this should be sent with -v2.
> >>
> >> On Thu, Aug 15, 2019 at 1:33 PM Vaibhav Gupta 
> wrote:
> >> >
> >> >
> >> >
> >> > On Thu, Aug 15, 2019 at 8:51 PM Gedare Bloom 
> wrote:
> >> >>
> >> >> Is this a duplicate of the other "patch v1 Add steps to test Newlib
> patch." or this one replaces it?
> >> >
> >> > This one replaces it. Actually I replaced all the previous ones with
> mine.
> >> > The commands, steps I have written are based on what worked for me
> for number of times.
> >> > I build the toolchain twice when RSB got updated, but my changes were
> not pushed so had to
> >> > use patches in RSB. And these steps worked perfectly both times.
> >> >
> >> > -Vaibhav
> >> >>
> >> >>
> >> >> On Wed, Aug 14, 2019 at 11:45 PM Vaibhav Gupta <
> vaibhavgupt...@gmail.com> wrote:
> >> >>>
> >> >>> Update the checksum to be used for the Newlib patches.
> >> >>> Earlier it was msd5, but it is depreciated for security
> >> >>> reasons. Now RSB accepts sha512.
> >> >>> ---
> >> >>>  user/rsb/project-sets.rst | 41
> +--
> >> >>>  1 file changed, 35 insertions(+), 6 deletions(-)
> >> >>>
> >> >>> diff --git a/user/rsb/project-sets.rst b/user/rsb/project-sets.rst
> >> >>> index 5ffce26..b01857e 100644
> >> >>> --- a/user/rsb/project-sets.rst
> >> >>> +++ b/user/rsb/project-sets.rst
> >> >>> @@ -261,17 +261,46 @@ in the ``source-builder/config`` template
> configuration files.
> >> >>>  To test a patch simply copy it to your local ``patches``
> directory. The RSB
> >> >>>  will see the patch is present and will not attempt to download it.
> Once you are
> >> >>>  happy with the patch submit it to the project and a core developer
> will review
> >> >>> -it and add it to the RTEMS Tools git repository.  For example, to
> test a local
> >> >>> -patch for newlib, add the following two lines to the .cfg file in
> >> >>> -``rtems/config/tools/`` that is included by the bset you use:
> >> >>> +it and add it to the RTEMS Tools git repository.
> >> >>> +
> >> >>> +Testing a Newlib Patch
> >> >>> +~~
> >> >>> +
> >> >>> +To test a local patch for newlib, you need to add the following
> >> >>> +two lines to the ``.cfg`` file in ``rsb/rtems/config/tools/`` that
> is included
> >> >>> +by the bset you use:
> >> >>> +
> >> >>> +.. topic:: Steps:
> >> >>> +
> >> >>> +  1. Create patches for the changes you want to test. (Note: For
> RSB, before
> >> >>> + creating Newlib patch, you must run ``autoreconf -fvi`` in
> the required
> >> >>> + directory after you make changes to the code. This is not
> required when
> >> >>> + you create patch to send to ``newlib-devel``. But if you want
> RSB to
> >> >>> + address your changes, your patch should also include
> regenerated files.)
> >> >>> +
> >> >>> +  2. Calculate ``sha512`` of your patch.
> >> >>> +
> >> >>> +  3. Place the patches in ``rsb/rtems/patches`` directory.
> >> >>> +
> >> >>> +  4. Open the ``.bset`` file used by your BSP in
> ``rsb/rtems/config``.
> >> >>> + For example, for ``rtems5``, ``SPARC``, the file will be
> >> >>> + ``rsb/rtems/config/5/rtems-sparc.bset``.
> >> >>> +
> >> 

[PATCH v2] Add steps to test Newlib patch.

[Vaibhav Gupta]

Update the checksum to be used for the Newlib patches.
Earlier it was msd5, but it is depreciated for security
reasons. Now RSB accepts sha512.
---
 user/rsb/project-sets.rst | 41 +--
 1 file changed, 35 insertions(+), 6 deletions(-)

diff --git a/user/rsb/project-sets.rst b/user/rsb/project-sets.rst
index 5ffce26..b01857e 100644
--- a/user/rsb/project-sets.rst
+++ b/user/rsb/project-sets.rst
@@ -261,17 +261,46 @@ in the ``source-builder/config`` template
configuration files.
 To test a patch simply copy it to your local ``patches`` directory. The RSB
 will see the patch is present and will not attempt to download it. Once
you are
 happy with the patch submit it to the project and a core developer will
review
-it and add it to the RTEMS Tools git repository.  For example, to test a
local
-patch for newlib, add the following two lines to the .cfg file in
-``rtems/config/tools/`` that is included by the bset you use:
+it and add it to the RTEMS Tools git repository.
+
+Testing a Newlib Patch
+~~
+
+To test a local patch for newlib, you need to add the following
+two lines to the ``.cfg`` file in ``rsb/rtems/config/tools/`` that is
included
+by the bset you use:
+
+.. topic:: Steps:
+
+  1. Create patches for the changes you want to test. (Note: For RSB,
before
+ creating Newlib patch, you must run ``autoreconf -fvi`` in the
required
+ directory after you make changes to the code. This is not required
when
+ you create patch to send to ``newlib-devel``. But if you want RSB to
+ address your changes, your patch should also include regenerated
files.)
+
+  2. Calculate ``sha512`` of your patch.
+
+  3. Place the patches in ``rsb/rtems/patches`` directory.
+
+  4. Open the ``.bset`` file used by your BSP in ``rsb/rtems/config``.
+ For example, for ``rtems5``, ``SPARC``, the file will be
+ ``rsb/rtems/config/5/rtems-sparc.bset``.
+
+  5. Inside it you will find the name of ``.cfg`` file for Newlib, used by
+ your BSP.
+ For example, I found ``tools/rtems-gcc-7.4.0-newlib-1d35a003f``.
+
+  6. Edit your ``.cfg`` file. In my case it will be,
+ ``rsb/rtems/config/tools/rtems-gcc-7.4.0-newlib-1d35a003f.cfg``. And
+ add the information about your patch as mentioned below.

 .. code-block:: spec

-%patch add newlib file://0001-this-is-a-newlib-patch.patch   <1>
-%hash md5 0001-this-is-a-newlib-patch.diff
77d070878112783292461bd6e7db17fb <2>
+%patch add newlib -p1 file://0001-Port-ndbm.patch <1>
+%hash sha512 0001-Port-ndbm.patch
7d999ceeea4f3dc82e8e0aadc09d983a7a68b44470da8a3d61ab6fc558fdba6f2c2de3acc2f32c0b0b97fcc9ab799c27e87afe046544a69519881f947e7881d1
<2>

 .. topic:: Items:

   1. The diff file prepended with ``file://`` to tell RSB this is a local
file.

-  2. The output from md5sum on the diff file.
+  2. The output from sha512sum on the patch file.

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

Re: GSoC 2019 : POSIX Compliance - Final Report

[Vaibhav Gupta]

Thanks, working on it.

-Vaibhav

On Fri, Aug 16, 2019 at 7:57 PM Gedare Bloom  wrote:

> Vaibhav,
>
> Please add a subsection near the top that consolidates links to all
> the code you wrote during the summer. It is great to have them in
> context, but it should also be easy (~10 seconds) to find what code
> you wrote.
>
> On Thu, Aug 15, 2019 at 1:27 PM Vaibhav Gupta 
> wrote:
> >
> > Hello,
> > I have made the draft of my project report on google docs.
> > I have mentioned about each and every task completed
> > and which are in progress.
> > .
> > It would be very helpful for me If I can get reviews on this,
> > will also make required changes.
> > .
> >
> https://docs.google.com/document/d/1I3FsA0whd2AcLKdagUzins-JmWv1QTC6-0v0uvS1_7k/edit?usp=sharing
> > .
> > .
> > Thank You
> > Vaibhav Gupta
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1] Add steps to test Newlib patch.

[Vaibhav Gupta]

Sure,
Actually made this patch on different branch so used -v1.
Sending a new one with -v2.

-Vaibhav

On Fri, Aug 16, 2019, 7:58 PM Gedare Bloom  wrote:

> Then this should be sent with -v2.
>
> On Thu, Aug 15, 2019 at 1:33 PM Vaibhav Gupta 
> wrote:
> >
> >
> >
> > On Thu, Aug 15, 2019 at 8:51 PM Gedare Bloom  wrote:
> >>
> >> Is this a duplicate of the other "patch v1 Add steps to test Newlib
> patch." or this one replaces it?
> >
> > This one replaces it. Actually I replaced all the previous ones with
> mine.
> > The commands, steps I have written are based on what worked for me for
> number of times.
> > I build the toolchain twice when RSB got updated, but my changes were
> not pushed so had to
> > use patches in RSB. And these steps worked perfectly both times.
> >
> > -Vaibhav
> >>
> >>
> >> On Wed, Aug 14, 2019 at 11:45 PM Vaibhav Gupta <
> vaibhavgupt...@gmail.com> wrote:
> >>>
> >>> Update the checksum to be used for the Newlib patches.
> >>> Earlier it was msd5, but it is depreciated for security
> >>> reasons. Now RSB accepts sha512.
> >>> ---
> >>>  user/rsb/project-sets.rst | 41 +--
> >>>  1 file changed, 35 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/user/rsb/project-sets.rst b/user/rsb/project-sets.rst
> >>> index 5ffce26..b01857e 100644
> >>> --- a/user/rsb/project-sets.rst
> >>> +++ b/user/rsb/project-sets.rst
> >>> @@ -261,17 +261,46 @@ in the ``source-builder/config`` template
> configuration files.
> >>>  To test a patch simply copy it to your local ``patches`` directory.
> The RSB
> >>>  will see the patch is present and will not attempt to download it.
> Once you are
> >>>  happy with the patch submit it to the project and a core developer
> will review
> >>> -it and add it to the RTEMS Tools git repository.  For example, to
> test a local
> >>> -patch for newlib, add the following two lines to the .cfg file in
> >>> -``rtems/config/tools/`` that is included by the bset you use:
> >>> +it and add it to the RTEMS Tools git repository.
> >>> +
> >>> +Testing a Newlib Patch
> >>> +~~
> >>> +
> >>> +To test a local patch for newlib, you need to add the following
> >>> +two lines to the ``.cfg`` file in ``rsb/rtems/config/tools/`` that is
> included
> >>> +by the bset you use:
> >>> +
> >>> +.. topic:: Steps:
> >>> +
> >>> +  1. Create patches for the changes you want to test. (Note: For RSB,
> before
> >>> + creating Newlib patch, you must run ``autoreconf -fvi`` in the
> required
> >>> + directory after you make changes to the code. This is not
> required when
> >>> + you create patch to send to ``newlib-devel``. But if you want
> RSB to
> >>> + address your changes, your patch should also include regenerated
> files.)
> >>> +
> >>> +  2. Calculate ``sha512`` of your patch.
> >>> +
> >>> +  3. Place the patches in ``rsb/rtems/patches`` directory.
> >>> +
> >>> +  4. Open the ``.bset`` file used by your BSP in ``rsb/rtems/config``.
> >>> + For example, for ``rtems5``, ``SPARC``, the file will be
> >>> + ``rsb/rtems/config/5/rtems-sparc.bset``.
> >>> +
> >>> +  5. Inside it you will find the name of ``.cfg`` file for Newlib,
> used by
> >>> + your BSP.
> >>> + For example, I found ``tools/rtems-gcc-7.4.0-newlib-1d35a003f``.
> >>> +
> >>> +  6. Edit your ``.cfg`` file. In my case it will be,
> >>> + ``rsb/rtems/config/tools/rtems-gcc-7.4.0-newlib-1d35a003f.cfg``.
> And
> >>> + add the information about your patch as mentioned below.
> >>>
> >>>  .. code-block:: spec
> >>>
> >>> -%patch add newlib file://0001-this-is-a-newlib-patch.patch   <1>
> >>> -%hash md5 0001-this-is-a-newlib-patch.diff
> 77d070878112783292461bd6e7db17fb <2>
> >>> +%patch add newlib -p1 file://0001-Port-ndbm.patch <1>
> >>> +%hash sha512 0001-Port-ndbm.patch
> 7d999ceeea4f3dc82e8e0aadc09d983a7a68b44470da8a3d61ab6fc558fdba6f2c2de3acc2f32c0b0b97fcc9ab799c27e87afe046544a69519881f947e7881d1
> <2>
> >>>
> >>>  .. topic:: Items:
> >>>
> >>>1. The diff file prepended with ``file://`` to tell RSB this is a
> local file.
> >>>
> >>> -  2. The output from md5sum on the diff file.
> >>> +  2. The output from sha512sum on the patch file.
> >>>
> >>> --
> >>> 2.21.0
> >>> ___
> >>> 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 v1] Remove back-slash in 'pacman' command in 'PDF' section under Arch Linux (installation of Sphinx).

[Vaibhav Gupta]

I apologize for this , will follow the given instructions from next time.

- Vaibhav

On Thu, Aug 15, 2019 at 8:52 PM Gedare Bloom  wrote:

> Please don't send multiple identical patches to the mailing list. You
> may reply to a patch to 'ping' it if you want to get it some attention
> after it sits for a few days.
>
> On Wed, Aug 14, 2019 at 11:44 PM Vaibhav Gupta 
> wrote:
> >
> > ---
> >  README.txt | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/README.txt b/README.txt
> > index 3679d1d..1567be6 100644
> > --- a/README.txt
> > +++ b/README.txt
> > @@ -247,7 +247,7 @@ Sphinx:
> >
> >  PDF:
> >
> > -  # pacman -S texlive-bin texlive-core texlive-latexextra
> texlive-fontsextra \
> > +  # pacman -S texlive-bin texlive-core texlive-latexextra
> texlive-fontsextra
> >
> >  openSUSE
> >  
> > --
> > 2.21.0
> >
> > ___
> > 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 v1] Add steps to test Newlib patch.

[Vaibhav Gupta]

On Thu, Aug 15, 2019 at 8:51 PM Gedare Bloom  wrote:

> Is this a duplicate of the other "patch v1 Add steps to test Newlib
> patch." or this one replaces it?
>
This one replaces it. Actually I replaced all the previous ones with mine.
The commands, steps I have written are based on what worked for me for
number of times.
I build the toolchain twice when RSB got updated, but my changes were not
pushed so had to
use patches in RSB. And these steps worked perfectly both times.

-Vaibhav

>
> On Wed, Aug 14, 2019 at 11:45 PM Vaibhav Gupta 
> wrote:
>
>> Update the checksum to be used for the Newlib patches.
>> Earlier it was msd5, but it is depreciated for security
>> reasons. Now RSB accepts sha512.
>> ---
>>  user/rsb/project-sets.rst | 41 +--
>>  1 file changed, 35 insertions(+), 6 deletions(-)
>>
>> diff --git a/user/rsb/project-sets.rst b/user/rsb/project-sets.rst
>> index 5ffce26..b01857e 100644
>> --- a/user/rsb/project-sets.rst
>> +++ b/user/rsb/project-sets.rst
>> @@ -261,17 +261,46 @@ in the ``source-builder/config`` template
>> configuration files.
>>  To test a patch simply copy it to your local ``patches`` directory. The
>> RSB
>>  will see the patch is present and will not attempt to download it. Once
>> you are
>>  happy with the patch submit it to the project and a core developer will
>> review
>> -it and add it to the RTEMS Tools git repository.  For example, to test a
>> local
>> -patch for newlib, add the following two lines to the .cfg file in
>> -``rtems/config/tools/`` that is included by the bset you use:
>> +it and add it to the RTEMS Tools git repository.
>> +
>> +Testing a Newlib Patch
>> +~~
>> +
>> +To test a local patch for newlib, you need to add the following
>> +two lines to the ``.cfg`` file in ``rsb/rtems/config/tools/`` that is
>> included
>> +by the bset you use:
>> +
>> +.. topic:: Steps:
>> +
>> +  1. Create patches for the changes you want to test. (Note: For RSB,
>> before
>> + creating Newlib patch, you must run ``autoreconf -fvi`` in the
>> required
>> + directory after you make changes to the code. This is not required
>> when
>> + you create patch to send to ``newlib-devel``. But if you want RSB
>> to
>> + address your changes, your patch should also include regenerated
>> files.)
>> +
>> +  2. Calculate ``sha512`` of your patch.
>> +
>> +  3. Place the patches in ``rsb/rtems/patches`` directory.
>> +
>> +  4. Open the ``.bset`` file used by your BSP in ``rsb/rtems/config``.
>> + For example, for ``rtems5``, ``SPARC``, the file will be
>> + ``rsb/rtems/config/5/rtems-sparc.bset``.
>> +
>> +  5. Inside it you will find the name of ``.cfg`` file for Newlib, used
>> by
>> + your BSP.
>> + For example, I found ``tools/rtems-gcc-7.4.0-newlib-1d35a003f``.
>> +
>> +  6. Edit your ``.cfg`` file. In my case it will be,
>> + ``rsb/rtems/config/tools/rtems-gcc-7.4.0-newlib-1d35a003f.cfg``. And
>> + add the information about your patch as mentioned below.
>>
>>  .. code-block:: spec
>>
>> -%patch add newlib file://0001-this-is-a-newlib-patch.patch   <1>
>> -%hash md5 0001-this-is-a-newlib-patch.diff
>> 77d070878112783292461bd6e7db17fb <2>
>> +%patch add newlib -p1 file://0001-Port-ndbm.patch <1>
>> +%hash sha512 0001-Port-ndbm.patch
>> 7d999ceeea4f3dc82e8e0aadc09d983a7a68b44470da8a3d61ab6fc558fdba6f2c2de3acc2f32c0b0b97fcc9ab799c27e87afe046544a69519881f947e7881d1
>> <2>
>>
>>  .. topic:: Items:
>>
>>1. The diff file prepended with ``file://`` to tell RSB this is a
>> local file.
>>
>> -  2. The output from md5sum on the diff file.
>> +  2. The output from sha512sum on the patch file.
>>
>> --
>> 2.21.0
>> ___
>> 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

GSoC 2019 : POSIX Compliance - Final Report

[Vaibhav Gupta]

Hello,
I have made the draft of my project report on google docs.
I have mentioned about each and every task completed
and which are in progress.
.
It would be very helpful for me If I can get reviews on this,
will also make required changes.
.
https://docs.google.com/document/d/1I3FsA0whd2AcLKdagUzins-JmWv1QTC6-0v0uvS1_7k/edit?usp=sharing
.
.
Thank You
Vaibhav Gupta
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV

[Vaibhav Gupta]

On Wed, Aug 14, 2019 at 8:56 PM Hesham Almatary 
wrote:

> On Wed, 14 Aug 2019 at 16:18, Vaibhav Gupta 
> wrote:
> >
> >
> >
> > On Wed, Aug 14, 2019, 8:09 PM Joel Sherrill  wrote:
> >>
> >> On Wed, Aug 14, 2019 at 9:35 AM Vaibhav Gupta 
> wrote:
> >> >
> >> > You are also getting same error :(
> >> > I thought problem is with my system/laptop and was trying to correct
> things.
> >> > Should we take the discussion to newlib?
> >>
> >> I would like Jiri and Hesham to chime in on the next step. I don't
> >> know the RISC-V
> >> well enough to say if this is a bug in risc-v fenv or not.
> >
> > Okay
>
> Can you try to build a BSP with FPU instructions? rv32imafdc? and test
> again? I assume this will eventually do FPU calculations that will
> emit FPU instructions in the case of rv32imafdc or softfloat in the
> case of rv32imac.
>
Hello, I tried with rv32imafdc too, same problem. I have sent a more proper
report on
devel with the patch for code I was working on.
It seems to be riscv specific issue.

-- Vaibhav Gupta

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

GSoC 2019 : POSIX Complaince - Fenv methods not returning expected outputs.

[Vaibhav Gupta]

Hello,
In yesterday's weekly meeting I mentioned about fenv problems I faced while
developing testsuite.
.
Here is a very raw patch of my code as testsuite is still in development.
.
==
Error 1
==
I took three float values:
a = 0.0
b = 1.0
c = b/a
This should have automatically raised FE_DIVBYZERO exception, which does
not happens.
No exception flag is set.
.
.
==
Error 2
==
Then I tried to raise an exception manually using feraiseexcept(), but this
operation was also unsuccessful .
The method returned 1 on execution, but it should return 0 on successful
operation.
.
.
==
Warning
==
As mentioned in opengroup I tried to define a pragma
https://pubs.opengroup.org/onlinepubs/009696799/basedefs/fenv.h.html
.
#pragma STDC FENV_ACCESS ON
.
But this pragma is ignored while 'make -j 2'
/home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:50:
warning: ignoring #pragma STDC FENV_ACCESS [-Wunknown-pragmas]

.
.

--Vaibhav Gupta
From 3ed1e005dd7629c2b0501cac457a758f3103b1fe Mon Sep 17 00:00:00 2001
From: Vaibhav Gupta 
Date: Thu, 15 Aug 2019 15:09:28 +0530
Subject: [PATCH] Trial 10

---
 testsuites/psxtests/Makefile.am  |   8 ++
 testsuites/psxtests/configure.ac |   1 +
 testsuites/psxtests/psxfenv01/init.c | 121 +++
 3 files changed, 130 insertions(+)
 create mode 100644 testsuites/psxtests/psxfenv01/init.c

diff --git a/testsuites/psxtests/Makefile.am b/testsuites/psxtests/Makefile.am
index c12b03636d..f6ab42fab5 100755
--- a/testsuites/psxtests/Makefile.am
+++ b/testsuites/psxtests/Makefile.am
@@ -415,6 +415,14 @@ psxfchx01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfchx01) \
 	$(support_includes) -I$(top_srcdir)/include
 endif
 
+if TEST_psxfenv01
+psx_tests += psxfenv01
+psxfenv01_SOURCES = psxfenv01/init.c
+psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
+   $(support_includes)
+psxfenv01_LDADD = -lm $(LDADD)
+endif
+
 if TEST_psxfile01
 psx_tests += psxfile01
 psx_screens += psxfile01/psxfile01.scn
diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/configure.ac
index bb44bb8883..92d3543acb 100644
--- a/testsuites/psxtests/configure.ac
+++ b/testsuites/psxtests/configure.ac
@@ -83,6 +83,7 @@ RTEMS_TEST_CHECK([psxenosys])
 RTEMS_TEST_CHECK([psxfatal01])
 RTEMS_TEST_CHECK([psxfatal02])
 RTEMS_TEST_CHECK([psxfchx01])
+RTEMS_TEST_CHECK([psxfenv01])
 RTEMS_TEST_CHECK([psxfile01])
 RTEMS_TEST_CHECK([psxfile02])
 RTEMS_TEST_CHECK([psxfilelock01])
diff --git a/testsuites/psxtests/psxfenv01/init.c b/testsuites/psxtests/psxfenv01/init.c
new file mode 100644
index 00..eae02da22e
--- /dev/null
+++ b/testsuites/psxtests/psxfenv01/init.c
@@ -0,0 +1,121 @@
+/*
+ *  @file
+ *  @brief Test suite for fenv.h methods
+ */
+
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2019 Vaibhav Gupta
+ *
+ * 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.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+/* header files are listed in lexical/lexicographical/alphabetical order */
+
+#include 
+#include 
+#include 
+#include/* contains declarations of fenv methods */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#pragma STDC FENV_ACCESS ON
+
+const char rtems_test_name[] = "PSXFENV 01";
+
+/* forward declarations to avoid warnings */
+rtems_task Init(rtems_task_argument ignored);
+

[PATCH v1] Add steps to test Newlib patch.

[Vaibhav Gupta]

Update the checksum to be used for the Newlib patches.
Earlier it was msd5, but it is depreciated for security
reasons. Now RSB accepts sha512.
---
 user/rsb/project-sets.rst | 41 +--
 1 file changed, 35 insertions(+), 6 deletions(-)

diff --git a/user/rsb/project-sets.rst b/user/rsb/project-sets.rst
index 5ffce26..b01857e 100644
--- a/user/rsb/project-sets.rst
+++ b/user/rsb/project-sets.rst
@@ -261,17 +261,46 @@ in the ``source-builder/config`` template
configuration files.
 To test a patch simply copy it to your local ``patches`` directory. The RSB
 will see the patch is present and will not attempt to download it. Once
you are
 happy with the patch submit it to the project and a core developer will
review
-it and add it to the RTEMS Tools git repository.  For example, to test a
local
-patch for newlib, add the following two lines to the .cfg file in
-``rtems/config/tools/`` that is included by the bset you use:
+it and add it to the RTEMS Tools git repository.
+
+Testing a Newlib Patch
+~~
+
+To test a local patch for newlib, you need to add the following
+two lines to the ``.cfg`` file in ``rsb/rtems/config/tools/`` that is
included
+by the bset you use:
+
+.. topic:: Steps:
+
+  1. Create patches for the changes you want to test. (Note: For RSB,
before
+ creating Newlib patch, you must run ``autoreconf -fvi`` in the
required
+ directory after you make changes to the code. This is not required
when
+ you create patch to send to ``newlib-devel``. But if you want RSB to
+ address your changes, your patch should also include regenerated
files.)
+
+  2. Calculate ``sha512`` of your patch.
+
+  3. Place the patches in ``rsb/rtems/patches`` directory.
+
+  4. Open the ``.bset`` file used by your BSP in ``rsb/rtems/config``.
+ For example, for ``rtems5``, ``SPARC``, the file will be
+ ``rsb/rtems/config/5/rtems-sparc.bset``.
+
+  5. Inside it you will find the name of ``.cfg`` file for Newlib, used by
+ your BSP.
+ For example, I found ``tools/rtems-gcc-7.4.0-newlib-1d35a003f``.
+
+  6. Edit your ``.cfg`` file. In my case it will be,
+ ``rsb/rtems/config/tools/rtems-gcc-7.4.0-newlib-1d35a003f.cfg``. And
+ add the information about your patch as mentioned below.

 .. code-block:: spec

-%patch add newlib file://0001-this-is-a-newlib-patch.patch   <1>
-%hash md5 0001-this-is-a-newlib-patch.diff
77d070878112783292461bd6e7db17fb <2>
+%patch add newlib -p1 file://0001-Port-ndbm.patch <1>
+%hash sha512 0001-Port-ndbm.patch
7d999ceeea4f3dc82e8e0aadc09d983a7a68b44470da8a3d61ab6fc558fdba6f2c2de3acc2f32c0b0b97fcc9ab799c27e87afe046544a69519881f947e7881d1
<2>

 .. topic:: Items:

   1. The diff file prepended with ``file://`` to tell RSB this is a local
file.

-  2. The output from md5sum on the diff file.
+  2. The output from sha512sum on the patch file.

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

Fwd: [PATCH v1] Remove back-slash in 'pacman' command in 'PDF' section under Arch Linux (installation of Sphinx).

[Vaibhav Gupta]

---
 README.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.txt b/README.txt
index 3679d1d..1567be6 100644
--- a/README.txt
+++ b/README.txt
@@ -247,7 +247,7 @@ Sphinx:

 PDF:

-  # pacman -S texlive-bin texlive-core texlive-latexextra
texlive-fontsextra \
+  # pacman -S texlive-bin texlive-core texlive-latexextra
texlive-fontsextra

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

Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV

[Vaibhav Gupta]

On Wed, Aug 14, 2019 at 8:56 PM Hesham Almatary 
wrote:

> On Wed, 14 Aug 2019 at 16:18, Vaibhav Gupta 
> wrote:
> >
> >
> >
> > On Wed, Aug 14, 2019, 8:09 PM Joel Sherrill  wrote:
> >>
> >> On Wed, Aug 14, 2019 at 9:35 AM Vaibhav Gupta 
> wrote:
> >> >
> >> > You are also getting same error :(
> >> > I thought problem is with my system/laptop and was trying to correct
> things.
> >> > Should we take the discussion to newlib?
> >>
> >> I would like Jiri and Hesham to chime in on the next step. I don't
> >> know the RISC-V
> >> well enough to say if this is a bug in risc-v fenv or not.
> >
> > Okay
>
> Can you try to build a BSP with FPU instructions? rv32imafdc? and test
> again? I assume this will eventually do FPU calculations that will
> emit FPU instructions in the case of rv32imafdc or softfloat in the
> case of rv32imac.
>
Okay I will try this direction too then.

>
> >>
> >>
> >> Keep plugging at another architecture.
> >
> > On that!
> >>
> >>
> >> --joel
> >>
> >> >
> >> > Vaibhav Gupta
> >> >
> >> > On Wed, Aug 14, 2019 at 7:51 PM Joel Sherrill  wrote:
> >> >>
> >> >>
> >> >> I ran it on sis built from the git repository. Unfortunately, the
> output doesn't match that I got on Linux.
> >> >>
> >> >> =
> >> >> $ ~/sis-riscv/install/bin/sis -riscv -gdb
> >> >>
> >> >>  SIS - SPARC/RISCV instruction simulator 2.17,  copyright Jiri
> Gaisler 2019
> >> >>  Bug-reports to j...@gaisler.se
> >> >>
> >> >>  RISCV emulation enabled, 1 cpus online, delta 50 clocks
> >> >>
> >> >> gdb: listening on port 1234 connected
> >> >> X4000,0:#72
> >> >>
> >> >>
> >> >> *** BEGIN OF TEST PSXFENV 01 ***
> >> >> *** TEST VERSION: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
> >> >> *** TEST STATE: EXPECTED-PASS
> >> >> *** TEST BUILD: RTEMS_POSIX_API
> >> >> *** TEST TOOLS: 9.1.0 20190503 (RTEMS 5, RSB
> be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
> >> >>
> >> >> Divide by zero and confirm fetestexcept().
> >> >>
> >> >> 8
> >> >> 0
> >> >> 1
> >> >>
> >> >> *** END OF TEST PSXFENV 01 ***
> >> >>
> >> >>
> >> >> *** FATAL ***
> >> >> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
> >> >> fatal code: 0 (0x)
> >> >> RTEMS version: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
> >> >> RTEMS tools: 9.1.0 20190503 (RTEMS 5, RSB
> be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
> >> >> executing thread ID: 0x08a010001
> >> >> executing thread name: UI1
> >> >> =
> >> >> On Wed, Aug 14, 2019 at 7:55 AM Vaibhav Gupta <
> vaibhavgupt...@gmail.com> wrote:
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Wed, Aug 14, 2019 at 6:22 PM Hesham Almatary <
> heshamelmat...@gmail.com> wrote:
> >> >>>>
> >> >>>> On Sun, 11 Aug 2019 at 16:49, Vaibhav Gupta <
> vaibhavgupt...@gmail.com> wrote:
> >> >>>> >
> >> >>>> > Configure command I used to build BSP:
> >> >>>> > ==
> >> >>>> > $ /home/varodek/development/rtems/kernel/rtems/configure
> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
> --enable-posix --disable-networking --enable-cxx RISCV_ENABLE_HTIF_SUPPORT=1
> >> >>>> > ==
> >> >>>> > .
> >> >>>> RISCV_ENABLE_HTIF_SUPPORT=1 should only be used if you're going to
> run
> >> >>>> on a Spike platform. I see you're using virt below
> >> >>>
> >> >>> Yah this was the time I was doing all kind of experiments to run
> the hello  world thing.
> >> >>> I have disabled HTIF now.
> >> >>>>
> >> >>>>
> >> >>>> > .
&g

Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV

[Vaibhav Gupta]

On Wed, Aug 14, 2019, 8:09 PM Joel Sherrill  wrote:

> On Wed, Aug 14, 2019 at 9:35 AM Vaibhav Gupta 
> wrote:
> >
> > You are also getting same error :(
> > I thought problem is with my system/laptop and was trying to correct
> things.
> > Should we take the discussion to newlib?
>
> I would like Jiri and Hesham to chime in on the next step. I don't
> know the RISC-V
> well enough to say if this is a bug in risc-v fenv or not.
>
Okay

>
> Keep plugging at another architecture.
>
On that!

>
> --joel
>
> >
> > Vaibhav Gupta
> >
> > On Wed, Aug 14, 2019 at 7:51 PM Joel Sherrill  wrote:
> >>
> >>
> >> I ran it on sis built from the git repository. Unfortunately, the
> output doesn't match that I got on Linux.
> >>
> >> =
> >> $ ~/sis-riscv/install/bin/sis -riscv -gdb
> >>
> >>  SIS - SPARC/RISCV instruction simulator 2.17,  copyright Jiri Gaisler
> 2019
> >>  Bug-reports to j...@gaisler.se
> >>
> >>  RISCV emulation enabled, 1 cpus online, delta 50 clocks
> >>
> >> gdb: listening on port 1234 connected
> >> X4000,0:#72
> >>
> >>
> >> *** BEGIN OF TEST PSXFENV 01 ***
> >> *** TEST VERSION: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
> >> *** TEST STATE: EXPECTED-PASS
> >> *** TEST BUILD: RTEMS_POSIX_API
> >> *** TEST TOOLS: 9.1.0 20190503 (RTEMS 5, RSB
> be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
> >>
> >> Divide by zero and confirm fetestexcept().
> >>
> >> 8
> >> 0
> >> 1
> >>
> >> *** END OF TEST PSXFENV 01 ***
> >>
> >>
> >> *** FATAL ***
> >> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
> >> fatal code: 0 (0x)
> >> RTEMS version: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
> >> RTEMS tools: 9.1.0 20190503 (RTEMS 5, RSB
> be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
> >> executing thread ID: 0x08a010001
> >> executing thread name: UI1
> >> =
> >> On Wed, Aug 14, 2019 at 7:55 AM Vaibhav Gupta 
> wrote:
> >>>
> >>>
> >>>
> >>> On Wed, Aug 14, 2019 at 6:22 PM Hesham Almatary <
> heshamelmat...@gmail.com> wrote:
> >>>>
> >>>> On Sun, 11 Aug 2019 at 16:49, Vaibhav Gupta 
> wrote:
> >>>> >
> >>>> > Configure command I used to build BSP:
> >>>> > ==
> >>>> > $ /home/varodek/development/rtems/kernel/rtems/configure
> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
> --enable-posix --disable-networking --enable-cxx RISCV_ENABLE_HTIF_SUPPORT=1
> >>>> > ==
> >>>> > .
> >>>> RISCV_ENABLE_HTIF_SUPPORT=1 should only be used if you're going to run
> >>>> on a Spike platform. I see you're using virt below
> >>>
> >>> Yah this was the time I was doing all kind of experiments to run the
> hello  world thing.
> >>> I have disabled HTIF now.
> >>>>
> >>>>
> >>>> > .
> >>>> > .
> >>>> > .
> >>>> > Qemu command I used to run test:
> >>>> > ==
> >>>> > $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
> -kernel psxfenv01.exe
> >>>> > ==
> >>>> > .
> >>>> > .
> >>>> > .
> >>>> > .
> >>>> > Makefile.am
> >>>> > ==
> >>>> > + if TEST_psxfenv01
> >>>> > + psx_tests += psxfenv01
> >>>> > + psxfenv01_SOURCES = psxfenv01/init.c
> >>>> > + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
> >>>> > +   $(support_includes)
> >>>> > + psxfenv01_LDADD = -lm $(LDADD)
> >>>> > + endif
> >>>> > +
> >>>> > ==
> >>>> >
> >>>> > On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta <
> vaibhavgupt...@gmail.com> wrote:
> >>>> >>
> >>&g

Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV

[Vaibhav Gupta]

You are also getting same error :(
I thought problem is with my system/laptop and was trying to correct things.
Should we take the discussion to newlib?

Vaibhav Gupta

On Wed, Aug 14, 2019 at 7:51 PM Joel Sherrill  wrote:

>
> I ran it on sis built from the git repository. Unfortunately, the output
> doesn't match that I got on Linux.
>
> =
> $ ~/sis-riscv/install/bin/sis -riscv -gdb
>
>  SIS - SPARC/RISCV instruction simulator 2.17,  copyright Jiri Gaisler 2019
>  Bug-reports to j...@gaisler.se
>
>  RISCV emulation enabled, 1 cpus online, delta 50 clocks
>
> gdb: listening on port 1234 connected
> X4000,0:#72
>
>
> *** BEGIN OF TEST PSXFENV 01 ***
> *** TEST VERSION: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
> *** TEST STATE: EXPECTED-PASS
> *** TEST BUILD: RTEMS_POSIX_API
> *** TEST TOOLS: 9.1.0 20190503 (RTEMS 5, RSB
> be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
>
> Divide by zero and confirm fetestexcept().
>
> 8
> 0
> 1
>
> *** END OF TEST PSXFENV 01 ***
>
>
> *** FATAL ***
> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
> fatal code: 0 (0x)
> RTEMS version: 5.0.0.a4d7e4cee77d16b0e34ef543f0804e7eb2954137
> RTEMS tools: 9.1.0 20190503 (RTEMS 5, RSB
> be90fb89678206e469f2f9189eb290cec49fd827, Newlib 6661a67)
> executing thread ID: 0x08a010001
> executing thread name: UI1
> =
> On Wed, Aug 14, 2019 at 7:55 AM Vaibhav Gupta 
> wrote:
>
>>
>>
>> On Wed, Aug 14, 2019 at 6:22 PM Hesham Almatary 
>> wrote:
>>
>>> On Sun, 11 Aug 2019 at 16:49, Vaibhav Gupta 
>>> wrote:
>>> >
>>> > Configure command I used to build BSP:
>>> > ==
>>> > $ /home/varodek/development/rtems/kernel/rtems/configure
>>> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
>>> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
>>> --enable-posix --disable-networking --enable-cxx RISCV_ENABLE_HTIF_SUPPORT=1
>>> > ==
>>> > .
>>> RISCV_ENABLE_HTIF_SUPPORT=1 should only be used if you're going to run
>>> on a Spike platform. I see you're using virt below
>>>
>> Yah this was the time I was doing all kind of experiments to run the
>> hello  world thing.
>> I have disabled HTIF now.
>>
>>>
>>> > .
>>> > .
>>> > .
>>> > Qemu command I used to run test:
>>> > ==
>>> > $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
>>> -kernel psxfenv01.exe
>>> > ==
>>> > .
>>> > .
>>> > .
>>> > .
>>> > Makefile.am
>>> > ==
>>> > + if TEST_psxfenv01
>>> > + psx_tests += psxfenv01
>>> > + psxfenv01_SOURCES = psxfenv01/init.c
>>> > + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
>>> > +   $(support_includes)
>>> > + psxfenv01_LDADD = -lm $(LDADD)
>>> > + endif
>>> > +
>>> > ==
>>> >
>>> > On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta <
>>> vaibhavgupt...@gmail.com> wrote:
>>> >>
>>> >> My code of testsuite:
>>> >> ===
>>> >>   /* Test 'FE_DIVBYZERO' */
>>> >>   puts( "\nDivide by zero and confirm fetestexcept()." );
>>> >>   a = 0.0;
>>> >>   b = 1.0;
>>> >>   c = b/a;
>>> >>   printf("\n%d",FE_DIVBYZERO);
>>> >>   fegetexceptflag(&excepts,FE_ALL_EXCEPT);
>>> >>   printf("\n%d",excepts);
>>> >>   r = feraiseexcept(FE_DIVBYZERO);
>>> >>   printf("\n%d\n",r);
>>> >>   rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
>>> >> ==
>>> >> OUTPUT
>>> >> ==
>>> >> Divide by zero and confirm fetestexcept().
>>> >>
>>> >> 8
>>> >> 0
>>> >> 1
>>> >>
>>> /home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
>>> 84 fetestexcept( FE_DIVBYZERO )
>>> >> ==
>>> >> EXPECTED OUTPUT
>>> >> ==
>>> >> Divide by zero and confirm fetestexcept().
>>> >>
>>> >> 8
>>> >> 8
>>> >> 0
>>> >> ==
>>> >> - fetestexcept( FE_DIVBYZERO ), should return a non-zero value as
>>> division-by-zero was performed.
>>> >> .
>>> >> - feraiseexcept(FE_DIVBYZERO); is also not working. It should return
>>> zero when successful
>>> >> .
>>> >> ==
>>> >>
>>> >> Thank You
>>> >> Vaibhav Gupta
>>> >>
>>> > ___
>>> > devel mailing list
>>> > devel@rtems.org
>>> > http://lists.rtems.org/mailman/listinfo/devel
>>>
>>> --
>>> Hesham
>>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV

[Vaibhav Gupta]

On Wed, Aug 14, 2019 at 6:22 PM Hesham Almatary 
wrote:

> On Sun, 11 Aug 2019 at 16:49, Vaibhav Gupta 
> wrote:
> >
> > Configure command I used to build BSP:
> > ==
> > $ /home/varodek/development/rtems/kernel/rtems/configure
> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
> --enable-posix --disable-networking --enable-cxx RISCV_ENABLE_HTIF_SUPPORT=1
> > ==
> > .
> RISCV_ENABLE_HTIF_SUPPORT=1 should only be used if you're going to run
> on a Spike platform. I see you're using virt below
>
Yah this was the time I was doing all kind of experiments to run the hello
world thing.
I have disabled HTIF now.

>
> > .
> > .
> > .
> > Qemu command I used to run test:
> > ==
> > $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
> -kernel psxfenv01.exe
> > ==
> > .
> > .
> > .
> > .
> > Makefile.am
> > ==
> > + if TEST_psxfenv01
> > + psx_tests += psxfenv01
> > + psxfenv01_SOURCES = psxfenv01/init.c
> > + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
> > +   $(support_includes)
> > + psxfenv01_LDADD = -lm $(LDADD)
> > + endif
> > +
> > ==
> >
> > On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta 
> wrote:
> >>
> >> My code of testsuite:
> >> ===
> >>   /* Test 'FE_DIVBYZERO' */
> >>   puts( "\nDivide by zero and confirm fetestexcept()." );
> >>   a = 0.0;
> >>   b = 1.0;
> >>   c = b/a;
> >>   printf("\n%d",FE_DIVBYZERO);
> >>   fegetexceptflag(&excepts,FE_ALL_EXCEPT);
> >>   printf("\n%d",excepts);
> >>   r = feraiseexcept(FE_DIVBYZERO);
> >>   printf("\n%d\n",r);
> >>   rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
> >> ==
> >> OUTPUT
> >> ==
> >> Divide by zero and confirm fetestexcept().
> >>
> >> 8
> >> 0
> >> 1
> >>
> /home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
> 84 fetestexcept( FE_DIVBYZERO )
> >> ==
> >> EXPECTED OUTPUT
> >> ==
> >> Divide by zero and confirm fetestexcept().
> >>
> >> 8
> >> 8
> >> 0
> >> ==
> >> - fetestexcept( FE_DIVBYZERO ), should return a non-zero value as
> division-by-zero was performed.
> >> .
> >> - feraiseexcept(FE_DIVBYZERO); is also not working. It should return
> zero when successful
> >> .
> >> ==
> >>
> >> Thank You
> >> Vaibhav Gupta
> >>
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> --
> Hesham
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV

[Vaibhav Gupta]

So I cloned the 'sis' repository and build it locally:
$  git clone git://git.rtems.org/sis.git
.
.
On one terminal I was running sis:
$ ~/development/sis/sis -riscv nouartrx -gdb
.
.
.
.
On another terminal I did:
$ riscv-rtems5-gdb psxfenv01.exe

Reading symbols from psxfenv01.exe...done.
(gdb) target extended-remote localhost:1234
Remote debugging using localhost:1234
0x in ?? ()
(gdb) load
Loading section .start, size 0x3c lma 0x8000
Loading section .text, size 0xd8c4 lma 0x803c
Loading section .rodata, size 0x11e29 lma 0x8000d900
Loading section .sdata2, size 0x20 lma 0x8001f72c
Loading section .eh_frame, size 0x68 lma 0x8001f74c
Loading section .init_array, size 0x4 lma 0x8001f7b4
Loading section .fini_array, size 0x4 lma 0x8001f7b8
Loading section .rtemsroset, size 0x34 lma 0x8001f7bc
Loading section .data, size 0x488 lma 0x8001f7f0
Loading section .htif, size 0x1000 lma 0x8001fc80
Loading section .sdata, size 0x3c lma 0x80021000
Start address 0x8000, load size 134321
Transfer rate: 2474 KB/sec, 236 bytes/write.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program:
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/psxtests/psxfenv01.exe

.
.
The screen just hangs here.

Vaibhav Gupta

On Wed, Aug 14, 2019 at 12:48 PM Jiri Gaisler  wrote:

> I have attached the sis manual. Page 17:
>
> "SIS can be connected to gdb through a network socket using the gdb remote 
> interface.
> Either start SIS with -gdb, or issue the ’gdb’ command inside SIS, and 
> connect gdb with
> ’target extended-remote localhost:1234’. The port can be changed using the 
> -port option."
>
> You still need all other options, so to start on a windows host do:
>
> $ riscv-rtems-sis -riscv -nouartrx -gdb
>
> To start gdb, do:
>
> $ riscv-rtems-gdb app.exe
>
> (gdb) target extended-remote localhost:1234
>
> (gdb) load
>
> (gdb) run
>
> To re-run the application, issue a new load command first.
>
> Regards, Jiri.
>
> On 8/14/19 12:37 AM, Vaibhav Gupta wrote:
>
>
>
> On Wed, Aug 14, 2019 at 4:04 AM Joel Sherrill  wrote:
>
>>
>>
>> On Tue, Aug 13, 2019 at 5:09 PM Vaibhav Gupta 
>> wrote:
>>
>>>
>>>
>>> On Mon, Aug 12, 2019 at 11:50 PM Joel Sherrill  wrote:
>>>
>>>> Can you post or email me privately the full patch? I can try to see
>>>> what I spot.
>>>>
>>> I have sent you the patch.
>>>
>>>>
>>>> Can you check with objdump or gdb that the methods which don't appear
>>>> to work
>>>> are actually the RISC-V implementation? Look at the disassembly and see
>>>> if it
>>>> looks like you expect.
>>>>
>>> I am exploring for this.
>>>
>>
>> Since I don't know how to attach gdb to the new sis for griscv, I emailed
>> Jiri privately.
>> Your program works as expected on Linux. Perhaps Jiri has some advice for
>> my
>> debugging setup ignorance and fenv on RISC-V.
>>
> Okay, I will wait. Till then I can work with porting for other
> architecture. :)
>
>>
>> Do you happen to have fenv support for another architecture queued up? It
>> would be
>> interesting to see if it works on other targets.
>>
> Yup, they were in my to do list. Till testsuite method is solved, I will
> work on them now.
>
> - Vaibhav Gupta
>
>>
>> --joel
>>
>>
>>>
>>> - Vaibhav Gupta
>>>
>>>>
>>>> Does this require a patch to newlib as well?
>>>>
>>>> --joel
>>>>
>>>> On Sun, Aug 11, 2019 at 10:49 AM Vaibhav Gupta <
>>>> vaibhavgupt...@gmail.com> wrote:
>>>>
>>>>> Configure command I used to build BSP:
>>>>> ==
>>>>> $ /home/varodek/development/rtems/kernel/rtems/configure
>>>>> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
>>>>> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
>>>>> --enable-posix --disable-networking --enable-cxx 
>>>>> RISCV_ENABLE_HTIF_SUPPORT=1
>>>>> ==
>>>>> .
>>>>> .
>>>>> .
>>>>> .
>>>>> Qemu command I used to run test:
>>>>> ==
>>>>> $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
>>>>> -kernel psxfenv01.exe
>>>&g

Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV

[Vaibhav Gupta]

Hello
I get following errors:
=
$ riscv-rtems5-sis -riscv -nouartrx -gdb

 SIS - SPARC/RISCV instruction simulator 2.13,  copyright Jiri Gaisler 2019
 Bug-reports to j...@gaisler.se

unknown option -riscv
usage: sis [-uart1 uart_device1] [-uart2 uart_device2]
[-m ] [-dumbio] [-v]
[-nfp] [-freq frequency] [-c batch_file] [files]
=
$ riscv-rtems5-sis -gdb

 SIS - SPARC/RISCV instruction simulator 2.13,  copyright Jiri Gaisler 2019
 Bug-reports to j...@gaisler.se

unknown option -gdb
usage: sis [-uart1 uart_device1] [-uart2 uart_device2]
[-m ] [-dumbio] [-v]
[-nfp] [-freq frequency] [-c batch_file] [files]
=

Vaibhav Gupta

On Wed, Aug 14, 2019 at 5:14 PM Joel Sherrill  wrote:

> Thank you.
>
> Do you see anything wrong with the riscv fenv implementation? His program
> runs under Linux and hangs on both Qemu and sis.
>
> On Wed, Aug 14, 2019, 2:18 AM Jiri Gaisler  wrote:
>
>> I have attached the sis manual. Page 17:
>>
>> "SIS can be connected to gdb through a network socket using the gdb remote 
>> interface.
>> Either start SIS with -gdb, or issue the ’gdb’ command inside SIS, and 
>> connect gdb with
>> ’target extended-remote localhost:1234’. The port can be changed using the 
>> -port option."
>>
>> You still need all other options, so to start on a windows host do:
>>
>> $ riscv-rtems-sis -riscv -nouartrx -gdb
>>
>> To start gdb, do:
>>
>> $ riscv-rtems-gdb app.exe
>>
>> (gdb) target extended-remote localhost:1234
>>
>> (gdb) load
>>
>> (gdb) run
>>
>> To re-run the application, issue a new load command first.
>>
>> Regards, Jiri.
>>
>> On 8/14/19 12:37 AM, Vaibhav Gupta wrote:
>>
>>
>>
>> On Wed, Aug 14, 2019 at 4:04 AM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Tue, Aug 13, 2019 at 5:09 PM Vaibhav Gupta 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Aug 12, 2019 at 11:50 PM Joel Sherrill  wrote:
>>>>
>>>>> Can you post or email me privately the full patch? I can try to see
>>>>> what I spot.
>>>>>
>>>> I have sent you the patch.
>>>>
>>>>>
>>>>> Can you check with objdump or gdb that the methods which don't appear
>>>>> to work
>>>>> are actually the RISC-V implementation? Look at the disassembly and
>>>>> see if it
>>>>> looks like you expect.
>>>>>
>>>> I am exploring for this.
>>>>
>>>
>>> Since I don't know how to attach gdb to the new sis for griscv, I
>>> emailed Jiri privately.
>>> Your program works as expected on Linux. Perhaps Jiri has some advice
>>> for my
>>> debugging setup ignorance and fenv on RISC-V.
>>>
>> Okay, I will wait. Till then I can work with porting for other
>> architecture. :)
>>
>>>
>>> Do you happen to have fenv support for another architecture queued up?
>>> It would be
>>> interesting to see if it works on other targets.
>>>
>> Yup, they were in my to do list. Till testsuite method is solved, I will
>> work on them now.
>>
>> - Vaibhav Gupta
>>
>>>
>>> --joel
>>>
>>>
>>>>
>>>> - Vaibhav Gupta
>>>>
>>>>>
>>>>> Does this require a patch to newlib as well?
>>>>>
>>>>> --joel
>>>>>
>>>>> On Sun, Aug 11, 2019 at 10:49 AM Vaibhav Gupta <
>>>>> vaibhavgupt...@gmail.com> wrote:
>>>>>
>>>>>> Configure command I used to build BSP:
>>>>>> ==
>>>>>> $ /home/varodek/development/rtems/kernel/rtems/configure
>>>>>> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
>>>>>> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
>>>>>> --enable-posix --disable-networking --enable-cxx 
>>>>>> RISCV_ENABLE_HTIF_SUPPORT=1
>>>>>> ==
>>>>>> .
>>>>>> .
>>>>>> .
>>>>>> .
>>>>>> Qemu command I used to run test:
>>>>>> ==
>>>>>> $ qemu-system-riscv32 -no

Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV

[Vaibhav Gupta]

On Wed, Aug 14, 2019 at 4:04 AM Joel Sherrill  wrote:

>
>
> On Tue, Aug 13, 2019 at 5:09 PM Vaibhav Gupta 
> wrote:
>
>>
>>
>> On Mon, Aug 12, 2019 at 11:50 PM Joel Sherrill  wrote:
>>
>>> Can you post or email me privately the full patch? I can try to see what
>>> I spot.
>>>
>> I have sent you the patch.
>>
>>>
>>> Can you check with objdump or gdb that the methods which don't appear to
>>> work
>>> are actually the RISC-V implementation? Look at the disassembly and see
>>> if it
>>> looks like you expect.
>>>
>> I am exploring for this.
>>
>
> Since I don't know how to attach gdb to the new sis for griscv, I emailed
> Jiri privately.
> Your program works as expected on Linux. Perhaps Jiri has some advice for
> my
> debugging setup ignorance and fenv on RISC-V.
>
Okay, I will wait. Till then I can work with porting for other
architecture. :)

>
> Do you happen to have fenv support for another architecture queued up? It
> would be
> interesting to see if it works on other targets.
>
Yup, they were in my to do list. Till testsuite method is solved, I will
work on them now.

- Vaibhav Gupta

>
> --joel
>
>
>>
>> - Vaibhav Gupta
>>
>>>
>>> Does this require a patch to newlib as well?
>>>
>>> --joel
>>>
>>> On Sun, Aug 11, 2019 at 10:49 AM Vaibhav Gupta 
>>> wrote:
>>>
>>>> Configure command I used to build BSP:
>>>> ==
>>>> $ /home/varodek/development/rtems/kernel/rtems/configure
>>>> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
>>>> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
>>>> --enable-posix --disable-networking --enable-cxx 
>>>> RISCV_ENABLE_HTIF_SUPPORT=1
>>>> ==
>>>> .
>>>> .
>>>> .
>>>> .
>>>> Qemu command I used to run test:
>>>> ==
>>>> $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
>>>> -kernel psxfenv01.exe
>>>> ==
>>>> .
>>>> .
>>>> .
>>>> .
>>>> Makefile.am
>>>> ==
>>>> + if TEST_psxfenv01
>>>> + psx_tests += psxfenv01
>>>> + psxfenv01_SOURCES = psxfenv01/init.c
>>>> + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
>>>> +   $(support_includes)
>>>> + psxfenv01_LDADD = -lm $(LDADD)
>>>> + endif
>>>> +
>>>> ==
>>>>
>>>> On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta 
>>>> wrote:
>>>>
>>>>> My code of testsuite:
>>>>> ===
>>>>>   /* Test 'FE_DIVBYZERO' */
>>>>>   puts( "\nDivide by zero and confirm fetestexcept()." );
>>>>>   a = 0.0;
>>>>>   b = 1.0;
>>>>>   c = b/a;
>>>>>   printf("\n%d",FE_DIVBYZERO);
>>>>>   fegetexceptflag(&excepts,FE_ALL_EXCEPT);
>>>>>   printf("\n%d",excepts);
>>>>>   r = feraiseexcept(FE_DIVBYZERO);
>>>>>   printf("\n%d\n",r);
>>>>>   rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
>>>>> ==
>>>>> OUTPUT
>>>>> ==
>>>>> Divide by zero and confirm fetestexcept().
>>>>>
>>>>> 8
>>>>> 0
>>>>> 1
>>>>> /home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
>>>>> 84 fetestexcept( FE_DIVBYZERO )
>>>>> ==
>>>>> EXPECTED OUTPUT
>>>>> ==
>>>>> Divide by zero and confirm fetestexcept().
>>>>>
>>>>> 8
>>>>> 8
>>>>> 0
>>>>> ==
>>>>> - fetestexcept( FE_DIVBYZERO ), should return a non-zero value as
>>>>> division-by-zero was performed.
>>>>> .
>>>>> - feraiseexcept(FE_DIVBYZERO); is also not working. It should return
>>>>> zero when successful
>>>>> .
>>>>> ==
>>>>>
>>>>> Thank You
>>>>> Vaibhav Gupta
>>>>>
>>>>> ___
>>>> devel mailing list
>>>> devel@rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV

[Vaibhav Gupta]

On Mon, Aug 12, 2019 at 11:50 PM Joel Sherrill  wrote:

> Can you post or email me privately the full patch? I can try to see what I
> spot.
>
I have sent you the patch.

>
> Can you check with objdump or gdb that the methods which don't appear to
> work
> are actually the RISC-V implementation? Look at the disassembly and see if
> it
> looks like you expect.
>
I am exploring for this.

- Vaibhav Gupta

>
> Does this require a patch to newlib as well?
>
> --joel
>
> On Sun, Aug 11, 2019 at 10:49 AM Vaibhav Gupta 
> wrote:
>
>> Configure command I used to build BSP:
>> ==
>> $ /home/varodek/development/rtems/kernel/rtems/configure
>> --prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
>> --target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
>> --enable-posix --disable-networking --enable-cxx RISCV_ENABLE_HTIF_SUPPORT=1
>> ==
>> .
>> .
>> .
>> .
>> Qemu command I used to run test:
>> ==
>> $ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M -kernel
>> psxfenv01.exe
>> ==
>> .
>> .
>> .
>> .
>> Makefile.am
>> ==
>> + if TEST_psxfenv01
>> + psx_tests += psxfenv01
>> + psxfenv01_SOURCES = psxfenv01/init.c
>> + psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
>> +   $(support_includes)
>> + psxfenv01_LDADD = -lm $(LDADD)
>> + endif
>> +
>> ==
>>
>> On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta 
>> wrote:
>>
>>> My code of testsuite:
>>> ===
>>>   /* Test 'FE_DIVBYZERO' */
>>>   puts( "\nDivide by zero and confirm fetestexcept()." );
>>>   a = 0.0;
>>>   b = 1.0;
>>>   c = b/a;
>>>   printf("\n%d",FE_DIVBYZERO);
>>>   fegetexceptflag(&excepts,FE_ALL_EXCEPT);
>>>   printf("\n%d",excepts);
>>>   r = feraiseexcept(FE_DIVBYZERO);
>>>   printf("\n%d\n",r);
>>>   rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
>>> ==
>>> OUTPUT
>>> ==
>>> Divide by zero and confirm fetestexcept().
>>>
>>> 8
>>> 0
>>> 1
>>> /home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
>>> 84 fetestexcept( FE_DIVBYZERO )
>>> ==
>>> EXPECTED OUTPUT
>>> ==
>>> Divide by zero and confirm fetestexcept().
>>>
>>> 8
>>> 8
>>> 0
>>> ==
>>> - fetestexcept( FE_DIVBYZERO ), should return a non-zero value as
>>> division-by-zero was performed.
>>> .
>>> - feraiseexcept(FE_DIVBYZERO); is also not working. It should return
>>> zero when successful
>>> .
>>> ==
>>>
>>> Thank You
>>> Vaibhav Gupta
>>>
>>> ___
>> 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: Not able to run riscv-rv32imac testsuites

[Vaibhav Gupta]

Okay. Thanks

On Mon, Aug 12, 2019 at 3:00 PM Hesham Almatary <
hesham.almat...@cl.cam.ac.uk> wrote:

> On Mon, 12 Aug 2019 at 03:55, Vaibhav Gupta 
> wrote:
> >
> >
> >
> > On Mon, Aug 12, 2019, 12:01 AM Hesham Almatary <
> hesham.almat...@cl.cam.ac.uk> wrote:
> >>
> >>
> >>
> >> On Sun, 11 Aug 2019 at 16:11, Vaibhav Gupta 
> wrote:
> >>>
> >>> But I am not able to run:
> >>>
> >>> qemu-system-riscv64 -no-reboot -nographic -machine virt -m 256M
> -kernel hello.exe
> >>>
> >>>
> >>> On Fri, Aug 9, 2019 at 2:53 PM Vaibhav Gupta 
> wrote:
> >>>>
> >>>> I was able to run rv32imac using
> >>>>
> >>>> qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
> -kernel hello.exe
> >>>
> >>> When I configured rv32imac BSP with RISCV_ENABLE_HTIF_SUPPORT=1, This
> >>
> >>
> >> RISCV_ENABLE_HTIF_SUPPORT is only needed if you’re running on Spike.
> >
> > Yeah, earlier i didn't use this parameter in configure. But when things
> were not working, I had to rebuilt BSP using it
> > And I used 'qemu-system-riscv64 -machine spike_v1.10...' but this too
> didn't worked.
> > .
> > .
> >>
> >> Which BSP are you building and running on QEMU?
> >
> > Both rv32imac and rv64imac.
> > I am able to run rv32imac but not rv64imac.
> >
> QEMU should be able to run "rv64imac_medany" and not "rv64imac". They
> have different DRAM_BASE and QEMU, AFAIK, only works with rv64*_medany
> which has 0x8000 as a DRAM_BASE.
>
> > - Vaibhav
> >>
> >>
> >>> command prevents qemu from quitting properly I guess.
> >>> As after showing output, cursor still blinks and I quit it using
> 'pkill -9 qemu'.
> >>>>
> >>>>
> >>>> On Tue, Aug 6, 2019 at 9:04 PM Vaibhav Gupta <
> vaibhavgupt...@gmail.com> wrote:
> >>>>>
> >>>>> Awesome, thanks!
> >>>>>
> >>>>> On Tue, Aug 6, 2019 at 8:50 PM Hesham Almatary <
> hesham.almat...@cl.cam.ac.uk> wrote:
> >>>>>>
> >>>>>> Hi Vaibhav,
> >>>>>>
> >>>>>> * I recommend you use rv64* because of a potential 32-bit HTIF
> issue on Spike.
> >>>>>> * Make sure you install Spike correctly [1] and it's in your path or
> >>>>>> also qemu-system-riscv* instead.
> >>>>>> * If you're building RTEMS for Spike (i.e., rv*_spike), make sure to
> >>>>>> add RISCV_ENABLE_HTIF_SUPPORT to your configure line [2] when you
> >>>>>> build RTEMS.
> >>>>>> * It might be easier to try rv64* on QEMU (i.e., no Spike) instead.
> >>>>>>
> >>>>>> [1] https://github.com/riscv/riscv-isa-sim
> >>>>>> [2]
> https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html
> >>>>>>
> >>>>>> On Tue, 6 Aug 2019 at 14:52, Vaibhav Gupta <
> vaibhavgupt...@gmail.com> wrote:
> >>>>>> >
> >>>>>> > I am getting following error:
> >>>>>> > .
> >>>>>> > .
> >>>>>> > $ rtems-test --rtems-bsp=rv32imac_spike
> --rtems-tools=$HOME/development/rtems/5
> ~/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples
> >>>>>> >
> >>>>>> > RTEMS Testing - Tester, 5.0.not_released
> >>>>>> >  Command Line: /home/varodek/development/rtems/5/bin/rtems-test
> --rtems-bsp=rv32imac_spike --rtems-tools=/home/varodek/development/rtems/5
> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples
> >>>>>> >  Host: Linux varodek 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20
> 15:00:46 UTC 2019 x86_64
> >>>>>> >  Python: 3.7.3 (default, Mar 26 2019, 21:43:19) [GCC 8.2.1
> 20181127]
> >>>>>> > Host: Linux-5.0.9-arch1-1-ARCH-x86_64-with-arch (Linux varodek
> 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20 15:00:46 UTC 2019 x86_64 )
> >>>>>> > [ 2/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
> riscv32/rv32imac: capture.exe
> >>>>>> > [ 3/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
> riscv32/rv32imac: cdtest.exe
> >>>>>> > [ 4/1

[PATCH v1] Add steps to test Newlib patch.

[Vaibhav Gupta]

Update the checksum to be used for the Newlib patches.
Earlier it was msd5, but it is depreciated for security
reasons. Now RSB accepts sha512.
---
 user/rsb/project-sets.rst | 41 +--
 1 file changed, 35 insertions(+), 6 deletions(-)

diff --git a/user/rsb/project-sets.rst b/user/rsb/project-sets.rst
index 5ffce26..b01857e 100644
--- a/user/rsb/project-sets.rst
+++ b/user/rsb/project-sets.rst
@@ -261,17 +261,46 @@ in the ``source-builder/config`` template configuration 
files.
 To test a patch simply copy it to your local ``patches`` directory. The RSB
 will see the patch is present and will not attempt to download it. Once you are
 happy with the patch submit it to the project and a core developer will review
-it and add it to the RTEMS Tools git repository.  For example, to test a local
-patch for newlib, add the following two lines to the .cfg file in
-``rtems/config/tools/`` that is included by the bset you use:
+it and add it to the RTEMS Tools git repository.
+
+Testing a Newlib Patch
+~~
+
+To test a local patch for newlib, you need to add the following
+two lines to the ``.cfg`` file in ``rsb/rtems/config/tools/`` that is included
+by the bset you use:
+
+.. topic:: Steps:
+
+  1. Create patches for the changes you want to test. (Note: For RSB, before
+ creating Newlib patch, you must run ``autoreconf -fvi`` in the required
+ directory after you make changes to the code. This is not required when
+ you create patch to send to ``newlib-devel``. But if you want RSB to 
+ address your changes, your patch should also include regenerated files.)
+
+  2. Calculate ``sha512`` of your patch.
+
+  3. Place the patches in ``rsb/rtems/patches`` directory.
+
+  4. Open the ``.bset`` file used by your BSP in ``rsb/rtems/config``.
+ For example, for ``rtems5``, ``SPARC``, the file will be
+ ``rsb/rtems/config/5/rtems-sparc.bset``.
+ 
+  5. Inside it you will find the name of ``.cfg`` file for Newlib, used by
+ your BSP.
+ For example, I found ``tools/rtems-gcc-7.4.0-newlib-1d35a003f``.
+ 
+  6. Edit your ``.cfg`` file. In my case it will be,
+ ``rsb/rtems/config/tools/rtems-gcc-7.4.0-newlib-1d35a003f.cfg``. And
+ add the information about your patch as mentioned below.
 
 .. code-block:: spec
 
-%patch add newlib file://0001-this-is-a-newlib-patch.patch   <1>
-%hash md5 0001-this-is-a-newlib-patch.diff 
77d070878112783292461bd6e7db17fb <2>
+%patch add newlib -p1 file://0001-Port-ndbm.patch <1>
+%hash sha512 0001-Port-ndbm.patch 
7d999ceeea4f3dc82e8e0aadc09d983a7a68b44470da8a3d61ab6fc558fdba6f2c2de3acc2f32c0b0b97fcc9ab799c27e87afe046544a69519881f947e7881d1
 <2>
 
 .. topic:: Items:
 
   1. The diff file prepended with ``file://`` to tell RSB this is a local file.
 
-  2. The output from md5sum on the diff file.
+  2. The output from sha512sum on the patch file.
-- 
2.21.0

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

[PATCH v1] Remove back-slash in 'pacman' command in 'PDF' section under Arch Linux (installation of Sphinx).

[Vaibhav Gupta]

---
 README.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.txt b/README.txt
index 3679d1d..1567be6 100644
--- a/README.txt
+++ b/README.txt
@@ -247,7 +247,7 @@ Sphinx:
 
 PDF:
 
-  # pacman -S texlive-bin texlive-core texlive-latexextra texlive-fontsextra \
+  # pacman -S texlive-bin texlive-core texlive-latexextra texlive-fontsextra
 
 openSUSE
 
-- 
2.21.0

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

Re: Not able to run riscv-rv32imac testsuites

[Vaibhav Gupta]

On Mon, Aug 12, 2019, 12:01 AM Hesham Almatary 
wrote:

>
>
> On Sun, 11 Aug 2019 at 16:11, Vaibhav Gupta 
> wrote:
>
>> But I am not able to run:
>>
>> qemu-system-riscv64 -no-reboot -nographic -machine virt -m 256M -kernel 
>> hello.exe
>>
>>
>> On Fri, Aug 9, 2019 at 2:53 PM Vaibhav Gupta 
>> wrote:
>>
>>> I was able to run rv32imac using
>>>
>>> qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M -kernel 
>>> hello.exe
>>>
>>> When I configured rv32imac BSP with RISCV_ENABLE_HTIF_SUPPORT=1, This
>>
>
> RISCV_ENABLE_HTIF_SUPPORT is only needed if you’re running on Spike.
>
Yeah, earlier i didn't use this parameter in configure. But when things
were not working, I had to rebuilt BSP using it
And I used 'qemu-system-riscv64 -machine spike_v1.10...' but this too
didn't worked.
.
.

> Which BSP are you building and running on QEMU?
>
Both rv32imac and rv64imac.
I am able to run rv32imac but not rv64imac.

- Vaibhav

>
> command prevents qemu from quitting properly I guess.
>> As after showing output, cursor still blinks and I quit it using 'pkill
>> -9 qemu'.
>>
>>>
>>> On Tue, Aug 6, 2019 at 9:04 PM Vaibhav Gupta 
>>> wrote:
>>>
>>>> Awesome, thanks!
>>>>
>>>> On Tue, Aug 6, 2019 at 8:50 PM Hesham Almatary <
>>>> hesham.almat...@cl.cam.ac.uk> wrote:
>>>>
>>>>> Hi Vaibhav,
>>>>>
>>>>> * I recommend you use rv64* because of a potential 32-bit HTIF issue
>>>>> on Spike.
>>>>> * Make sure you install Spike correctly [1] and it's in your path or
>>>>> also qemu-system-riscv* instead.
>>>>> * If you're building RTEMS for Spike (i.e., rv*_spike), make sure to
>>>>> add RISCV_ENABLE_HTIF_SUPPORT to your configure line [2] when you
>>>>> build RTEMS.
>>>>> * It might be easier to try rv64* on QEMU (i.e., no Spike) instead.
>>>>>
>>>>> [1] https://github.com/riscv/riscv-isa-sim
>>>>> [2] https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html
>>>>>
>>>>> On Tue, 6 Aug 2019 at 14:52, Vaibhav Gupta 
>>>>> wrote:
>>>>> >
>>>>> > I am getting following error:
>>>>> > .
>>>>> > .
>>>>> > $ rtems-test --rtems-bsp=rv32imac_spike
>>>>> --rtems-tools=$HOME/development/rtems/5
>>>>> ~/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples
>>>>> >
>>>>> > RTEMS Testing - Tester, 5.0.not_released
>>>>> >  Command Line: /home/varodek/development/rtems/5/bin/rtems-test
>>>>> --rtems-bsp=rv32imac_spike --rtems-tools=/home/varodek/development/rtems/5
>>>>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples
>>>>> >  Host: Linux varodek 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20
>>>>> 15:00:46 UTC 2019 x86_64
>>>>> >  Python: 3.7.3 (default, Mar 26 2019, 21:43:19) [GCC 8.2.1 20181127]
>>>>> > Host: Linux-5.0.9-arch1-1-ARCH-x86_64-with-arch (Linux varodek
>>>>> 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20 15:00:46 UTC 2019 x86_64 )
>>>>> > [ 2/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>>>>> riscv32/rv32imac: capture.exe
>>>>> > [ 3/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>>>>> riscv32/rv32imac: cdtest.exe
>>>>> > [ 4/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>>>>> riscv32/rv32imac: cxx_iostream.exe
>>>>> > [ 1/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>>>>> riscv32/rv32imac: base_sp.exe
>>>>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>>>>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/capture.exe:
>>>>> exit-code:2
>>>>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>>>>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/capture.exe:
>>>>> exit-code:2
>>>>> > warning: switched to dry run due to errors
>>>>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>>>>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cxx_iostream.exe:
>>>>>

Re: GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV

[Vaibhav Gupta]

Configure command I used to build BSP:
==
$ /home/varodek/development/rtems/kernel/rtems/configure
--prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
--target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
--enable-posix --disable-networking --enable-cxx RISCV_ENABLE_HTIF_SUPPORT=1
==
.
.
.
.
Qemu command I used to run test:
==
$ qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M -kernel
psxfenv01.exe
==
.
.
.
.
Makefile.am
==
+ if TEST_psxfenv01
+ psx_tests += psxfenv01
+ psxfenv01_SOURCES = psxfenv01/init.c
+ psxfenv01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxfenv01) \
+   $(support_includes)
+ psxfenv01_LDADD = -lm $(LDADD)
+ endif
+
==

On Sun, Aug 11, 2019 at 8:36 PM Vaibhav Gupta 
wrote:

> My code of testsuite:
> ===
>   /* Test 'FE_DIVBYZERO' */
>   puts( "\nDivide by zero and confirm fetestexcept()." );
>   a = 0.0;
>   b = 1.0;
>   c = b/a;
>   printf("\n%d",FE_DIVBYZERO);
>   fegetexceptflag(&excepts,FE_ALL_EXCEPT);
>   printf("\n%d",excepts);
>   r = feraiseexcept(FE_DIVBYZERO);
>   printf("\n%d\n",r);
>   rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
> ==
> OUTPUT
> ==
> Divide by zero and confirm fetestexcept().
>
> 8
> 0
> 1
> /home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
> 84 fetestexcept( FE_DIVBYZERO )
> ==
> EXPECTED OUTPUT
> ==
> Divide by zero and confirm fetestexcept().
>
> 8
> 8
> 0
> ==
> - fetestexcept( FE_DIVBYZERO ), should return a non-zero value as
> division-by-zero was performed.
> .
> - feraiseexcept(FE_DIVBYZERO); is also not working. It should return zero
> when successful
> .
> ==
>
> Thank You
> Vaibhav Gupta
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Not able to run riscv-rv32imac testsuites

[Vaibhav Gupta]

But I am not able to run:

qemu-system-riscv64 -no-reboot -nographic -machine virt -m 256M
-kernel hello.exe


On Fri, Aug 9, 2019 at 2:53 PM Vaibhav Gupta 
wrote:

> I was able to run rv32imac using
>
> qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M -kernel 
> hello.exe
>
> When I configured rv32imac BSP with RISCV_ENABLE_HTIF_SUPPORT=1, This
command prevents qemu from quitting properly I guess.
As after showing output, cursor still blinks and I quit it using 'pkill -9
qemu'.

>
> On Tue, Aug 6, 2019 at 9:04 PM Vaibhav Gupta 
> wrote:
>
>> Awesome, thanks!
>>
>> On Tue, Aug 6, 2019 at 8:50 PM Hesham Almatary <
>> hesham.almat...@cl.cam.ac.uk> wrote:
>>
>>> Hi Vaibhav,
>>>
>>> * I recommend you use rv64* because of a potential 32-bit HTIF issue on
>>> Spike.
>>> * Make sure you install Spike correctly [1] and it's in your path or
>>> also qemu-system-riscv* instead.
>>> * If you're building RTEMS for Spike (i.e., rv*_spike), make sure to
>>> add RISCV_ENABLE_HTIF_SUPPORT to your configure line [2] when you
>>> build RTEMS.
>>> * It might be easier to try rv64* on QEMU (i.e., no Spike) instead.
>>>
>>> [1] https://github.com/riscv/riscv-isa-sim
>>> [2] https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html
>>>
>>> On Tue, 6 Aug 2019 at 14:52, Vaibhav Gupta 
>>> wrote:
>>> >
>>> > I am getting following error:
>>> > .
>>> > .
>>> > $ rtems-test --rtems-bsp=rv32imac_spike
>>> --rtems-tools=$HOME/development/rtems/5
>>> ~/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples
>>> >
>>> > RTEMS Testing - Tester, 5.0.not_released
>>> >  Command Line: /home/varodek/development/rtems/5/bin/rtems-test
>>> --rtems-bsp=rv32imac_spike --rtems-tools=/home/varodek/development/rtems/5
>>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples
>>> >  Host: Linux varodek 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20
>>> 15:00:46 UTC 2019 x86_64
>>> >  Python: 3.7.3 (default, Mar 26 2019, 21:43:19) [GCC 8.2.1 20181127]
>>> > Host: Linux-5.0.9-arch1-1-ARCH-x86_64-with-arch (Linux varodek
>>> 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20 15:00:46 UTC 2019 x86_64 )
>>> > [ 2/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>>> riscv32/rv32imac: capture.exe
>>> > [ 3/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>>> riscv32/rv32imac: cdtest.exe
>>> > [ 4/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>>> riscv32/rv32imac: cxx_iostream.exe
>>> > [ 1/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>>> riscv32/rv32imac: base_sp.exe
>>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/capture.exe:
>>> exit-code:2
>>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/capture.exe:
>>> exit-code:2
>>> > warning: switched to dry run due to errors
>>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cxx_iostream.exe:
>>> exit-code:2
>>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cxx_iostream.exe:
>>> exit-code:2
>>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cdtest.exe:
>>> exit-code:2
>>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cdtest.exe:
>>> exit-code:2
>>> > warning: switched to dry run due to errors
>>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/base_sp.exe:
>>> exit-code:2
>>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/base_sp.exe:
>>> exit-code:2
>>> > warning: switched to dry run due to errors
>>> &g

GSoC 2019: POSIX Compliance - FENV Environment probably not working properly in RISCV

[Vaibhav Gupta]

My code of testsuite:
===
  /* Test 'FE_DIVBYZERO' */
  puts( "\nDivide by zero and confirm fetestexcept()." );
  a = 0.0;
  b = 1.0;
  c = b/a;
  printf("\n%d",FE_DIVBYZERO);
  fegetexceptflag(&excepts,FE_ALL_EXCEPT);
  printf("\n%d",excepts);
  r = feraiseexcept(FE_DIVBYZERO);
  printf("\n%d\n",r);
  rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
==
OUTPUT
==
Divide by zero and confirm fetestexcept().

8
0
1
/home/varodek/development/rtems/kernel/rtems/c/src/../../testsuites/psxtests/psxfenv01/init.c:
84 fetestexcept( FE_DIVBYZERO )
==
EXPECTED OUTPUT
==
Divide by zero and confirm fetestexcept().

8
8
0
==
- fetestexcept( FE_DIVBYZERO ), should return a non-zero value as
division-by-zero was performed.
.
- feraiseexcept(FE_DIVBYZERO); is also not working. It should return zero
when successful
.
======

Thank You
Vaibhav Gupta
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Not able to run riscv-rv32imac testsuites

[Vaibhav Gupta]

I was able to run rv32imac using

qemu-system-riscv32 -no-reboot -nographic -machine virt -m 256M
-kernel hello.exe


On Tue, Aug 6, 2019 at 9:04 PM Vaibhav Gupta 
wrote:

> Awesome, thanks!
>
> On Tue, Aug 6, 2019 at 8:50 PM Hesham Almatary <
> hesham.almat...@cl.cam.ac.uk> wrote:
>
>> Hi Vaibhav,
>>
>> * I recommend you use rv64* because of a potential 32-bit HTIF issue on
>> Spike.
>> * Make sure you install Spike correctly [1] and it's in your path or
>> also qemu-system-riscv* instead.
>> * If you're building RTEMS for Spike (i.e., rv*_spike), make sure to
>> add RISCV_ENABLE_HTIF_SUPPORT to your configure line [2] when you
>> build RTEMS.
>> * It might be easier to try rv64* on QEMU (i.e., no Spike) instead.
>>
>> [1] https://github.com/riscv/riscv-isa-sim
>> [2] https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html
>>
>> On Tue, 6 Aug 2019 at 14:52, Vaibhav Gupta 
>> wrote:
>> >
>> > I am getting following error:
>> > .
>> > .
>> > $ rtems-test --rtems-bsp=rv32imac_spike
>> --rtems-tools=$HOME/development/rtems/5
>> ~/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples
>> >
>> > RTEMS Testing - Tester, 5.0.not_released
>> >  Command Line: /home/varodek/development/rtems/5/bin/rtems-test
>> --rtems-bsp=rv32imac_spike --rtems-tools=/home/varodek/development/rtems/5
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples
>> >  Host: Linux varodek 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20
>> 15:00:46 UTC 2019 x86_64
>> >  Python: 3.7.3 (default, Mar 26 2019, 21:43:19) [GCC 8.2.1 20181127]
>> > Host: Linux-5.0.9-arch1-1-ARCH-x86_64-with-arch (Linux varodek
>> 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20 15:00:46 UTC 2019 x86_64 )
>> > [ 2/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>> riscv32/rv32imac: capture.exe
>> > [ 3/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>> riscv32/rv32imac: cdtest.exe
>> > [ 4/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>> riscv32/rv32imac: cxx_iostream.exe
>> > [ 1/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>> riscv32/rv32imac: base_sp.exe
>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/capture.exe:
>> exit-code:2
>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/capture.exe:
>> exit-code:2
>> > warning: switched to dry run due to errors
>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cxx_iostream.exe:
>> exit-code:2
>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cxx_iostream.exe:
>> exit-code:2
>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cdtest.exe:
>> exit-code:2
>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cdtest.exe:
>> exit-code:2
>> > warning: switched to dry run due to errors
>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/base_sp.exe:
>> exit-code:2
>> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/base_sp.exe:
>> exit-code:2
>> > warning: switched to dry run due to errors
>> > warning: switched to dry run due to errors
>> > [ 1/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>> riscv32/rv32imac: base_sp.exe
>> > Result: invalidTime: 0:00:00.032377 base_sp.exe
>> > =>  run: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/base_sp.exe
>> > [ 2/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>> riscv32/rv32imac: capture.exe
>> > Result: invalidTime: 0:00:00.037950 capture.exe
>> > =>  run: spike --isa=RV32IMAC
>> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/capture.exe
>> >

Re: Not able to run riscv-rv32imac testsuites

[Vaibhav Gupta]

Awesome, thanks!

On Tue, Aug 6, 2019 at 8:50 PM Hesham Almatary 
wrote:

> Hi Vaibhav,
>
> * I recommend you use rv64* because of a potential 32-bit HTIF issue on
> Spike.
> * Make sure you install Spike correctly [1] and it's in your path or
> also qemu-system-riscv* instead.
> * If you're building RTEMS for Spike (i.e., rv*_spike), make sure to
> add RISCV_ENABLE_HTIF_SUPPORT to your configure line [2] when you
> build RTEMS.
> * It might be easier to try rv64* on QEMU (i.e., no Spike) instead.
>
> [1] https://github.com/riscv/riscv-isa-sim
> [2] https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html
>
> On Tue, 6 Aug 2019 at 14:52, Vaibhav Gupta 
> wrote:
> >
> > I am getting following error:
> > .
> > .
> > $ rtems-test --rtems-bsp=rv32imac_spike
> --rtems-tools=$HOME/development/rtems/5
> ~/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples
> >
> > RTEMS Testing - Tester, 5.0.not_released
> >  Command Line: /home/varodek/development/rtems/5/bin/rtems-test
> --rtems-bsp=rv32imac_spike --rtems-tools=/home/varodek/development/rtems/5
> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples
> >  Host: Linux varodek 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20
> 15:00:46 UTC 2019 x86_64
> >  Python: 3.7.3 (default, Mar 26 2019, 21:43:19) [GCC 8.2.1 20181127]
> > Host: Linux-5.0.9-arch1-1-ARCH-x86_64-with-arch (Linux varodek
> 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20 15:00:46 UTC 2019 x86_64 )
> > [ 2/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv32/rv32imac:
> capture.exe
> > [ 3/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv32/rv32imac:
> cdtest.exe
> > [ 4/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv32/rv32imac:
> cxx_iostream.exe
> > [ 1/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv32/rv32imac:
> base_sp.exe
> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/capture.exe:
> exit-code:2
> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/capture.exe:
> exit-code:2
> > warning: switched to dry run due to errors
> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cxx_iostream.exe:
> exit-code:2
> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cxx_iostream.exe:
> exit-code:2
> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cdtest.exe:
> exit-code:2
> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cdtest.exe:
> exit-code:2
> > warning: switched to dry run due to errors
> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/base_sp.exe:
> exit-code:2
> > error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/base_sp.exe:
> exit-code:2
> > warning: switched to dry run due to errors
> > warning: switched to dry run due to errors
> > [ 1/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv32/rv32imac:
> base_sp.exe
> > Result: invalidTime: 0:00:00.032377 base_sp.exe
> > =>  run: spike --isa=RV32IMAC
> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/base_sp.exe
> > [ 2/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv32/rv32imac:
> capture.exe
> > Result: invalidTime: 0:00:00.037950 capture.exe
> > =>  run: spike --isa=RV32IMAC
> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/capture.exe
> > [ 3/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv32/rv32imac:
> cdtest.exe
> > Result: invalidTime: 0:00:00.038061 cdtest.exe
> > =>  run: spike --isa=RV32IMAC
> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cdtest.exe
> > [ 4/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv32/rv32imac:
> cxx_iostream.exe
> > Result: invalidTime: 0:00:00.034353 cxx_iostream.exe
> > =>  run: spike --isa=RV32IMAC
> /home/varodek/development/r

Re: Not able to run riscv-rv32imac testsuites

[Vaibhav Gupta]

I am getting following error:
.
.
$ rtems-test --rtems-bsp=rv32imac_spike
--rtems-tools=$HOME/development/rtems/5
~/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples

RTEMS Testing - Tester, 5.0.not_released
 Command Line: /home/varodek/development/rtems/5/bin/rtems-test
--rtems-bsp=rv32imac_spike --rtems-tools=/home/varodek/development/rtems/5
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples
 Host: Linux varodek 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20 15:00:46
UTC 2019 x86_64
 Python: 3.7.3 (default, Mar 26 2019, 21:43:19) [GCC 8.2.1 20181127]
Host: Linux-5.0.9-arch1-1-ARCH-x86_64-with-arch (Linux varodek
5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20 15:00:46 UTC 2019 x86_64 )
[ 2/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv32/rv32imac:
capture.exe
[ 3/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv32/rv32imac:
cdtest.exe
[ 4/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv32/rv32imac:
cxx_iostream.exe
[ 1/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv32/rv32imac:
base_sp.exe
error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/capture.exe:
exit-code:2
error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/capture.exe:
exit-code:2
warning: switched to dry run due to errors
error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cxx_iostream.exe:
exit-code:2
error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cxx_iostream.exe:
exit-code:2
error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cdtest.exe:
exit-code:2
error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cdtest.exe:
exit-code:2
warning: switched to dry run due to errors
error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/base_sp.exe:
exit-code:2
error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/base_sp.exe:
exit-code:2
warning: switched to dry run due to errors
warning: switched to dry run due to errors
[ 1/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv32/rv32imac:
base_sp.exe
Result: invalidTime: 0:00:00.032377 base_sp.exe
=>  run: spike --isa=RV32IMAC
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/base_sp.exe
[ 2/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv32/rv32imac:
capture.exe
Result: invalidTime: 0:00:00.037950 capture.exe
=>  run: spike --isa=RV32IMAC
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/capture.exe
[ 3/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv32/rv32imac:
cdtest.exe
Result: invalidTime: 0:00:00.038061 cdtest.exe
=>  run: spike --isa=RV32IMAC
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cdtest.exe
[ 4/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | riscv32/rv32imac:
cxx_iostream.exe
Result: invalidTime: 0:00:00.034353 cxx_iostream.exe
=>  run: spike --isa=RV32IMAC
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/cxx_iostream.exe
[ 7/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:4  W:0  | riscv32/rv32imac:
minimum.exe
[ 8/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:4  W:0  | riscv32/rv32imac:
nsecs.exe
[ 5/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:4  W:0  | riscv32/rv32imac:
fileio.exe
[ 6/11] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:4  W:0  | riscv32/rv32imac:
hello.exe
error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/minimum.exe:
exit-code:2
error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/minimum.exe:
exit-code:2
error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/nsecs.exe:
exit-code:2
error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/fileio.exe:
exit-code:2
error: spike.cfg:58: execute failed: spike --isa=RV32IMAC
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples/nsecs.exe:
exit-code:2
warning: switched to dry run du

Re: Not able to run riscv-rv32imac testsuites

[Vaibhav Gupta]

On Tue, Aug 6, 2019 at 2:36 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 06/08/2019 10:54, Vaibhav Gupta wrote:
> > Getting this error:
> > $ rtems-test --rtems-bsp=rv32imac
> > --rtems-tools=$HOME/development/rtems/5
> >
> ~/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples
> >
> > RTEMS Testing - Tester, 5.0.not_released
> >   Command Line: /home/varodek/development/rtems/5/bin/rtems-test
> > --rtems-bsp=rv32imac --rtems-tools=/home/varodek/development/rtems/5
> >
> /home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples
> >   Host: Linux varodek 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20
> > 15:00:46 UTC 2019 x86_64
> >   Python: 3.7.3 (default, Mar 26 2019, 21:43:19) [GCC 8.2.1 20181127]
> > Host: Linux-5.0.9-arch1-1-ARCH-x86_64-with-arch (Linux varodek
> > 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20 15:00:46 UTC 2019 x86_64 )
> > error: cannot find bsp configuration file: rv32imac.ini
>
> Ok, maybe you can try one of these:
>
> find -name '*rv*ini' | sort
>
Thanks, this worked.

> ./tester/rtems/testing/bsps/rv32iac_spike.ini
> ./tester/rtems/testing/bsps/rv32imac_spike.ini
> ./tester/rtems/testing/bsps/rv32imafc_spike.ini
> ./tester/rtems/testing/bsps/rv32imafdc_spike.ini
> ./tester/rtems/testing/bsps/rv32imafd_spike.ini
> ./tester/rtems/testing/bsps/rv32im_spike.ini
> ./tester/rtems/testing/bsps/rv32i_spike.ini
> ./tester/rtems/testing/bsps/rv64imac_medany_spike.ini
> ./tester/rtems/testing/bsps/rv64imac_spike.ini
> ./tester/rtems/testing/bsps/rv64imafdc_medany_spike.ini
> ./tester/rtems/testing/bsps/rv64imafdc_spike.ini
> ./tester/rtems/testing/bsps/rv64imafd_medany.ini
> ./tester/rtems/testing/bsps/rv64imafd_medany_spike.ini
> ./tester/rtems/testing/bsps/rv64imafd_spike.ini
>
> --
> 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: Not able to run riscv-rv32imac testsuites

[Vaibhav Gupta]

Getting this error:
$ rtems-test --rtems-bsp=rv32imac --rtems-tools=$HOME/development/rtems/5
~/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples

RTEMS Testing - Tester, 5.0.not_released
 Command Line: /home/varodek/development/rtems/5/bin/rtems-test
--rtems-bsp=rv32imac --rtems-tools=/home/varodek/development/rtems/5
/home/varodek/development/rtems/kernel/rv32imac/riscv-rtems5/c/rv32imac/testsuites/samples
 Host: Linux varodek 5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20 15:00:46
UTC 2019 x86_64
 Python: 3.7.3 (default, Mar 26 2019, 21:43:19) [GCC 8.2.1 20181127]
Host: Linux-5.0.9-arch1-1-ARCH-x86_64-with-arch (Linux varodek
5.0.9-arch1-1-ARCH #1 SMP PREEMPT Sat Apr 20 15:00:46 UTC 2019 x86_64 )
error: cannot find bsp configuration file: rv32imac.ini
.
.
I mentioned "--enable-tests " while configuration.
Moreover, I wanted to run a specific test like hello.exe, like
i do for sparc:
$ sparc-rtems-run ./hello.exe

Because i need to test my testsuite.

Vaibhav Gupta

On Tue, Aug 6, 2019 at 2:10 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 06/08/2019 10:33, Vaibhav Gupta wrote:
> > But when I am trying to run hello world testsuite:
> > $ riscv-rtems5-run ./hello.exe
>
> You have to use the RTEMS Tester, e.g.
>
> rtems-test --rtems-bsp=rv32imac
>
> --
> 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

Not able to run riscv-rv32imac testsuites

[Vaibhav Gupta]

Hello,
.
I build riscv tool chain using command:
$ ../source-builder/sb-set-builder
--prefix=/home/varodek/development/rtems/5 5/rtems-riscv
.
And then build the kernel using command:
$ /home/varodek/development/rtems/kernel/rtems/configure
--prefix=/home/varodek/development/rtems/5 --enable-maintainer-mode
--target=riscv-rtems5 --enable-rtemsbsp=rv32imac --enable-tests
--enable-posix --disable-networking --enable-cxx
.
.
But when I am trying to run hello world testsuite:
$ riscv-rtems5-run ./hello.exe
.
It seems that it is not responding, cursor just keeps on bliking and
nothing gets printed on my terminal.

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

Re: RISCV BSP

[Vaibhav Gupta]

On Fri, Aug 2, 2019 at 10:44 PM Gedare Bloom  wrote:

>  Seems you will need 2 more spike to cover the suggestion 32/64 and
> HW/SW FP?

Yes, moreover I will need good amount of guidance too.

> i also recommend you try the sis variant, for a bit more
> coverage.
>
Okay, I will do that.
For now I wanted to test my code for testsuite. Basic tests for now,
then can move to Floating Point Unit.

>
> On Fri, Aug 2, 2019 at 10:27 AM Vaibhav Gupta 
> wrote:
> >
> > Thanks a lot.
> > Then I will be working with "rv32imac" and "rv64imac"
> >
> > Vaibhav Gupta
> >
> > On Fri, Aug 2, 2019 at 1:33 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >>
> >> On 02/08/2019 09:50, Vaibhav Gupta wrote:
> >> > Hello,
> >> > I was about to test the testsuite code, need to confirm
> >> > on which RISCV BSP we are going to work?
> >> >
> >> > For example, for ARM I was asked for xilinx-zynq
> >> > So is there any specific one for riscv too, or should I build any of
> it?
> >>
> >> While you work on this, please review the documentation.
> >>
> >> https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html
> >>
> >> Feel free to send documentation patches. There is support for some
> >> RISC-V BSPs in the RTEMS Tester:
> >>
> >> ./tester/rtems/testing/bsps/griscv-sis.ini
> >> ./tester/rtems/testing/bsps/griscv.ini
> >> ./tester/rtems/testing/bsps/griscv-sis-cov.ini
> >> ./tester/rtems/testing/bsps/rv32imac_spike.ini
> >> ./tester/rtems/testing/bsps/rv64imafdc_spike.ini
> >> ./tester/rtems/testing/bsps/rv64imafd_spike.ini
> >> ./tester/rtems/testing/bsps/rv64imafd_medany.ini
> >> ./tester/rtems/testing/bsps/rv64imafd_medany_spike.ini
> >> ./tester/rtems/testing/bsps/rv32imafc_spike.ini
> >> ./tester/rtems/testing/bsps/rv32imafd_spike.ini
> >> ./tester/rtems/testing/bsps/rv64imac_medany_spike.ini
> >> ./tester/rtems/testing/bsps/rv32im_spike.ini
> >> ./tester/rtems/testing/bsps/rv64imac_spike.ini
> >> ./tester/rtems/testing/bsps/rv32imafdc_spike.ini
> >> ./tester/rtems/testing/bsps/rv32iac_spike.ini
> >> ./tester/rtems/testing/bsps/rv64imafdc_medany_spike.ini
> >> ./tester/rtems/testing/bsps/rv32i_spike.ini
> >> ./tester/rtems/testing/bsps/rv32imac_spike.ini
> >> ./tester/rtems/testing/bsps/rv64imafdc_spike.ini
> >> ./tester/rtems/testing/bsps/rv64imafd_spike.ini
> >> ./tester/rtems/testing/bsps/rv64imafd_medany.ini
> >> ./tester/rtems/testing/bsps/rv64imafd_medany_spike.ini
> >> ./tester/rtems/testing/bsps/rv32imafc_spike.ini
> >> ./tester/rtems/testing/bsps/rv32imafd_spike.ini
> >> ./tester/rtems/testing/bsps/rv64imac_medany_spike.ini
> >> ./tester/rtems/testing/bsps/rv32im_spike.ini
> >> ./tester/rtems/testing/bsps/rv64imac_spike.ini
> >> ./tester/rtems/testing/bsps/rv32imafdc_spike.ini
> >> ./tester/rtems/testing/bsps/rv32iac_spike.ini
> >> ./tester/rtems/testing/bsps/rv64imafdc_medany_spike.ini
> >> ./tester/rtems/testing/bsps/rv32i_spike.ini
> >>
> >> I would test on a 32-bit and 64-bit variant. Also with hardware FP and
> >> without.
> >>
> >> --
> >> 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: RISCV BSP

[Vaibhav Gupta]

Thanks a lot.
Then I will be working with "rv32imac" and "rv64imac"

Vaibhav Gupta

On Fri, Aug 2, 2019 at 1:33 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 02/08/2019 09:50, Vaibhav Gupta wrote:
> > Hello,
> > I was about to test the testsuite code, need to confirm
> > on which RISCV BSP we are going to work?
> >
> > For example, for ARM I was asked for xilinx-zynq
> > So is there any specific one for riscv too, or should I build any of it?
>
> While you work on this, please review the documentation.
>
> https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html
>
> Feel free to send documentation patches. There is support for some
> RISC-V BSPs in the RTEMS Tester:
>
> ./tester/rtems/testing/bsps/griscv-sis.ini
> ./tester/rtems/testing/bsps/griscv.ini
> ./tester/rtems/testing/bsps/griscv-sis-cov.ini
> ./tester/rtems/testing/bsps/rv32imac_spike.ini
> ./tester/rtems/testing/bsps/rv64imafdc_spike.ini
> ./tester/rtems/testing/bsps/rv64imafd_spike.ini
> ./tester/rtems/testing/bsps/rv64imafd_medany.ini
> ./tester/rtems/testing/bsps/rv64imafd_medany_spike.ini
> ./tester/rtems/testing/bsps/rv32imafc_spike.ini
> ./tester/rtems/testing/bsps/rv32imafd_spike.ini
> ./tester/rtems/testing/bsps/rv64imac_medany_spike.ini
> ./tester/rtems/testing/bsps/rv32im_spike.ini
> ./tester/rtems/testing/bsps/rv64imac_spike.ini
> ./tester/rtems/testing/bsps/rv32imafdc_spike.ini
> ./tester/rtems/testing/bsps/rv32iac_spike.ini
> ./tester/rtems/testing/bsps/rv64imafdc_medany_spike.ini
> ./tester/rtems/testing/bsps/rv32i_spike.ini
> ./tester/rtems/testing/bsps/rv32imac_spike.ini
> ./tester/rtems/testing/bsps/rv64imafdc_spike.ini
> ./tester/rtems/testing/bsps/rv64imafd_spike.ini
> ./tester/rtems/testing/bsps/rv64imafd_medany.ini
> ./tester/rtems/testing/bsps/rv64imafd_medany_spike.ini
> ./tester/rtems/testing/bsps/rv32imafc_spike.ini
> ./tester/rtems/testing/bsps/rv32imafd_spike.ini
> ./tester/rtems/testing/bsps/rv64imac_medany_spike.ini
> ./tester/rtems/testing/bsps/rv32im_spike.ini
> ./tester/rtems/testing/bsps/rv64imac_spike.ini
> ./tester/rtems/testing/bsps/rv32imafdc_spike.ini
> ./tester/rtems/testing/bsps/rv32iac_spike.ini
> ./tester/rtems/testing/bsps/rv64imafdc_medany_spike.ini
> ./tester/rtems/testing/bsps/rv32i_spike.ini
>
> I would test on a 32-bit and 64-bit variant. Also with hardware FP and
> without.
>
> --
> 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

RISCV BSP

[Vaibhav Gupta]

Hello,
I was about to test the testsuite code, need to confirm
on which RISCV BSP we are going to work?

For example, for ARM I was asked for xilinx-zynq
So is there any specific one for riscv too, or should I build any of it?

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

Re: GSoC 2019 : POSIX Compliance - Weekly Report

[Vaibhav Gupta]

On Tue, Jul 30, 2019 at 7:23 PM Joel Sherrill  wrote:

>
>
> On Tue, Jul 30, 2019 at 7:44 AM Vaibhav Gupta 
> wrote:
>
>>
>>
>> On Tue, Jul 30, 2019 at 3:25 AM Gedare Bloom  wrote:
>>
>>> On Wed, Jul 24, 2019 at 10:43 AM Vaibhav Gupta 
>>> wrote:
>>> >
>>> > Hello,
>>> > Progress so far:
>>> > - NDBM patch is pushed by newlib.
>>> > - NDBM Testsuite is sent to devel ([PATCH V6] ndbm test suite), its
>>> execution will be verified once newlib has required files. Although I have
>>> tested it by manually generating required file using 'autoreconf -fvi' on
>>> my local system.
>>> >
>>> > Blocker:
>>> > - My pace got slow last week as my college started, I informed about
>>> it on devel.
>>> >
>>> > Next:
>>> > - Implement fenv for SPARC first, then move on to ARM, PPC and others.
>>> >
>>> What about fenv testcase?
>>>
>> I guess after Joel had a discussion in newlib, we will be switching code
>> structure for fenv, so implementation of riscv will also need to be
>> updated.
>> .
>> Hence, I will implement fenv for SPARC and make test case for same.
>>
>
> The test case can be added now if you have a RISC-V toolchain.  I expect
> the test code will
> have to be conditionalized on whether the target architecture supports the
> fenv.h methods.
> This would be best implemented with  like AC_CHECK_FUNC and pick a method
> like
> fegetround() to probe for.
>
Or I can use AC_CHECK_HEADER like you used for NDBM Testsuite.

> That way as you add support for other architectures, the test(s)
> will automatically get enabled.
>
> The alternative is like how libdebugger tests have to list specific
> architectures that are
> supported. That requires manual intervention (but is the only option for
> libdebugger).
>
>>
>> -Vaibhav Gupta
>>
>>>
>>> >
>>> > Thank You
>>> > Vaibhav Gupta
>>> > ___
>>> > 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: GSoC 2019 : POSIX Compliance - Weekly Report

[Vaibhav Gupta]

On Tue, Jul 30, 2019 at 8:49 PM Joel Sherrill  wrote:

>
>
> On Tue, Jul 30, 2019 at 10:15 AM Vaibhav Gupta 
> wrote:
>
>>
>>
>> On Tue, Jul 30, 2019 at 7:23 PM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Tue, Jul 30, 2019 at 7:44 AM Vaibhav Gupta 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jul 30, 2019 at 3:25 AM Gedare Bloom  wrote:
>>>>
>>>>> On Wed, Jul 24, 2019 at 10:43 AM Vaibhav Gupta <
>>>>> vaibhavgupt...@gmail.com> wrote:
>>>>> >
>>>>> > Hello,
>>>>> > Progress so far:
>>>>> > - NDBM patch is pushed by newlib.
>>>>> > - NDBM Testsuite is sent to devel ([PATCH V6] ndbm test suite), its
>>>>> execution will be verified once newlib has required files. Although I have
>>>>> tested it by manually generating required file using 'autoreconf -fvi' on
>>>>> my local system.
>>>>> >
>>>>> > Blocker:
>>>>> > - My pace got slow last week as my college started, I informed about
>>>>> it on devel.
>>>>> >
>>>>> > Next:
>>>>> > - Implement fenv for SPARC first, then move on to ARM, PPC and
>>>>> others.
>>>>> >
>>>>> What about fenv testcase?
>>>>>
>>>> I guess after Joel had a discussion in newlib, we will be switching code
>>>> structure for fenv, so implementation of riscv will also need to be
>>>> updated.
>>>> .
>>>> Hence, I will implement fenv for SPARC and make test case for same.
>>>>
>>>
>>> The test case can be added now if you have a RISC-V toolchain.  I expect
>>> the test code will
>>> have to be conditionalized on whether the target architecture supports
>>> the fenv.h methods.
>>>
>> Okay then I will start working on testsuite, I will build riscv
>> toolchain.
>>
>>> This would be best implemented with  like AC_CHECK_FUNC and pick a
>>> method like
>>> fegetround() to probe for.
>>>
>> You mentioned that you have pushed NDBM testsuite in a conditional way on
>> your branch,
>> that will make testsuite compile only if ndbm tools are present. Can I
>> get that code?
>> It will be helpful for me.
>>
>
> Sorry. I posted to devel@ but forgot to push. I just pushed it.
>
No problem, Thanks :)!

>
> --joel
>
>
>> - Vaibhav Gupta
>>
>>> That way as you add support for other architectures, the test(s)
>>> will automatically get enabled.
>>>
>>> The alternative is like how libdebugger tests have to list specific
>>> architectures that are
>>> supported. That requires manual intervention (but is the only option for
>>> libdebugger).
>>>
>>>>
>>>> -Vaibhav Gupta
>>>>
>>>>>
>>>>> >
>>>>> > Thank You
>>>>> > Vaibhav Gupta
>>>>> > ___
>>>>> > 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: GSoC 2019 : POSIX Compliance - Weekly Report

[Vaibhav Gupta]

On Tue, Jul 30, 2019 at 7:23 PM Joel Sherrill  wrote:

>
>
> On Tue, Jul 30, 2019 at 7:44 AM Vaibhav Gupta 
> wrote:
>
>>
>>
>> On Tue, Jul 30, 2019 at 3:25 AM Gedare Bloom  wrote:
>>
>>> On Wed, Jul 24, 2019 at 10:43 AM Vaibhav Gupta 
>>> wrote:
>>> >
>>> > Hello,
>>> > Progress so far:
>>> > - NDBM patch is pushed by newlib.
>>> > - NDBM Testsuite is sent to devel ([PATCH V6] ndbm test suite), its
>>> execution will be verified once newlib has required files. Although I have
>>> tested it by manually generating required file using 'autoreconf -fvi' on
>>> my local system.
>>> >
>>> > Blocker:
>>> > - My pace got slow last week as my college started, I informed about
>>> it on devel.
>>> >
>>> > Next:
>>> > - Implement fenv for SPARC first, then move on to ARM, PPC and others.
>>> >
>>> What about fenv testcase?
>>>
>> I guess after Joel had a discussion in newlib, we will be switching code
>> structure for fenv, so implementation of riscv will also need to be
>> updated.
>> .
>> Hence, I will implement fenv for SPARC and make test case for same.
>>
>
> The test case can be added now if you have a RISC-V toolchain.  I expect
> the test code will
> have to be conditionalized on whether the target architecture supports the
> fenv.h methods.
>
Okay then I will start working on testsuite, I will build riscv toolchain.

> This would be best implemented with  like AC_CHECK_FUNC and pick a method
> like
> fegetround() to probe for.
>
You mentioned that you have pushed NDBM testsuite in a conditional way on
your branch,
that will make testsuite compile only if ndbm tools are present. Can I get
that code?
It will be helpful for me.
- Vaibhav Gupta

> That way as you add support for other architectures, the test(s)
> will automatically get enabled.
>
> The alternative is like how libdebugger tests have to list specific
> architectures that are
> supported. That requires manual intervention (but is the only option for
> libdebugger).
>
>>
>> -Vaibhav Gupta
>>
>>>
>>> >
>>> > Thank You
>>> > Vaibhav Gupta
>>> > ___
>>> > 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: GSoC 2019 : POSIX Compliance - Weekly Report

[Vaibhav Gupta]

On Tue, Jul 30, 2019 at 3:25 AM Gedare Bloom  wrote:

> On Wed, Jul 24, 2019 at 10:43 AM Vaibhav Gupta 
> wrote:
> >
> > Hello,
> > Progress so far:
> > - NDBM patch is pushed by newlib.
> > - NDBM Testsuite is sent to devel ([PATCH V6] ndbm test suite), its
> execution will be verified once newlib has required files. Although I have
> tested it by manually generating required file using 'autoreconf -fvi' on
> my local system.
> >
> > Blocker:
> > - My pace got slow last week as my college started, I informed about it
> on devel.
> >
> > Next:
> > - Implement fenv for SPARC first, then move on to ARM, PPC and others.
> >
> What about fenv testcase?
>
I guess after Joel had a discussion in newlib, we will be switching code
structure for fenv, so implementation of riscv will also need to be updated.
.
Hence, I will implement fenv for SPARC and make test case for same.

-Vaibhav Gupta

>
> >
> > Thank You
> > Vaibhav Gupta
> > ___
> > 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 v6] ndbm test suite

[Vaibhav Gupta]

On Tue, Jul 30, 2019 at 12:11 AM Joel Sherrill  wrote:

>
>
> On Mon, Jul 29, 2019 at 1:07 PM Vaibhav Gupta 
> wrote:
>
>>
>>
>> On Mon, Jul 29, 2019 at 10:44 PM Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Mon, Jul 29, 2019 at 11:35 AM Vaibhav Gupta 
>>> wrote:
>>>
>>>> Thanks Joel!
>>>> .
>>>> Now when the testsuite patch is successfully accepted, I would like
>>>> to add an example in:
>>>> https://devel.rtems.org/wiki/Developer/Coding/80_characters_per_line,
>>>> about wrapping a "function call" in "80 characters per line".
>>>>
>>>
>>> Pull. I pushed the test. It just won't get built unless your toolset has
>>> ndbm.h
>>>
>>> Thanks
>>
>>> This sounds like helpful guidance.
>>>
>>> What's next for fenv?
>>>
>> I am following what You and Gedare suggested me. I won't directly import
>> fenv files,
>> as sources are mixed (FreeBSD and NetBSD), I am trying to unify them.
>>
>
> One newlib patch per architecture even if you are merging implementations.
>
>
>> .
>> I will be approaching in this manner:
>>
>>1. I will make a header file `libc/include/fenv.h`. All function
>>definitons will be mentioned. All definitons/macros which are architecture
>>specific will be kept between  #if /  #elif  /  #else  directives.
>>
>>
> Avoid adding if's to the main fenv.h if you are doing bodies of the
> implementation. As one example, RISC-V has its own fenv.h in
> libc/machine/riscv/include and bodies of the methods in libm/machine/riscv.
>
Okay.

>
>  fenv.h looks to be portable if sys/fenv.h is "machine" dependent. Your
> if's could be factored out into machine/ARCH/include/fenv.h. Then the
> portable method prototypes are in libc/include/fenv.h.
>
> Let me ask about that on the newlib list.
>
Yeah, I saw your mail on newlib just now, So you are proposing same
structure as followed by
NetBSD. They too have general fenv.h present in incliude :
https://github.com/NetBSD/src/blob/trunk/include/fenv.h
and a minimal working header which is architecture dependent.:
https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h
.
I wasn't sure if this approach can applied in newlib too, so I was going
for if's directive thing.

Thanks
Vaibhav Gupta

>
>
>>
>>1. Make architecture specific folders where I will Place   `fenv.c`
>>files.
>>
>>
>
>
>> - Vaibhav  Gupta
>>
>>>
>>>
>>>> .
>>>> Gedare and me discussed about it on a thread. That time he guided me
>>>> for this
>>>> as there is no example about in on the trac pag.
>>>> .
>>>> Vaibhav Gupta
>>>>
>>>>
>>>> On Mon, Jul 29, 2019 at 9:33 PM Joel Sherrill  wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> Now pushed. Thanks.
>>>>>
>>>>> I finally got a local sparc tool chain built with the git master of
>>>>> newlib to build and run this test. It was a bit more complicated than I
>>>>> expected.
>>>>>
>>>>> I did add a bit of logic to the psxtests configure.ac and Makefile.am
>>>>> to ensure the test was not built unless the toolset included . 
>>>>> This
>>>>> ensures that builds don't break when the toolset doesn't include it and
>>>>> that git bisect will continue to work.
>>>>>
>>>>> The RSB will need to be bumped to the git master once the github
>>>>> mirror updates to include my push to libm.
>>>>>
>>>>> On Thu, Jul 25, 2019 at 2:34 PM Joel Sherrill  wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> I just wanted to let everyone know that I have this pending on a
>>>>>> branch and can build it using the current but there is a problem linking
>>>>>> libm on the newlib git master. Once I have the RSB updated, I will look 
>>>>>> at
>>>>>> pushing this.
>>>>>>
>>>>>> To let Vaibhav continue pushing on fenv, if we decide the
>>>>>> configure.ac should check for the newly added dbm methods before
>>>>>> building the test, I will merge that into the patch.
>>>>>>
>>>>>> --joel
>>>>>>
>>>>>> On Tue, Jul

Re: [PATCH v6] ndbm test suite

[Vaibhav Gupta]

On Mon, Jul 29, 2019 at 10:44 PM Joel Sherrill  wrote:

>
>
> On Mon, Jul 29, 2019 at 11:35 AM Vaibhav Gupta 
> wrote:
>
>> Thanks Joel!
>> .
>> Now when the testsuite patch is successfully accepted, I would like
>> to add an example in:
>> https://devel.rtems.org/wiki/Developer/Coding/80_characters_per_line,
>> about wrapping a "function call" in "80 characters per line".
>>
>
> Pull. I pushed the test. It just won't get built unless your toolset has
> ndbm.h
>
> Thanks

> This sounds like helpful guidance.
>
> What's next for fenv?
>
I am following what You and Gedare suggested me. I won't directly import
fenv files,
as sources are mixed (FreeBSD and NetBSD), I am trying to unify them.
.
I will be approaching in this manner:

   1. I will make a header file `libc/include/fenv.h`. All function
   definitons will be mentioned. All definitons/macros which are architecture
   specific will be kept between  #if /  #elif  /  #else  directives.
   2. Make architecture specific folders where I will Place   `fenv.c`
   files.

- Vaibhav  Gupta

>
>
>> .
>> Gedare and me discussed about it on a thread. That time he guided me for
>> this
>> as there is no example about in on the trac pag.
>> .
>> Vaibhav Gupta
>>
>>
>> On Mon, Jul 29, 2019 at 9:33 PM Joel Sherrill  wrote:
>>
>>> Hi
>>>
>>> Now pushed. Thanks.
>>>
>>> I finally got a local sparc tool chain built with the git master of
>>> newlib to build and run this test. It was a bit more complicated than I
>>> expected.
>>>
>>> I did add a bit of logic to the psxtests configure.ac and Makefile.am
>>> to ensure the test was not built unless the toolset included . This
>>> ensures that builds don't break when the toolset doesn't include it and
>>> that git bisect will continue to work.
>>>
>>> The RSB will need to be bumped to the git master once the github mirror
>>> updates to include my push to libm.
>>>
>>> On Thu, Jul 25, 2019 at 2:34 PM Joel Sherrill  wrote:
>>>
>>>> Hi
>>>>
>>>> I just wanted to let everyone know that I have this pending on a branch
>>>> and can build it using the current but there is a problem linking libm on
>>>> the newlib git master. Once I have the RSB updated, I will look at pushing
>>>> this.
>>>>
>>>> To let Vaibhav continue pushing on fenv, if we decide the configure.ac
>>>> should check for the newly added dbm methods before building the test, I
>>>> will merge that into the patch.
>>>>
>>>> --joel
>>>>
>>>> On Tue, Jul 23, 2019 at 8:42 AM Vaibhav Gupta 
>>>> wrote:
>>>>
>>>>> ---
>>>>>  testsuites/psxtests/Makefile.am |   9 +
>>>>>  testsuites/psxtests/configure.ac|   1 +
>>>>>  testsuites/psxtests/psxndbm01/init.c| 299 
>>>>>  testsuites/psxtests/psxndbm01/psxndbm01.doc |  36 +++
>>>>>  testsuites/psxtests/psxndbm01/psxndbm01.scn |  29 ++
>>>>>  5 files changed, 374 insertions(+)
>>>>>  create mode 100644 testsuites/psxtests/psxndbm01/init.c
>>>>>  create mode 100644 testsuites/psxtests/psxndbm01/psxndbm01.doc
>>>>>  create mode 100644 testsuites/psxtests/psxndbm01/psxndbm01.scn
>>>>>
>>>>> diff --git a/testsuites/psxtests/Makefile.am
>>>>> b/testsuites/psxtests/Makefile.am
>>>>> index 59c9f2085b..36da591ccc 100755
>>>>> --- a/testsuites/psxtests/Makefile.am
>>>>> +++ b/testsuites/psxtests/Makefile.am
>>>>> @@ -694,6 +694,15 @@ psxmutexattr01_CPPFLAGS = $(AM_CPPFLAGS)
>>>>> $(TEST_FLAGS_psxmutexattr01) \
>>>>> $(support_includes) -I$(top_srcdir)/include
>>>>>  endif
>>>>>
>>>>> +if TEST_psxndbm01
>>>>> +psx_tests += psxndbm01
>>>>> +psx_screens += psxndbm01/psxndbm01.scn
>>>>> +psx_docs += psxndbm01/psxndbm01.doc
>>>>> +psxndbm01_SOURCES = psxndbm01/init.c
>>>>> +psxndbm01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxndbm01) \
>>>>> +   $(support_includes)
>>>>> +endif
>>>>> +
>>>>>  if TEST_psxobj01
>>>>>  psx_tests += psxobj01
>>>>>  psx_screens += psxobj01/psxobj01.scn
>>>>> diff --git a/testsuites/psxtes

Re: [PATCH v6] ndbm test suite

[Vaibhav Gupta]

Thanks Joel!
.
Now when the testsuite patch is successfully accepted, I would like
to add an example in:
https://devel.rtems.org/wiki/Developer/Coding/80_characters_per_line,
about wrapping a "function call" in "80 characters per line".
.
Gedare and me discussed about it on a thread. That time he guided me for
this
as there is no example about in on the trac pag.
.
Vaibhav Gupta


On Mon, Jul 29, 2019 at 9:33 PM Joel Sherrill  wrote:

> Hi
>
> Now pushed. Thanks.
>
> I finally got a local sparc tool chain built with the git master of newlib
> to build and run this test. It was a bit more complicated than I expected.
>
> I did add a bit of logic to the psxtests configure.ac and Makefile.am to
> ensure the test was not built unless the toolset included . This
> ensures that builds don't break when the toolset doesn't include it and
> that git bisect will continue to work.
>
> The RSB will need to be bumped to the git master once the github mirror
> updates to include my push to libm.
>
> On Thu, Jul 25, 2019 at 2:34 PM Joel Sherrill  wrote:
>
>> Hi
>>
>> I just wanted to let everyone know that I have this pending on a branch
>> and can build it using the current but there is a problem linking libm on
>> the newlib git master. Once I have the RSB updated, I will look at pushing
>> this.
>>
>> To let Vaibhav continue pushing on fenv, if we decide the configure.ac
>> should check for the newly added dbm methods before building the test, I
>> will merge that into the patch.
>>
>> --joel
>>
>> On Tue, Jul 23, 2019 at 8:42 AM Vaibhav Gupta 
>> wrote:
>>
>>> ---
>>>  testsuites/psxtests/Makefile.am |   9 +
>>>  testsuites/psxtests/configure.ac|   1 +
>>>  testsuites/psxtests/psxndbm01/init.c| 299 
>>>  testsuites/psxtests/psxndbm01/psxndbm01.doc |  36 +++
>>>  testsuites/psxtests/psxndbm01/psxndbm01.scn |  29 ++
>>>  5 files changed, 374 insertions(+)
>>>  create mode 100644 testsuites/psxtests/psxndbm01/init.c
>>>  create mode 100644 testsuites/psxtests/psxndbm01/psxndbm01.doc
>>>  create mode 100644 testsuites/psxtests/psxndbm01/psxndbm01.scn
>>>
>>> diff --git a/testsuites/psxtests/Makefile.am
>>> b/testsuites/psxtests/Makefile.am
>>> index 59c9f2085b..36da591ccc 100755
>>> --- a/testsuites/psxtests/Makefile.am
>>> +++ b/testsuites/psxtests/Makefile.am
>>> @@ -694,6 +694,15 @@ psxmutexattr01_CPPFLAGS = $(AM_CPPFLAGS)
>>> $(TEST_FLAGS_psxmutexattr01) \
>>> $(support_includes) -I$(top_srcdir)/include
>>>  endif
>>>
>>> +if TEST_psxndbm01
>>> +psx_tests += psxndbm01
>>> +psx_screens += psxndbm01/psxndbm01.scn
>>> +psx_docs += psxndbm01/psxndbm01.doc
>>> +psxndbm01_SOURCES = psxndbm01/init.c
>>> +psxndbm01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxndbm01) \
>>> +   $(support_includes)
>>> +endif
>>> +
>>>  if TEST_psxobj01
>>>  psx_tests += psxobj01
>>>  psx_screens += psxobj01/psxobj01.scn
>>> diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/
>>> configure.ac
>>> index 85559e4aa5..07d7ccaf55 100644
>>> --- a/testsuites/psxtests/configure.ac
>>> +++ b/testsuites/psxtests/configure.ac
>>> @@ -110,6 +110,7 @@ RTEMS_TEST_CHECK([psxmsgq02])
>>>  RTEMS_TEST_CHECK([psxmsgq03])
>>>  RTEMS_TEST_CHECK([psxmsgq04])
>>>  RTEMS_TEST_CHECK([psxmutexattr01])
>>> +RTEMS_TEST_CHECK([psxndbm01])
>>>  RTEMS_TEST_CHECK([psxobj01])
>>>  RTEMS_TEST_CHECK([psxonce01])
>>>  RTEMS_TEST_CHECK([psxpasswd01])
>>> diff --git a/testsuites/psxtests/psxndbm01/init.c
>>> b/testsuites/psxtests/psxndbm01/init.c
>>> new file mode 100644
>>> index 00..a1eff4bd67
>>> --- /dev/null
>>> +++ b/testsuites/psxtests/psxndbm01/init.c
>>> @@ -0,0 +1,299 @@
>>> +/**
>>> + *  @file
>>> + *  @brief Test suite for ndbm.h methods
>>> + */
>>> +
>>> +/*
>>> + * SPDX-License-Identifier: BSD-2-Clause
>>> + *
>>> + * Copyright (C) 2019 Vaibhav Gupta
>>> + *
>>> + * 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. Redistributio

Re: newlib ndbm documentation

[Vaibhav Gupta]

On Tue, Jul 23, 2019, 8:57 PM Joel Sherrill  wrote:

> Hi
>
> Just a note to remind you that we need to find a way to get the ndbm
> documentation into newlib. Since they put a marked up man page at the top
> of the .c file, I expect there are only two choices.
>
> (1) Put it at the top of ndbm.c as expected
> (2) Leave ndbm.c as found and add ndbm_doc.c
>
> As much as I don't like modifying a standard merged file, I suspect (1) is
> more acceptable to the newlib community.
>
> In both solutions, the contents of this file have to be converted to
> newlib markup.
>
> https://github.com/freebsd/freebsd/blob/master/lib/libc/db/man/dbm.3
>
> Thoughts
>
Let's move with 1st option. I will need to find about this method and
newlib markup. I will send a patch on devel for verification.

Vaibhav Gupta

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

Re: GSoC 2019 : POSIX Compliance- Low pace in last week

[Vaibhav Gupta]

On Wed, Jul 24, 2019, 9:44 PM Joel Sherrill  wrote:

> Hi
>
> I have some progress to report on this. The ndbm patch is in newlib git
> now but
> the corresponding files were not regenerated. Once Corinna pushes those, I
> will
> test and bump the newlib version in the tools.
>
Corinna just did it. :), Thanks for mentioning this thing on that thread.

>
> I see you have a test posted and once I have tools, I will be able to
> review that
> properly.
>
> How is the fenv test going? And what's the list of targets missing fenv
> support
> in newlib that you have found code for?
>
> --joel
>
> On Wed, Jul 24, 2019 at 10:56 AM Vaibhav Gupta 
> wrote:
>
>> Hello,
>> I want to apologise that I couldn't inform earlier, actually my time
>> table got hectic.
>> My college started last week and their initial time table is not much
>> useful in terms of productivity. Hence my pace got slow last week.
>>
>> I am back on track and continuing with my fenv task.
>>
>> Thank you
>> Vaibhav Gupta
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC 2019 : POSIX Compliance - Weekly Report

[Vaibhav Gupta]

Hello,
Progress so far:
- NDBM patch is pushed by newlib.
- NDBM Testsuite is sent to devel ([PATCH V6] ndbm test suite), its
execution will be verified once newlib has required files. Although I have
tested it by manually generating required file using 'autoreconf -fvi' on
my local system.

Blocker:
- My pace got slow last week as my college started, I informed about it on
devel.

Next:
- Implement fenv for SPARC first, then move on to ARM, PPC and others.


Thank You
Vaibhav Gupta
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2019 : POSIX Compliance- Low pace in last week

[Vaibhav Gupta]

On Wed, Jul 24, 2019 at 9:44 PM Joel Sherrill  wrote:

> Hi
>
> I have some progress to report on this. The ndbm patch is in newlib git
> now but
> the corresponding files were not regenerated. Once Corinna pushes those, I
> will
> test and bump the newlib version in the tools.
>
Thanks, Yah I saw the mail today. The path is pushed, I am also waiting for
regenerated file, Or else will have pull the current update and regenerae
the files using 'autoreconf -fvi'.

>
> I see you have a test posted and once I have tools, I will be able to
> review that
> properly.
>
Yes, and Gedare has verified the code for now, but its execution needs to be
verified once newlib has the update.

>
> How is the fenv test going? And what's the list of targets missing fenv
> support
> in newlib that you have found code for?
>
There are two approach I found:

   1. I saw in NetBSD, they have one general 'fenv.h' which is present in
   their include directory (This contains function prototypes). And one
   'fenv.h' is present in evry architecture specific folders(They contain
   architecture specific macros). We can implement it in similar way. When
   they are compiled, the 'include/fenv.h' and '/fenv.h' gets
   combined i guess.
   2. Or we can have only architecture specific headers which contain
   function prototypes and macros in one single file for every architecture.


> --joel
>
> On Wed, Jul 24, 2019 at 10:56 AM Vaibhav Gupta 
> wrote:
>
>> Hello,
>> I want to apologise that I couldn't inform earlier, actually my time
>> table got hectic.
>> My college started last week and their initial time table is not much
>> useful in terms of productivity. Hence my pace got slow last week.
>>
>> I am back on track and continuing with my fenv task.
>>
>> Thank you
>> Vaibhav Gupta
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC 2019 : POSIX Compliance- Low pace in last week

[Vaibhav Gupta]

Hello,
I want to apologise that I couldn't inform earlier, actually my time table
got hectic.
My college started last week and their initial time table is not much
useful in terms of productivity. Hence my pace got slow last week.

I am back on track and continuing with my fenv task.

Thank you
Vaibhav Gupta
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v6] ndbm test suite

[Vaibhav Gupta]

---
 testsuites/psxtests/Makefile.am |   9 +
 testsuites/psxtests/configure.ac|   1 +
 testsuites/psxtests/psxndbm01/init.c| 299 
 testsuites/psxtests/psxndbm01/psxndbm01.doc |  36 +++
 testsuites/psxtests/psxndbm01/psxndbm01.scn |  29 ++
 5 files changed, 374 insertions(+)
 create mode 100644 testsuites/psxtests/psxndbm01/init.c
 create mode 100644 testsuites/psxtests/psxndbm01/psxndbm01.doc
 create mode 100644 testsuites/psxtests/psxndbm01/psxndbm01.scn

diff --git a/testsuites/psxtests/Makefile.am b/testsuites/psxtests/Makefile.am
index 59c9f2085b..36da591ccc 100755
--- a/testsuites/psxtests/Makefile.am
+++ b/testsuites/psxtests/Makefile.am
@@ -694,6 +694,15 @@ psxmutexattr01_CPPFLAGS = $(AM_CPPFLAGS) 
$(TEST_FLAGS_psxmutexattr01) \
$(support_includes) -I$(top_srcdir)/include
 endif
 
+if TEST_psxndbm01
+psx_tests += psxndbm01
+psx_screens += psxndbm01/psxndbm01.scn
+psx_docs += psxndbm01/psxndbm01.doc
+psxndbm01_SOURCES = psxndbm01/init.c
+psxndbm01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxndbm01) \
+   $(support_includes)
+endif
+
 if TEST_psxobj01
 psx_tests += psxobj01
 psx_screens += psxobj01/psxobj01.scn
diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/configure.ac
index 85559e4aa5..07d7ccaf55 100644
--- a/testsuites/psxtests/configure.ac
+++ b/testsuites/psxtests/configure.ac
@@ -110,6 +110,7 @@ RTEMS_TEST_CHECK([psxmsgq02])
 RTEMS_TEST_CHECK([psxmsgq03])
 RTEMS_TEST_CHECK([psxmsgq04])
 RTEMS_TEST_CHECK([psxmutexattr01])
+RTEMS_TEST_CHECK([psxndbm01])
 RTEMS_TEST_CHECK([psxobj01])
 RTEMS_TEST_CHECK([psxonce01])
 RTEMS_TEST_CHECK([psxpasswd01])
diff --git a/testsuites/psxtests/psxndbm01/init.c 
b/testsuites/psxtests/psxndbm01/init.c
new file mode 100644
index 00..a1eff4bd67
--- /dev/null
+++ b/testsuites/psxtests/psxndbm01/init.c
@@ -0,0 +1,299 @@
+/**
+ *  @file
+ *  @brief Test suite for ndbm.h methods
+ */
+
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2019 Vaibhav Gupta
+ *
+ * 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.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+/* header files are listed in lexical/lexicographical/alphabetical order */
+
+#include 
+#include   /* contains definitions of 'open_flags' */
+#include 
+#include/* contains declarations of ndbm methods */
+#include 
+#include 
+#include 
+#include/* contains definitions of 'file_mode' */
+#include 
+#include 
+#include 
+
+const char rtems_test_name[] = "PSXNDBM 01";
+
+#define NAME  "VARoDeK"
+#define PHONE_NO  "123-321-777-888"
+#define DB_NAME   "phones_test"
+#define NAME2 "VG"
+#define PHONE_NO2 "321-123-888-777"
+
+/* forward declarations to avoid warnings */
+rtems_task Init(rtems_task_argument ignored);
+
+/*
+* This Function takes DBM* as a argument and count the number of records in the
+* database pointed by it.
+*/
+static int count_no_of_records( DBM *db_local )
+{
+  int count = 0;
+  datum temp;
+
+  for (
+temp = dbm_firstkey( db_local );
+temp.dptr != NULL;
+temp = dbm_nextkey( db_local ), count++
+  );
+  
+  return count;
+}
+
+/* Test Function Begins */
+rtems_task Init(rtems_task_argument ignored)
+{
+  datum name  = { NAME, sizeof( NAME ) };
+  datum put_phone_no  = { PHONE_NO, sizeof( PHONE_NO ) };
+  datum name2 = { NAME2, sizeof( NAME2 ) };
+  datum put_phone_no2 = { PHONE_NO2, sizeof( PHONE_NO2 ) };
+
+  datum get_phone_no, key;
+ 
+  int i;
+  char *test_strings;
+
+  DBM *db;
+
+  TEST_BEGIN();
+
+/* A Simple test to check if ndbm methods are call-able */
+
+/*
+ * A Simple t

[PATCH v5] ndbm test suite

[Vaibhav Gupta]

---
 testsuites/psxtests/Makefile.am  |   7 +
 testsuites/psxtests/configure.ac |   1 +
 testsuites/psxtests/psxndbm01/init.c | 299 +++
 3 files changed, 307 insertions(+)
 create mode 100644 testsuites/psxtests/psxndbm01/init.c

diff --git a/testsuites/psxtests/Makefile.am b/testsuites/psxtests/Makefile.am
index 59c9f2085b..7d1c0a783c 100755
--- a/testsuites/psxtests/Makefile.am
+++ b/testsuites/psxtests/Makefile.am
@@ -694,6 +694,13 @@ psxmutexattr01_CPPFLAGS = $(AM_CPPFLAGS) 
$(TEST_FLAGS_psxmutexattr01) \
$(support_includes) -I$(top_srcdir)/include
 endif
 
+if TEST_psxndbm01
+psx_tests += psxndbm01
+psxndbm01_SOURCES = psxndbm01/init.c
+psxndbm01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxndbm01) \
+   $(support_includes)
+endif
+
 if TEST_psxobj01
 psx_tests += psxobj01
 psx_screens += psxobj01/psxobj01.scn
diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/configure.ac
index 85559e4aa5..07d7ccaf55 100644
--- a/testsuites/psxtests/configure.ac
+++ b/testsuites/psxtests/configure.ac
@@ -110,6 +110,7 @@ RTEMS_TEST_CHECK([psxmsgq02])
 RTEMS_TEST_CHECK([psxmsgq03])
 RTEMS_TEST_CHECK([psxmsgq04])
 RTEMS_TEST_CHECK([psxmutexattr01])
+RTEMS_TEST_CHECK([psxndbm01])
 RTEMS_TEST_CHECK([psxobj01])
 RTEMS_TEST_CHECK([psxonce01])
 RTEMS_TEST_CHECK([psxpasswd01])
diff --git a/testsuites/psxtests/psxndbm01/init.c 
b/testsuites/psxtests/psxndbm01/init.c
new file mode 100644
index 00..a1eff4bd67
--- /dev/null
+++ b/testsuites/psxtests/psxndbm01/init.c
@@ -0,0 +1,299 @@
+/**
+ *  @file
+ *  @brief Test suite for ndbm.h methods
+ */
+
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2019 Vaibhav Gupta
+ *
+ * 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.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+/* header files are listed in lexical/lexicographical/alphabetical order */
+
+#include 
+#include   /* contains definitions of 'open_flags' */
+#include 
+#include/* contains declarations of ndbm methods */
+#include 
+#include 
+#include 
+#include/* contains definitions of 'file_mode' */
+#include 
+#include 
+#include 
+
+const char rtems_test_name[] = "PSXNDBM 01";
+
+#define NAME  "VARoDeK"
+#define PHONE_NO  "123-321-777-888"
+#define DB_NAME   "phones_test"
+#define NAME2 "VG"
+#define PHONE_NO2 "321-123-888-777"
+
+/* forward declarations to avoid warnings */
+rtems_task Init(rtems_task_argument ignored);
+
+/*
+* This Function takes DBM* as a argument and count the number of records in the
+* database pointed by it.
+*/
+static int count_no_of_records( DBM *db_local )
+{
+  int count = 0;
+  datum temp;
+
+  for (
+temp = dbm_firstkey( db_local );
+temp.dptr != NULL;
+temp = dbm_nextkey( db_local ), count++
+  );
+  
+  return count;
+}
+
+/* Test Function Begins */
+rtems_task Init(rtems_task_argument ignored)
+{
+  datum name  = { NAME, sizeof( NAME ) };
+  datum put_phone_no  = { PHONE_NO, sizeof( PHONE_NO ) };
+  datum name2 = { NAME2, sizeof( NAME2 ) };
+  datum put_phone_no2 = { PHONE_NO2, sizeof( PHONE_NO2 ) };
+
+  datum get_phone_no, key;
+ 
+  int i;
+  char *test_strings;
+
+  DBM *db;
+
+  TEST_BEGIN();
+
+/* A Simple test to check if ndbm methods are call-able */
+
+/*
+ * A Simple test to check if NDBM methods are call-able
+ * 
+ * We will try to open a database and then close it.
+ * If it successful, hence we can have further tests.
+ * Also, while opening it for first time, will create that database,
+ * hence we will be able to test for 'O_RDWR | O_EXCL' case later.
+ * Meanwhile we w

Re: [PATCH v4] ndbm test suite

[Vaibhav Gupta]

On Fri, Jul 19, 2019 at 2:12 AM Gedare Bloom  wrote:

> On Thu, Jul 18, 2019 at 11:05 AM Vaibhav Gupta 
> wrote:
> >
> > ---
> >  testsuites/psxtests/Makefile.am  |   7 +
> >  testsuites/psxtests/configure.ac |   1 +
> >  testsuites/psxtests/psxndbm01/init.c | 305 +++
> >  3 files changed, 313 insertions(+)
> >  create mode 100644 testsuites/psxtests/psxndbm01/init.c
> >
> > diff --git a/testsuites/psxtests/Makefile.am
> b/testsuites/psxtests/Makefile.am
> > index 59c9f2085b..7d1c0a783c 100755
> > --- a/testsuites/psxtests/Makefile.am
> > +++ b/testsuites/psxtests/Makefile.am
> > @@ -694,6 +694,13 @@ psxmutexattr01_CPPFLAGS = $(AM_CPPFLAGS)
> $(TEST_FLAGS_psxmutexattr01) \
> > $(support_includes) -I$(top_srcdir)/include
> >  endif
> >
> > +if TEST_psxndbm01
> > +psx_tests += psxndbm01
> > +psxndbm01_SOURCES = psxndbm01/init.c
> > +psxndbm01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxndbm01) \
> > +   $(support_includes)
> > +endif
> > +
> >  if TEST_psxobj01
> >  psx_tests += psxobj01
> >  psx_screens += psxobj01/psxobj01.scn
> > diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/
> configure.ac
> > index 85559e4aa5..07d7ccaf55 100644
> > --- a/testsuites/psxtests/configure.ac
> > +++ b/testsuites/psxtests/configure.ac
> > @@ -110,6 +110,7 @@ RTEMS_TEST_CHECK([psxmsgq02])
> >  RTEMS_TEST_CHECK([psxmsgq03])
> >  RTEMS_TEST_CHECK([psxmsgq04])
> >  RTEMS_TEST_CHECK([psxmutexattr01])
> > +RTEMS_TEST_CHECK([psxndbm01])
> >  RTEMS_TEST_CHECK([psxobj01])
> >  RTEMS_TEST_CHECK([psxonce01])
> >  RTEMS_TEST_CHECK([psxpasswd01])
> > diff --git a/testsuites/psxtests/psxndbm01/init.c
> b/testsuites/psxtests/psxndbm01/init.c
> > new file mode 100644
> > index 00..d3b1e36ca0
> > --- /dev/null
> > +++ b/testsuites/psxtests/psxndbm01/init.c
> > @@ -0,0 +1,305 @@
> > +/**
> > + *  @file
> > + *  @brief Test suite for ndbm.h methods
> > + */
> > +
> > +/*
> > + * SPDX-License-Identifier: BSD-2-Clause
> > + *
> > + * Copyright (C) 2019 Vaibhav Gupta
> > + *
> > + * 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.
> > + */
> > +
> > +#ifdef HAVE_CONFIG_H
> > +#include "config.h"
> > +#endif
> > +
> > +/* header files are listed in lexical/lexicographical/alphabetical
> order */
> > +
> > +#include 
> > +#include   /* contains definitions of 'open_flags' */
> > +#include 
> > +#include/* contains declarations of ndbm methods */
> > +#include 
> > +#include 
> > +#include 
> > +#include/* contains definitions of 'file_mode' */
> > +#include 
> > +#include 
> > +#include 
> > +
> > +const char rtems_test_name[] = "PSXNDBM 01";
> > +
> > +#define NAME  "VARoDeK"
> > +#define PHONE_NO  "123-321-777-888"
> > +#define DB_NAME   "phones_test"
> > +#define NAME2 "VG"
> > +#define PHONE_NO2 "321-123-888-777"
> > +
> > +/* forward declarations to avoid wa

[PATCH v4] ndbm test suite

[Vaibhav Gupta]

---
 testsuites/psxtests/Makefile.am  |   7 +
 testsuites/psxtests/configure.ac |   1 +
 testsuites/psxtests/psxndbm01/init.c | 305 +++
 3 files changed, 313 insertions(+)
 create mode 100644 testsuites/psxtests/psxndbm01/init.c

diff --git a/testsuites/psxtests/Makefile.am b/testsuites/psxtests/Makefile.am
index 59c9f2085b..7d1c0a783c 100755
--- a/testsuites/psxtests/Makefile.am
+++ b/testsuites/psxtests/Makefile.am
@@ -694,6 +694,13 @@ psxmutexattr01_CPPFLAGS = $(AM_CPPFLAGS) 
$(TEST_FLAGS_psxmutexattr01) \
$(support_includes) -I$(top_srcdir)/include
 endif
 
+if TEST_psxndbm01
+psx_tests += psxndbm01
+psxndbm01_SOURCES = psxndbm01/init.c
+psxndbm01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxndbm01) \
+   $(support_includes)
+endif
+
 if TEST_psxobj01
 psx_tests += psxobj01
 psx_screens += psxobj01/psxobj01.scn
diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/configure.ac
index 85559e4aa5..07d7ccaf55 100644
--- a/testsuites/psxtests/configure.ac
+++ b/testsuites/psxtests/configure.ac
@@ -110,6 +110,7 @@ RTEMS_TEST_CHECK([psxmsgq02])
 RTEMS_TEST_CHECK([psxmsgq03])
 RTEMS_TEST_CHECK([psxmsgq04])
 RTEMS_TEST_CHECK([psxmutexattr01])
+RTEMS_TEST_CHECK([psxndbm01])
 RTEMS_TEST_CHECK([psxobj01])
 RTEMS_TEST_CHECK([psxonce01])
 RTEMS_TEST_CHECK([psxpasswd01])
diff --git a/testsuites/psxtests/psxndbm01/init.c 
b/testsuites/psxtests/psxndbm01/init.c
new file mode 100644
index 00..d3b1e36ca0
--- /dev/null
+++ b/testsuites/psxtests/psxndbm01/init.c
@@ -0,0 +1,305 @@
+/**
+ *  @file
+ *  @brief Test suite for ndbm.h methods
+ */
+
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2019 Vaibhav Gupta
+ *
+ * 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.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+/* header files are listed in lexical/lexicographical/alphabetical order */
+
+#include 
+#include   /* contains definitions of 'open_flags' */
+#include 
+#include/* contains declarations of ndbm methods */
+#include 
+#include 
+#include 
+#include/* contains definitions of 'file_mode' */
+#include 
+#include 
+#include 
+
+const char rtems_test_name[] = "PSXNDBM 01";
+
+#define NAME  "VARoDeK"
+#define PHONE_NO  "123-321-777-888"
+#define DB_NAME   "phones_test"
+#define NAME2 "VG"
+#define PHONE_NO2 "321-123-888-777"
+
+/* forward declarations to avoid warnings */
+rtems_task Init(rtems_task_argument ignored);
+int count_no_of_records( DBM *db_local );
+
+/*
+* This Function takes DBM* as a argument and count the number of records in the
+* database pointed by it.
+*/
+int count_no_of_records( DBM *db_local )
+{
+  int count = 0;
+  datum temp;
+
+  for(
+temp = dbm_firstkey( db_local );
+temp.dptr != NULL;
+temp = dbm_nextkey( db_local ) , count++
+  );
+  
+  return count;
+}
+
+/* Test Function Begins */
+rtems_task Init(rtems_task_argument ignored)
+{
+  datum name  = { NAME, sizeof( NAME ) };
+  datum put_phone_no  = { PHONE_NO, sizeof( PHONE_NO ) };
+  datum name2 = { NAME2, sizeof( NAME2 ) };
+  datum put_phone_no2 = { PHONE_NO2, sizeof( PHONE_NO2 ) };
+
+  datum get_phone_no, key;
+ 
+  int i;
+  char *test_strings;
+
+  DBM *db;
+
+  TEST_BEGIN();
+
+/* A Simple test to check if ndbm methods are call-able */
+
+/*
+ * A Simple test to check if NDBM methods are call-able
+ * 
+ * We will try to open a database and then close it.
+ * If it successful, hence we can have further tests.
+ * Also, while opening it for first time, will create that database,
+ * hence we will be able to test for 'O_RDWR | O_EXCL&#

Re: Sources for fenv (ARM, PPC, x86, SPARC and RISC5)

[Vaibhav Gupta]

On Wed, Jul 17, 2019 at 11:42 PM Gedare Bloom  wrote:

> On Tue, Jul 16, 2019 at 6:57 AM Joel Sherrill  wrote:
> >
> > Let's give preference to FreeBSD sources. Notes below.
> >
> > On Wed, Jul 3, 2019 at 1:08 PM Vaibhav Gupta 
> wrote:
> >>
> >> Hello,
> >> I have found sources for fenv.
> >>
> >> 1.1) - ARM FreeBSD Source:
> >> - https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.h
> >> - https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.c
> >> .
> >> 1.2) - ARM NetBSD Source :
> >> - https://github.com/NetBSD/src/blob/trunk/sys/arch/arm/include/fenv.h
> >> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/arm/fenv.c
> >>
> -
> >
> >
> > For the ARM FreeBSD source, there are some ifdef's which appear to
> > be for architectural variations. Please check the gcc source for arm
> > (gcc-XXX/gcc/config/arm) to see if they are defined by gcc. If they
> > all are, then there is nothing to consider on how they get tripped.
> >
> > For example, __ARM_PCS_AAPCS64 is one. That looks like a multilib
> > define.
> >
> >>
> >> 2.1) - SPARC NetBSD Source :
> >> -
> https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h
> >> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/sparc/fenv.c
> >>
> 
> >
> >
> > This looks good and may work for sparc64 as well as sparc. Check if
> > sparc64-rtems5-gcc defines __arch64 as used byL
> >
> >
> https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h#L36
> >
> >>
> >> 3.1) - PPC FreeBSD Source:
> >> -
> https://github.com/freebsd/freebsd/blob/master/lib/msun/powerpc/fenv.h
> >> -
> https://github.com/freebsd/freebsd/blob/master/lib/msun/powerpc/fenv.c
> >> .
> >> 3.2) - PPC NetBSD Source:
> >> -
> https://github.com/NetBSD/src/blob/trunk/sys/arch/powerpc/include/fenv.h
> >> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/powerpc/fenv.c
> >>
> ---
> >
> >
> > Sam advice on PPC. Looks OK, check ifdefs
> >
> >>
> >> 4.1) - x86 FreeBSD Source:
> >> - https://github.com/freebsd/freebsd/blob/master/lib/msun/x86/fenv.h
> >> .
> >> 4.2) - x86 NetBSD Source:
> >> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/x86_64/fenv.c
> >>
> --
> >
> >
> > This is not i386 (e.g. 32-bit), it is for the 64-bit target. Good to
> merge it into
> > newlib but we don't have a fully functional port to test this with.
> >
> >>
> >> 5.1) - RISC5 FreeBSD Source:
> >> - https://github.com/freebsd/freebsd/blob/master/lib/msun/riscv/fenv.h
> >> - https://github.com/freebsd/freebsd/blob/master/lib/msun/riscv/fenv.c
> >> .
> >> 5.2) - RISC5 NetBSD Source:
> >> -
> https://github.com/NetBSD/src/blob/trunk/sys/arch/riscv/include/fenv.h
> >> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/riscv/fenv.c
> >> 
> >
> >
> > Same advice.
> >
> >>
> >> 
> >>
> >> It's impossible to depend on either NetBSD or FreeBSD.
> >
> >
> > Yep. Give preference to FreeBSD but if it isn't in FreeBSD, use NetBSD.
> >>
> >> .
> >> For some architectures, FreeBSD has code,
> >> for some, NetBSD has.
> >> .
> >> For x86, Free BSD has explicit header
> >> and NetBSD has .c file.
> >
> >
> > These are all architecture specific files so do not go in a main include
> > or source directory. They go in an architecture specific subdirectory.
> >
> > See
> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=newlib/libm/machine;h=9b2197b2660fd84c6b64ef265c1ec3b6e30c9074;hb=HEAD
> >
> > And notice that arm, aarch64, riscv, and i386 are all already there.
> Looks
> > like you can focus on the ones not there (PPC and SPARC). Ignore x86_64
> > for now. If there is a ticket for the port, just add a comment to that.
> I don't
> > think we are setup to test that port right now.
> >
> Since arm/riscv/i386 are there, you might be able to write an fenv
> test suite that can pass on one of those archs, and then use it with
> confidence to do TDD of other architectures.
>
Sure, I will move ahead with this.
Thank you!

>
> > Hope that all makes sense.
> >
> > --joel
> >
> >> .
> >> .
> >> .
> >> Vaibhav Gupta
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Sources for fenv (ARM, PPC, x86, SPARC and RISC5)

[Vaibhav Gupta]

On Tue, Jul 16, 2019 at 6:26 PM Joel Sherrill  wrote:

> Let's give preference to FreeBSD sources. Notes below.
>
> On Wed, Jul 3, 2019 at 1:08 PM Vaibhav Gupta 
> wrote:
>
>> Hello,
>> I have found sources for fenv.
>>
>> 1.1) - ARM FreeBSD Source:
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.h
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.c
>> .
>> 1.2) - ARM NetBSD Source :
>> - https://github.com/NetBSD/src/blob/trunk/sys/arch/arm/include/fenv.h
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/arm/fenv.c
>>
>> -
>>
>
> For the ARM FreeBSD source, there are some ifdef's which appear to
> be for architectural variations. Please check the gcc source for arm
> (gcc-XXX/gcc/config/arm) to see if they are defined by gcc. If they
> all are, then there is nothing to consider on how they get tripped.
>
> For example, __ARM_PCS_AAPCS64 is one. That looks like a multilib
> define.
>
Okay!

>
>
>> 2.1) - SPARC NetBSD Source :
>> - https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/sparc/fenv.c
>>
>> 
>>
>
> This looks good and may work for sparc64 as well as sparc. Check if
> sparc64-rtems5-gcc defines __arch64 as used byL
>
> https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h#L36
>
>
>
>> 3.1) - PPC FreeBSD Source:
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/powerpc/fenv.h
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/powerpc/fenv.c
>> .
>> 3.2) - PPC NetBSD Source:
>> -
>> https://github.com/NetBSD/src/blob/trunk/sys/arch/powerpc/include/fenv.h
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/powerpc/fenv.c
>>
>> ---
>>
>
> Sam advice on PPC. Looks OK, check ifdefs
>
>
>> 4.1) - x86 FreeBSD Source:
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/x86/fenv.h
>> .
>> 4.2) - x86 NetBSD Source:
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/x86_64/fenv.c
>> --
>>
>
> This is not i386 (e.g. 32-bit), it is for the 64-bit target. Good to merge
> it into
> newlib but we don't have a fully functional port to test this with.
>
>
>> 5.1) - RISC5 FreeBSD Source:
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/riscv/fenv.h
>> - https://github.com/freebsd/freebsd/blob/master/lib/msun/riscv/fenv.c
>> .
>> 5.2) - RISC5 NetBSD Source:
>> - https://github.com/NetBSD/src/blob/trunk/sys/arch/riscv/include/fenv.h
>> - https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/riscv/fenv.c
>> 
>>
>
> Same advice.
>
>
>> 
>>
>> It's impossible to depend on either NetBSD or FreeBSD.
>>
>
> Yep. Give preference to FreeBSD but if it isn't in FreeBSD, use NetBSD.
>
>> .
>> For some architectures, FreeBSD has code,
>> for some, NetBSD has.
>> .
>> For x86, Free BSD has explicit header
>> and NetBSD has .c file.
>>
>
> These are all architecture specific files so do not go in a main include
> or source directory. They go in an architecture specific subdirectory.
>
Yah, so here was one confusion.
I was going through fenv sources of SPARC in NetBSD
NetBSD has defined two headers for fenv
1- https://github.com/NetBSD/src/blob/trunk/include/fenv.h
---This contains function prototypes
.
2- https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h
---This defines macros
.
And hence, I will have to use either FreeBSD or NetBSD depending in the
architecture, I am planning for this approach:
I will make a generic header file, `fenv.h`, which will contain function
prototypes
and other data which are common in all architectures.
Then I will place architecture specific data in their respective `fenv.c`
file
along with the function definitions.

>
> See
> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=newlib/libm/machine;h=9b2197b2660fd84c6b64ef265c1ec3b6e30c9074;hb=HEAD
>
> And notice that arm, aarch64, riscv, and i386 are all already there. Looks
> like you can focus on the ones not there (PPC and SPARC). Ignore x86_64
> for now. If there is a ticket for the port, just add a comment to that. I
> don't
> think we are setup to test that port right now.
>
> Hope that all makes sense.
>
Yes, thank you!

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

Re: [PATCH v3] ndbm test suite

[Vaibhav Gupta]

On Wed, Jul 17, 2019, 11:46 PM Gedare Bloom  wrote:

> On Wed, Jul 17, 2019 at 11:09 AM Vaibhav Gupta 
> wrote:
> >
> > Thanks for the review!
> > I will re generate the patch with corrections
> >
> > On Wed, Jul 17, 2019 at 10:12 PM Gedare Bloom  wrote:
> >>
> >> On Wed, Jul 10, 2019 at 1:49 AM Vaibhav Gupta 
> wrote:
> >> >
> >> > ---
> >> >  testsuites/psxtests/Makefile.am  |   7 +
> >> >  testsuites/psxtests/configure.ac |   1 +
> >> >  testsuites/psxtests/psxndbm01/init.c | 260
> +++
> >> >  3 files changed, 268 insertions(+)
> >> >  create mode 100644 testsuites/psxtests/psxndbm01/init.c
> >> >
> >> > diff --git a/testsuites/psxtests/Makefile.am
> b/testsuites/psxtests/Makefile.am
> >> > index 59c9f2085b..7d1c0a783c 100755
> >> > --- a/testsuites/psxtests/Makefile.am
> >> > +++ b/testsuites/psxtests/Makefile.am
> >> > @@ -694,6 +694,13 @@ psxmutexattr01_CPPFLAGS = $(AM_CPPFLAGS)
> $(TEST_FLAGS_psxmutexattr01) \
> >> > $(support_includes) -I$(top_srcdir)/include
> >> >  endif
> >> >
> >> > +if TEST_psxndbm01
> >> > +psx_tests += psxndbm01
> >> > +psxndbm01_SOURCES = psxndbm01/init.c
> >> > +psxndbm01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxndbm01) \
> >> > +   $(support_includes)
> >> > +endif
> >> > +
> >> >  if TEST_psxobj01
> >> >  psx_tests += psxobj01
> >> >  psx_screens += psxobj01/psxobj01.scn
> >> > diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/
> configure.ac
> >> > index 85559e4aa5..07d7ccaf55 100644
> >> > --- a/testsuites/psxtests/configure.ac
> >> > +++ b/testsuites/psxtests/configure.ac
> >> > @@ -110,6 +110,7 @@ RTEMS_TEST_CHECK([psxmsgq02])
> >> >  RTEMS_TEST_CHECK([psxmsgq03])
> >> >  RTEMS_TEST_CHECK([psxmsgq04])
> >> >  RTEMS_TEST_CHECK([psxmutexattr01])
> >> > +RTEMS_TEST_CHECK([psxndbm01])
> >> >  RTEMS_TEST_CHECK([psxobj01])
> >> >  RTEMS_TEST_CHECK([psxonce01])
> >> >  RTEMS_TEST_CHECK([psxpasswd01])
> >> > diff --git a/testsuites/psxtests/psxndbm01/init.c
> b/testsuites/psxtests/psxndbm01/init.c
> >> > new file mode 100644
> >> > index 00..b38900361d
> >> > --- /dev/null
> >> > +++ b/testsuites/psxtests/psxndbm01/init.c
> >> > @@ -0,0 +1,260 @@
> >> > +/**
> >> > + *  @file
> >> > + *  @brief Test suite for ndbm.h methods
> >> > + */
> >> > +
> >> > +/*
> >> > + * SPDX-License-Identifier: BSD-2-Clause
> >> > + *
> >> > + * Copyright (C) 2019 Vaibhav Gupta
> >> > + *
> >> > + * 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.
> >> > + */
> >> > +
> >> > +#ifdef HAVE_CONFI

Re: [PATCH v3] ndbm test suite

[Vaibhav Gupta]

Thanks for the review!
I will re generate the patch with corrections

On Wed, Jul 17, 2019 at 10:12 PM Gedare Bloom  wrote:

> On Wed, Jul 10, 2019 at 1:49 AM Vaibhav Gupta 
> wrote:
> >
> > ---
> >  testsuites/psxtests/Makefile.am  |   7 +
> >  testsuites/psxtests/configure.ac |   1 +
> >  testsuites/psxtests/psxndbm01/init.c | 260 +++
> >  3 files changed, 268 insertions(+)
> >  create mode 100644 testsuites/psxtests/psxndbm01/init.c
> >
> > diff --git a/testsuites/psxtests/Makefile.am
> b/testsuites/psxtests/Makefile.am
> > index 59c9f2085b..7d1c0a783c 100755
> > --- a/testsuites/psxtests/Makefile.am
> > +++ b/testsuites/psxtests/Makefile.am
> > @@ -694,6 +694,13 @@ psxmutexattr01_CPPFLAGS = $(AM_CPPFLAGS)
> $(TEST_FLAGS_psxmutexattr01) \
> > $(support_includes) -I$(top_srcdir)/include
> >  endif
> >
> > +if TEST_psxndbm01
> > +psx_tests += psxndbm01
> > +psxndbm01_SOURCES = psxndbm01/init.c
> > +psxndbm01_CPPFLAGS = $(AM_CPPFLAGS) $(TEST_FLAGS_psxndbm01) \
> > +   $(support_includes)
> > +endif
> > +
> >  if TEST_psxobj01
> >  psx_tests += psxobj01
> >  psx_screens += psxobj01/psxobj01.scn
> > diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/
> configure.ac
> > index 85559e4aa5..07d7ccaf55 100644
> > --- a/testsuites/psxtests/configure.ac
> > +++ b/testsuites/psxtests/configure.ac
> > @@ -110,6 +110,7 @@ RTEMS_TEST_CHECK([psxmsgq02])
> >  RTEMS_TEST_CHECK([psxmsgq03])
> >  RTEMS_TEST_CHECK([psxmsgq04])
> >  RTEMS_TEST_CHECK([psxmutexattr01])
> > +RTEMS_TEST_CHECK([psxndbm01])
> >  RTEMS_TEST_CHECK([psxobj01])
> >  RTEMS_TEST_CHECK([psxonce01])
> >  RTEMS_TEST_CHECK([psxpasswd01])
> > diff --git a/testsuites/psxtests/psxndbm01/init.c
> b/testsuites/psxtests/psxndbm01/init.c
> > new file mode 100644
> > index 00..b38900361d
> > --- /dev/null
> > +++ b/testsuites/psxtests/psxndbm01/init.c
> > @@ -0,0 +1,260 @@
> > +/**
> > + *  @file
> > + *  @brief Test suite for ndbm.h methods
> > + */
> > +
> > +/*
> > + * SPDX-License-Identifier: BSD-2-Clause
> > + *
> > + * Copyright (C) 2019 Vaibhav Gupta
> > + *
> > + * 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.
> > + */
> > +
> > +#ifdef HAVE_CONFIG_H
> > +#include "config.h"
> > +#endif
> > +
> > +/* header files are listed in lexical/lexicographical/alphabetical
> order */
> > +
> > +#include 
> > +#include   /* contains definitions of `open_flags` */
> > +#include 
> > +#include/* conatains declarations of ndbm methods */
> > +#include 
> > +#include 
> > +#include 
> > +#include/* contains definitions of `file_mode` */
> > +#include 
> > +#include 
> > +#include 
> > +
> > +const char rtems_test_name[] = "PSXNDBM 01";
> > +
> > +#define NAME  "VARoDeK"
> > +#define PHONE_NO  "123-321-777-888"
> > +#define DB_NAME   "phones_test"
> > +#define NAME2 "VG"
> > +#define PHONE_NO2 "321-123-888-777"
>

Re: GSoC 2019 | POSIX Compliance - RSB patch generated ndbm library (lib_a-ndbm.o) successfully in RTEMS Toolchain

[Vaibhav Gupta]

On Mon, Jul 15, 2019 at 10:21 PM Gedare Bloom  wrote:

> On Thu, Jul 11, 2019 at 9:01 PM Vaibhav Gupta 
> wrote:
> >
> > Sounds good to me.
> >
> > On Thu, Jul 11, 2019 at 6:47 PM Joel Sherrill  wrote:
> >>
> >>
> >>
> >> On Thu, Jul 11, 2019 at 2:12 AM Vaibhav Gupta 
> wrote:
> >>>
> >>> Hello,
> >>> After Joel pointed out in an offlist discussion,
> >>> I made a new patch for ndbm port.
> >>> .
> >>> To send the changes to Newlib, i had to place `ndbm.h` , `ndbm.c` in
> their respective places and make  changes in Makefile.am.
> >>> Before, I applied same patch to RSB hence ndbm library was not
> generated.
> >>> .
> >>
> >> In my local build yesterday, I saw the symbols in the installed libc.a.
> I have not run the tests.
> >>
> >>>
> >>> .
> >>> This time I also added files generated by `autoreconf -fvi` in the
> patch.
> >>> .
> >>> This patch is 10MB in size hence cannot be send in raw format on
> mailing list.
> >>
> >>
> >> The person committing is supposed to do the autoreconf and commit that.
> >>
> >> No one has answered if it is OK to commit. That was the last message in
> the thread.
> >
> > I will ping on that thread again for confirmation.
> >>
> >>
> >>>
> >>> .
> >>> This patch worked with RSB and ndbm library (lib_a-ndbm.o) was
> generated
> >>> successfully in RTEMS Toolchain.
> >>
> >>
> >> I'm hoping we can avoid this by pushing the patch to newlib, then
> bumping the hash for
> >> newlib in the RSB, then adding your ndbm test patch to RTEMS.
> >
> > Yeah, meanwhile testsuite can be verified.
> > .
> > Also, please look at the sources I send on devel for fenv. Should I
> ignore architectures
> > which are not having FreeBSD source? or Should i pick from NetBSD and
> FreeBSD
> > both?
> Pick from both, figuring out how to translate the NetBSD
> implementation to work with how the FreeBSD ones are implemented, if
> necessary. Mostly, they define very similar data structures,
> macros/functions, etc., so I think it should be possible to unify
> them.
>
Sure, then I will work in this direction. Also, SPARC has only NetBSD
source,
so I guess it can be ported directly from it.

-Vaibhav Gupta

>
> Gedare
>
> >>
> >>
> >> --joel
> >>
> >>>
> >>>
> >>>
> >>> Thank you
> >>> Vaibhav Gupta
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC 2019 | POSIX Compliance - Location for fenv files for sparc

[Vaibhav Gupta]

The implementation of fenv for SPARC is in NetBSD
only.
.
Now NetBSD has two `fenv.h` header files.
1- https://github.com/NetBSD/src/blob/trunk/include/fenv.h
This contains function prototypes.
This can go to `newlib/libc/include`
.
2- https://github.com/NetBSD/src/blob/trunk/sys/arch/sparc/include/fenv.h
This contains some macros.
Where should this go??


Thank you
Vaibhav Gupta
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel