Ticket #2974 Enable search.h functionality in newlib

[Vaibhav Gupta]

On Mon, 23 Mar 2020 at 06:47, Gedare Bloom <gedare at rtems.org> wrote:

> On Sun, Mar 22, 2020 at 8:46 AM Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Sun, Mar 22, 2020, 1:58 AM Vaibhav Gupta <vaibhav.varodek at gmail.com>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200323/ff1d82b6/attachment.html>