• Help: Ada in NetBSD

    From Fernando Oleo Blanco@21:1/5 to All on Sun Aug 29 13:06:53 2021
    Dear All,

    I have been trying for the past few months to make GCC/Ada work in
    NetBSD. I am writing this message to you since I have been stuck in a
    roadblock for far too long and without concrete answers.

    Long story short: JMarino, within the Aurora project, already ported
    GCC/Ada to a lot of systems, namely FreeBSD, DragonflyBSD, NetBSD and
    Solaris. The last version that works without friction in NetBSD/pkgsrc
    is GCC v6. I wanted to update GCC to v10 (10.3.0).

    So, one can compile GCC v10 with C, C++ and Ada support with v6 without
    any issues. The biggest problem is that the RT (RunTime Files) had no configuration for NetBSD (see the original Makefile.rtl in the gcc/ada directory). I fixed it by copying the FreeBSD support files and
    modifying a imported C function to be POSIX compilant, since NetBSD did
    not had the function that FreeBSD used (related to pthreads).

    The results of compiling GCC v10 with this "small" change are documented
    in a blog entry I did: https://www.irvise.xyz/Projects%20&%20Engineering/updating-gcc-ada-pkgsrc.html

    TL;DR: GCC v10 compiles and can generate binaries!!! :D But...

    The tasking system is not working correctly (I have been testing the
    compiler with the ACATS test suite provided by Simon). The linker
    complains about some C functions not being correctly imported within Ada
    files. And the programs where the linker complains, once compiled, tend
    to get blocked or die. Here is one such example:

    /usr/bin/ld: /home/fernando/mysandboxfolder/usr/pkg/gcc10/lib/gcc/x86_64--netbsd/10.3.0/adalib/libgnat.a(s-osprim.o):
    in function `system__os_primitives__clock': /usr/pkgsrc/wip/gcc10-aux/work/build/gcc/ada/rts/s-osprim.adb:91:
    warning: warning: reference to compatibility gettimeofday(); include <sys/time.h> to generate correct reference

    As you can see, the linker says that, in this case, gettimeofday() is
    not correctly referenced and that I should include <sys/time.h>. Notice,
    it is complaining that the file s-osprim.adb, and Ada file, is at fault
    here. This happens to all files that use the tasking system in one way
    or another, so, in summary, all large projects, such as GPRBuild.

    I thought that an #include <sys/time.h> may have been missing from a C
    source file that is required to build the Ada compiler. After all, there
    were some defined (__NetBSD__) missing from the Ada sources.

    I added those. Nothing. I took a really good look at JMarino's patches: http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/gcc6-aux/files/diff-ada?rev=1.1&content-type=text/x-cvsweb-markup
    I applied some extra changes (the configure/configure.ac patches are
    failing to apply). Still nothing, it keeps failing.

    I have been looking for the "missing" #include files, they are <time.h>, <sys/time.h> and <signal.h>. I searched through the code, there are few occurrences of them and, for example, <sys/time.h> only appears in a
    legacy system.

    I checked the C signature files to make sure that they were also correct
    in the Ada sources, and they seem to match.

    I am out of ideas.

    How come the linker complains about those functions and not the other
    imported C ones? These files are automatically included with -lc.
    How could I go about fixing this issue? Any ideas, pointers?

    Below are the patches that I have created.

    If you are wondering why am I doing this: I like alternative systems,
    Ada is portable on paper, but what about in reality? And my end goal
    would be to see Ada everywhere and upstream these fixes to GCC.

    Thank you for your time,

    -------

    --- gcc/ada/adaint.c.orig 2021-08-28 18:39:27.509714592 +0000
    +++ gcc/ada/adaint.c 2021-08-28 18:40:44.190149364 +0000
    @@ -817,7 +817,8 @@
    }

    #if defined (_WIN32) || defined (__linux__) || defined (__sun__) \
    - || defined (__FreeBSD__) || defined(__DragonFly__) || defined (__QNX__)
    + || defined (__FreeBSD__) || defined(__DragonFly__) || defined (__QNX__) \
    + || defined (__NetBSD__)
    #define HAS_TARGET_WCHAR_T
    #endif

    --- gcc/ada/cstreams.c.orig 2021-08-28 18:42:21.323680378 +0000
    +++ gcc/ada/cstreams.c 2021-08-28 18:43:48.045445919 +0000
    @@ -188,7 +188,8 @@
    *p = '\\';
    }

    -#elif defined (__FreeBSD__) || defined (__DragonFly__) || defined (__OpenBSD__)
    +#elif defined (__FreeBSD__) || defined (__DragonFly__) \
    + || defined (__OpenBSD__) || defined (__NetBSD__)

    /* Use realpath function which resolves links and references to . and ..
    on those Unix systems that support it. Note that GNU/Linux
    provides it but
    @@ -270,7 +271,7 @@
    }

    #elif defined (__l
  • From Stephane Carrez@21:1/5 to All on Sun Aug 29 06:19:57 2021
    Hi!

    On NetBSD there are several symbols that are replaced by the virtue of including a C header.
    If you include correctly the C header, the correct symbol is used and you don't get the linker warning.

    For gettimeofday the symbol is replaced by __gettimeofday50.
    These symbols are marked with __RENAME(XXX) macros in the C headers.

    I would suggest to have a look at the .o files to find out the one that has the `gettimeofday` symbol that is not replaced.

    By the way, I'm intertested by your work as I'm still stuck on gcc 6 for my NetBSD machines.
    20 years ago I wrote the 68HC11 port that was integrated in GCC 3.3 so I have some past experience in working with GCC.
    Despite my very limited spare time, I could have a look if you provide me the sources of your port :-)

    Best regards,

    Stephane

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Wright@21:1/5 to Fernando Oleo Blanco on Sun Aug 29 18:34:50 2021
    Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

    The tasking system is not working correctly (I have been testing the
    compiler with the ACATS test suite provided by Simon).

    There are several tasking-related (CXD) tests in ACATS that few if any
    desktop OSs are expected to support; mainly, I think, priority-related.

    On macOS, I get (with latest ACATS 4.1W, not yet pushed, & FSF GCC 11.1.0)

    PASS: cxd1001
    PASS: cxd1002
    FAIL: cxd1003
    FAIL: cxd1004
    FAIL: cxd1005
    PASS: cxd1006
    PASS: cxd1007
    PASS: cxd1008
    UNSUPPORTED: cxd2001 (no multiprocessing)
    UNSUPPORTED: cxd2002 ( " )
    UNSUPPORTED: cxd2003 ( " )
    UNSUPPORTED: cxd2004 ( " )
    FAIL: cxd2006
    UNSUPPORTED: cxd2007 (no async task control)
    UNSUPPORTED: cxd2008 ( " )
    FAIL: cxd3001
    FAIL: cxd3002
    PASS: cxd3003
    PASS: cxd4001
    PASS: cxd4002
    PASS: cxd4003
    PASS: cxd4004
    PASS: cxd4005
    PASS: cxd4006
    PASS: cxd4007
    PASS: cxd4008
    PASS: cxd4009
    PASS: cxd4010
    PASS: cxd5001
    UNSUPPORTED: cxd6001 (no multiprocessing)
    UNSUPPORTED: cxd6002 ( " )
    UNSUPPORTED: cxd6003 ( " )
    PASS: cxd8001
    PASS: cxd8002
    PASS: cxd8003
    PASS: cxd9001
    PASS: cxda001
    PASS: cxda002
    PASS: cxda003
    PASS: cxda004
    UNSUPPORTED: cxdb001 (no async task control)
    UNSUPPORTED: cxdb002 ( " )
    UNSUPPORTED: cxdb003 ( " )
    UNSUPPORTED: cxdb004 ( " )

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to Stephane Carrez on Sun Aug 29 20:08:27 2021
    On 29.08.21 15:19, Stephane Carrez wrote:
    Hi!

    On NetBSD there are several symbols that are replaced by the virtue of including a C header.
    If you include correctly the C header, the correct symbol is used and you don't get the linker warning.

    That is what I did by adding the indicated header files to the NetBSD
    section of the init.c file. No other systems have them there (or
    anywhere in some cases). I expected that to fix the issue, but it did not.

    For gettimeofday the symbol is replaced by __gettimeofday50.
    These symbols are marked with __RENAME(XXX) macros in the C headers.

    I saw a few of those... So that is what they do... I never got to the
    bottom of that rabbit hole.

    I would suggest to have a look at the .o files to find out the one that has the `gettimeofday` symbol that is not replaced.

    I am doing it right now, lets see what I can find... However, as I said,
    the headers should have been already included. The linker does not
    complain during the compilation of gcc. Only when I try to build things
    with the newly created toolchain. Maybe that is a clue...

    By the way, I'm intertested by your work as I'm still stuck on gcc 6 for my NetBSD machines.
    20 years ago I wrote the 68HC11 port that was integrated in GCC 3.3 so I have some past experience in working with GCC.
    Despite my very limited spare time, I could have a look if you provide me the sources of your port :-)

    I am working directly on pkgsrc/wip. This way I hope to be able to
    upstream everything as quickly as possible. Jay Patelani already
    uploaded the patches from the initial blog post. You can find them here: https://github.com/NetBSD/pkgsrc-wip/tree/c550eafe889691af212379590974944e1359e180/gcc10_aux

    It is basically the gcc10 entry with the patch-ada* file in patches and
    Ada added to the USE_LANGUAGES variable (is has to be hardcoded, it
    cannot be set via options). It is not a clean snapshot, some dirty files
    were pulled, but it should work as first order approximation. The
    previous email contains some extra patches (though you would have to
    update the distinfo file manually). I was lucky that the pkgsrc got
    changed a few months back to make gcc6-aux the default, instead of gcc5-aux.

    I will ask you to take a look if I need to. However, this is "my
    personal project" I want to do this myself, so for the time being, no
    need for that :) I would like to see Ada running on as many systems and
    package managers as possible ;)

    P.S: I am yet to try your AWA, I am looking forwards to it.

    Regards,

    --
    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to All on Sun Aug 29 19:45:23 2021
    Thanks Simon, I will take into account this failures when I get to the
    final testing round.

    Regards,

    --
    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Wright@21:1/5 to Fernando Oleo Blanco on Sun Aug 29 19:25:05 2021
    Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

    On NetBSD there are several symbols that are replaced by the virtue
    of including a C header.
    If you include correctly the C header, the correct symbol is used
    and you don't get the linker warning.

    That is what I did by adding the indicated header files to the NetBSD
    section of the init.c file. No other systems have them there (or
    anywhere in some cases). I expected that to fix the issue, but it did not.

    The problem can't be fixed by including C headers, because ...

    For gettimeofday the symbol is replaced by __gettimeofday50.
    These symbols are marked with __RENAME(XXX) macros in the C headers.

    The C header is (I got this from the net, so beware)

    int gettimeofday(struct timeval * __restrict, void *__restrict)
    __RENAME(__gettimeofday50);

    so when you say, in Ada,

    function gettimeofday
    (tv : not null access struct_timeval;
    tz : struct_timezone_ptr) return Integer;
    pragma Import (C, gettimeofday, "gettimeofday");

    the linker looks for a symbol gettimeofday (or maybe _gettimeofday) and
    gives you the warning that you report. Since it's just a warning, it may actually work - for the moment, anyway.

    The Ada needs to change to

    function gettimeofday
    (tv : not null access struct_timeval;
    tz : struct_timezone_ptr) return Integer;
    pragma Import (C, gettimeofday, "gettimeofday50");

    (or maybe "_gettimeofday50", or even "__gettimeofday50" - nm will be
    your friend).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to Simon Wright on Sun Aug 29 22:36:41 2021
    On 29.08.21 20:25, Simon Wright wrote:
    The problem can't be fixed by including C headers, because ...

    For gettimeofday the symbol is replaced by __gettimeofday50.
    These symbols are marked with __RENAME(XXX) macros in the C headers.

    The C header is (I got this from the net, so beware)

    int gettimeofday(struct timeval * __restrict, void *__restrict)
    __RENAME(__gettimeofday50);

    That is correct. I do not know exactly how the __RENAME() statement
    works, however, I can take a guess. The symbol gettimeofday should still
    be defined and just call the __RENAME directly. The NetBSD people cannot
    expect everybody to rename their functions just for them. There are very
    many more functions that are also __RENAME d

    The Ada needs to change to

    function gettimeofday
    (tv : not null access struct_timeval;
    tz : struct_timezone_ptr) return Integer;
    pragma Import (C, gettimeofday, "gettimeofday50");

    (or maybe "_gettimeofday50", or even "__gettimeofday50" - nm will be
    your friend).

    This is exactly what I want to avoid. I took a look at FreeBSD's libc
    and glibc. None __RENAME their functions (at the very least the ones I
    am interested)... I need to interrogate some developers in IRC.

    I will update the thread if I find anything relevant.

    Regards,
    --
    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephane Carrez@21:1/5 to All on Sun Aug 29 15:08:27 2021
    Hi!

    Simon is right, the symbol used by the Ada import statement must be renamed.

    The reason for the symbol change is some NetBSD libc change in the signature of some system calls.
    Some information in: http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/lib/libc/README

    The __gettimeofday50 is the new function signature while _gettimeofday is the old one.
    The gettimeofday is the weak alias to _gettimeofday and produces the warning.

    Beware that the symbol name that you specify for some import statement is platform specific.
    Having a different symbol names for NetBSD is quite common.

    FreeBSD is different than NetBSD, likewise for OpenBSD :-)

    Thanks for the link to the NetBSD git sources, I'm trying to build and keep you informed in my progress :-)

    Stephane

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to Stephane Carrez on Mon Aug 30 10:14:05 2021
    On 30.08.21 00:08, Stephane Carrez wrote:
    Hi!

    The reason for the symbol change is some NetBSD libc change in the signature of some system calls.
    Some information in: http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/lib/libc/README

    Thank you very much for the link. It does explain quite a few things


    Simon is right, the symbol used by the Ada import statement must be
    renamed.

    The __gettimeofday50 is the new function signature while _gettimeofday is the old one.
    The gettimeofday is the weak alias to _gettimeofday and produces the warning.

    Beware that the symbol name that you specify for some import statement is platform specific.
    Having a different symbol names for NetBSD is quite common.

    However, I still would say that is not right. Here is my
    reasoning/arguments:

    - All programs would have to be corrected just for NetBSD if the linker
    does not do the alias translation automatically.

    - I think the linker is doing the aliasing correctly, meaning, that any
    program that references such functions directly, get linked correctly to
    the actual implementation. After all, the alias is just another
    identifier for the actual function.

    - The linker does not complain when linking these files during the
    compilation of GCC.

    - JMarino's gcc6-aux does not use an special identifier. It also uses
    the "normal" function name directly and it compiles and works. See: https://github.com/NetBSD/pkgsrc/blob/27a8f94efc02f33007d20a4ba6a8aaa369361b95/lang/gcc6-aux/files/diff-ada#L1584
    for another function that gets "renamed". It just works.

    The last point is what makes me _very_ hesitant about this issue. Why
    would it work for JMarino's gcc and not mine? I have compiled JMarino's
    port in the same system.

    I may be missing some other fix in some other part...

    Anyhow, for the time being, I want to get this working. I will try this
    fix and see if it solves the issue.

    Thanks for the link to the NetBSD git sources, I'm trying to build and keep you informed in my progress :-)

    Stephane


    Great!

    Regards,
    --
    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Wright@21:1/5 to Stephane Carrez on Mon Aug 30 08:37:54 2021
    Stephane Carrez <stephane.carrez@gmail.com> writes:

    Simon is right, the symbol used by the Ada import statement must be
    renamed.

    One possibility, with ample precedent, would be to create
    e.g. __gnat_gettimeofday() in gcc/ada/adaint.[ch] and reference that in
    the Ada import statement.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to All on Mon Aug 30 12:24:49 2021
    Actually, I am wrong about the compiler not complaining.

    In the last stage of building GCC I get:

    .o \
    -Wl,-soname,libgnat-10.so \
    -lutil -lm
    /usr/bin/ld: s-osprim.o: in function `system__os_primitives__timed_delay': /usr/pkgsrc/wip/gcc10-aux/work/build/gcc/ada/rts/s-optide.adb:75:
    warning: warning: reference to compatibility nanosleep(); include
    <time.h> to generate correct reference
    /usr/bin/ld: g-socket.o: in function `gnat__sockets__check_selector__2': /usr/pkgsrc/wip/gcc10-aux/work/build/gcc/ada/rts/g-socket.adb:566:
    warning: warning: reference to compatibility select(); include
    <sys/select.h> to generate correct reference
    /usr/bin/ld: g-socthi.o: in function `gnat__sockets__thin__c_socket': /usr/pkgsrc/wip/gcc10-aux/work/build/gcc/ada/rts/g-socthi.adb:388:
    warning: warning: reference to compatibility socket(); include
    <sys/socket.h> for correct reference
    /usr/bin/ld: s-osprim.o: in function `system__os_primitives__clock': /usr/pkgsrc/wip/gcc10-aux/work/build/gcc/ada/rts/s-osprim.adb:91:
    warning: warning: reference to compatibility gettimeofday(); include <sys/time.h> to generate correct reference
    cd rts; `echo "/usr/pkgsrc/wip/gcc10-aux/work/build/./gcc/xgcc -B/usr/pkgsrc/wip/gcc10-aux/work/build/./gcc/ -B/usr/pkg/gcc10/x86_64--netbsd/bin/
    -B/usr/pkg/gcc10/x86_64--netbsd/lib/ -isystem /usr/pkg/gcc10/x86_64--netbsd/include -isystem /usr/pkg/gcc10/x86_64--netbsd/sys-include " \
    | sed -e 's,\./xgcc,../../xgcc,' -e
    's,-B\./,-B../../,'` -shared -g -O2 \
    -fpic \
    -o libgnarl-10.so \
    a-dispat.o a-dynpri.o a-interr.o a-intnam.o a-reatim.o
    a-retide.o a-rttiev.o a-synbar.o a-sytaco.o a-tasatt.o a-taside.o
    a-taster.o g-boubuf.o g-boumai.o g-semaph.o g-signal.o g-tastus.o
    g-thread.o s-inmaop.o s-interr.o s-intman.o s-mudido.o s-osinte.o
    s-proinf.o s-solita.o s-stusta.o s-taenca.o s-taprob.o s-taprop.o
    s-tarest.o s-tasdeb.o s-tasinf.o s-tasini.o s-taskin.o s-taspri.o
    s-tasque.o s-tasres.o s-tasren.o s-tassta.o s-tasuti.o s-taasde.o
    s-tadeca.o s-tadert.o s-tataat.o s-tpinop.o s-tpoben.o s-tpobop.o
    s-tposen.o thread.o \
    -Wl,-soname,libgnarl-10.so \
    -lpthread -lrt
    /usr/bin/ld: s-inmaop.o: in function `system__interrupt_management__operations___elabb': /usr/pkgsrc/wip/gcc10-aux/work/build/gcc/ada/rts/s-inmaop.adb:280:
    warning: warning: reference to compatibility sigaction(); include
    <signal.h> for correct reference
    /usr/bin/ld: s-taprop.o: in function `system__task_primitives__operations__monotonic__monotonic_clockXnn': /usr/pkgsrc/wip/gcc10-aux/work/build/gcc/ada/rts/s-tpopmo.adb:60:
    warning: warning: reference to compatibility clock_gettime(); include
    <time.h> to generate correct reference
    /usr/bin/ld: s-taprop.o: in function `system__task_primitives__operations__monotonic__rt_resolutionXnn': /usr/pkgsrc/wip/gcc10-aux/work/build/gcc/ada/rts/s-tpopmo.adb:76:
    warning: warning: reference to compatibility clock_getres(); include
    <time.h> to generate correct reference
    /usr/bin/ld: s-inmaop.o: in function `system__interrupt_management__operations__thread_block_interrupt': /usr/pkgsrc/wip/gcc10-aux/work/build/gcc/ada/rts/s-inmaop.adb:70:
    warning: warning: reference to compatibility sigaddset(); include
    <signal.h> for correct reference
    /usr/bin/ld: s-inmaop.o: in function `system__interrupt_management__operations___elabb': /usr/pkgsrc/wip/gcc10-aux/work/build/gcc/ada/rts/s-inmaop.adb:314:
    warning: warning: reference to compatibility sigdelset(); include
    <signal.h> for correct reference
    /usr/bin/ld: s-inmaop.o: in function `system__interrupt_management__operations__thread_block_interrupt': /usr/pkgsrc/wip/gcc10-aux/work/build/gcc/ada/rts/s-inmaop.adb:68:
    warning: warning: reference to compatibility sigemptyset(); include
    <signal.h> for correct reference
    /usr/bin/ld: s-inmaop.o: in function `system__interrupt_management__operations___elabb': /usr/pkgsrc/wip/gcc10-aux/work/build/gcc/ada/rts/s-inmaop.adb:295:
    warning: warning: reference to compatibility sigfillset(); include
    <signal.h> for correct reference
    /usr/bin/ld: s-inmaop.o: in function `system__interrupt_management__operations__is_member': /usr/pkgsrc/wip/gcc10-aux/work/build/gcc/ada/rts/s-inmaop.adb:230:
    warning: warning: reference to compatibility sigismember(); include
    <signal.h> for correct reference

    when GCC tries to compile libgnarl... So... lets get to renaming these
    symbols! And there are noticeable many more failures here that during
    ACATS. Maybe I did not get to see all the failures that ACATS was
    generating. However, I do not expect any more warnings than these ones,
    since this the linking of libgnarl from ALL the object files.


    Regards,
    --
    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to All on Mon Aug 30 14:15:18 2021
    Okay. I have a much much clearer picture now.

    I have spoken with a couple of people in the NetBSD IRC. NetBSD has been revamping their ABI, see for example, the UNIX time.

    Some things were going to break. In the case of some of the "standard" functions, they created a RENAME macro to hide this changes. It leaves a
    weak symbol reference that is empty and not resolved by the linker.

    After taking a much closer look into the patch set of JMarino, I
    realised that he had already dealt with this issue. For example, see: https://github.com/NetBSD/pkgsrc/blob/27a8f94efc02f33007d20a4ba6a8aaa369361b95/lang/gcc6-aux/files/diff-ada#L1685

    I think I am going to use the strategy that Simon pointed out. Since
    that would be the most maintainable way for the future... The patching
    is going to be much longer than I expected.

    Regards,

    --
    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to All on Mon Aug 30 20:49:26 2021
    I have good news and bad news.

    The good news is that there are no more linker warnings in the RTS!!! :D

    The bad news:

    1. There are still some symbols missing, but I think they are only
    present within the GNAT libraries. This has to be fixed, but it is not a priority now.

    2. The patches are the most horrible fix anybody ever came with.
    Basically I just modified the __posix files directly to make it work.
    Not very upstream friendly lets say.

    3. Finally, and this is killing me. While running the ACATS test suit, I
    am getting stalled tests. This has happened in the past, where some
    tests just stall and block everything. "No problem" just kill a couple
    of tests.
    However, for the past day, a lot of tests are stalling. Like 1 every 5.
    Heck, some tests that are stalling are compilation tests, meaning that
    one it compiles, it basically does nothing and it doing nothing is
    considered a PASS, for example test

    ,.,. A83A02B ACATS 4.1 21-08-30 18:26:03
    ---- A83A02B CHECK THAT A LABEL IN A NESTED TASK CAN BE IDENTICAL TO A
    LABEL OUTSIDE THE TASK.
    ==== A83A02B PASSED ============================.
    PASS: a83a02b

    passed when I killed it. Some are failures when I kill them, others that are/seem stuck are not. But I think they are all related to the tasking
    system.

    The worst part is that if I leave some tests running indefinitely, such
    as the example test above, my NetBSD VM dies. I increased the memory
    from 4Gb to 7Gb. Some tests, when left to run, kill the machine.

    Since this behaviour is rather recent, I am inclined to believe it is
    some other patch that I applied that is not screwing with GCC/Tests. A
    lot of these tests used to PASS without issue, even with the linking
    problem.

    Simon, have you seen this behaviour? Any tips?

    Regards,
    --
    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Wright@21:1/5 to Fernando Oleo Blanco on Mon Aug 30 20:23:26 2021
    Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

    I have good news and bad news.

    The good news is that there are no more linker warnings in the RTS!!! :D

    The bad news:
    [...]
    3. Finally, and this is killing me. While running the ACATS test suit,
    I am getting stalled tests. This has happened in the past, where some
    tests just stall and block everything. "No problem" just kill a couple
    of tests.
    However, for the past day, a lot of tests are stalling. Like 1 every
    5.
    [...]
    Simon, have you seen this behaviour? Any tips?

    No, very sorry (there was one test which stalled, c425-something I
    think, but only the one, and that was a while ago)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to Simon Wright on Wed Sep 1 11:44:42 2021
    Here is an update. With more good news than bad ones.

    Short summary:

    - Personal reminder, do not run ACATS as root.
    - Lower the timeout of the tests to 30s setting the global environment
    varialbe DEJAGNU_TIMEOUT to 30 (seconds). Some tests will take nearly a
    minute to time out, but it is much better than the 300 seconds default.
    - Increase the stack size (ulimit -s) of the NetBSD x86_64 machine from
    4Mb to 16Mb.
    - I ran ACATS twice. One with the default timeout and the other one with
    a 30 second timeout.

    So, what did I get?

    The bad news is that I am getting 411 unexpected failures. All of the
    failures can be reproduced up until the middle of the C9 section. The
    reason for the "middle of the C9 section" is that I killed the ACATS
    running with the default timeout after more than 18h of running.

    What is the cause of failure? 95% is timeout.
    What about the tests that did not fail because of timeout? One I had to
    kill because gcc got stuck. It was indeed a C* test. To be more
    specific, it was C452003.

    On 30.08.21 21:23, Simon Wright wrote:

    No, very sorry (there was one test which stalled, c425-something I
    think, but only the one, and that was a while ago)

    There were a couple other tests that simply just failed: tests c350a01, c452005, c452006, c611A04, c760a03, just failed "normally".

    Same for c3a0018, but that one is strange, since it did not print what
    that test is trying to test. It just compiles and fail, no information
    about when it got started (time) and the goal of that test. Test c460015
    does the same thing.

    Test c52103x failed with a r "raised STORAGE_ERROR: stack overflow or
    erroneous memory access". So I guess it succeeded? Its definition says:

    ```
    ,.,. C52103X ACATS 4.1 21-08-31 09:31:05
    ---- C52103X CHECK THAT IN ARRAY ASSIGNMENTS AND IN SLICE ASSIGNMENTS,
    THE LENGTHS MUST MATCH; ALSO CHECK WHETHER
    CONSTRAINT_ERROR OR STORAGE_ERROR ARE RAISED FOR LARGE
    ARRAYS.
    - C52103X NO CONSTRAINT_ERROR FOR TYPE WITH 'LENGTH = INTEGER'LAST +
    3.

    raised STORAGE_ERROR : stack overflow or erroneous memory access
    FAIL: c52103x
    ```
    Same error failure for c52104x, c52104y, c650b04 and c93007a. But their description leads me to believe they should not fail that way.

    Tests cb1010c, cb1010d, should fail with a STORAGE_ERROR and they do,
    but they are flagged as FAIL.

    cdd2b04, cxaib05, cxaib06 and cxaib08 fail because of a compilation error:
    ```
    cdd2b04.adb:116:12: stream size for elementary type must be a power of 2
    and at least 8
    gnatmake: "cdd2b04.adb" compilation error
    FAIL: cdd2b04
    ```
    ```
    cxaib05_data.ads:70:04: private object not allowed in preelaborated unit cxaib05_data.ads:70:04: would be legal if pragma
    Preelaborable_Initialization give
    n for "Map" at a-coorma.ads:54, instance at line 66
    cxaib05_data.ads:77:04: private object not allowed in preelaborated unit cxaib05_data.ads:77:04: would be legal if pragma
    Preelaborable_Initialization give
    n for "Map" at a-coorma.ads:54, instance at line 72
    gnatmake: "cxaib05.adb" compilation error
    FAIL: cxaib05
    ```
    ```
    cxaib06_data.ads:69:04: instantiation error at a-cborma.ads:351 cxaib06_data.ads:69:04: object in preelaborated unit has non-static
    default at a-crbltr.ads:74, instance at a-cborma.ads:245, instance at
    line 69
    cxaib06_data.ads:75:04: instantiation error at a-cborma.ads:351 cxaib06_data.ads:75:04: object in preelaborated unit has non-static
    default at a-crbltr.ads:74, instance at a-cborma.ads:245, instance at
    line 75
    gnatmake: "cxaib06.adb" compilation error
    FAIL: cxaib06
    ```
    ```
    cxaib08_data.ads:69:04: instantiation error at a-cbhama.ads:450 cxaib08_data.ads:69:04: object in preelaborated unit has non-static
    default at a-cohata.ads:75, instance at a-cbhama.ads:337, instance at
    line 69
    cxaib08_data.ads:77:04: instantiation error at a-cbhama.ads:450 cxaib08_data.ads:77:04: object in preelaborated unit has non-static
    default at a-cohata.ads:75, instance at a-cbhama.ads:337, instance at
    line 77
    gnatmake: "cxaib08.adb" compilation error
    FAIL: cxaib08
    ```

    ALSO! I get this error at the very beginning:
    ```
    cannot generate code for file b~impbit.ads (package spec)
    gnatmake: "b~impbit.ads" compilation error
    ```

    But then the actual body gets compiled:
    ```
    gcc -c -gnatws -g -O2 -gnato -gnatE b~impbit.adb
    ```

    Okay, too much text and very little insight. So what is the insight?

    I guess that there must be a couple of bad things either in the code or
    in my system that just make about 400 fail because of timeout... I will
    keep on digging. The vast majority of failures take place in the C9
    section. As per
    http://www.ada-auth.org/acats-files/4.1/docs/ACATS-UG.PDF it should be
    about section 9 of the RM. Section 9 is about... You guess it! Tasks and Synchronization!

    So I now know where to look. However, I may need some pointers/extra tests.

    So, Simon, Stephane, here I am leaving you with some goodies, should you
    want to take a look:

    The pkgsrc recipe for gcc10-aux as I currently have it. Maybe the
    tasking errors only happen on my system. You may want to test this
    Stephane: https://irvise.xyz/gcc10-aux.tar.gz

    The ACATS log: https://irvise.xyz/acats.tar.gz


    I will keep on digging. Regards,
    --
    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John R. Marino@21:1/5 to All on Wed Sep 1 06:28:43 2021
    Fernando,
    Maybe you are in luck.
    A friend of mine needs Ravenports (http://www.ravenports.com/) to support NetBSD. Ravenports has the same base compiler for all supported systems. It was GCC 9.3 but I'm the process of completing the transition to GCC 11.2.0. This base compiler has to
    support Ada among other languages.
    Which is a long way of saying I have polish my netbsd patches for that compiler and re-bootstrap it back to NetBSD.
    So I'll be working on this separately (for GCC 11.2, not 10.x).
    My process will be different.
    I cross-compile it on another host, then bring it over to NetBSD and eventfully it builds itself natively.
    I'm awaiting an SSD to arrive which I'll install the latest NetBSD on.
    My gcc6-aux work has been living on: https://github.com/jrmarino/draco
    While the patches are current for FreeBSD, DragonFly, Linux, Solaris and probably Android, I did let OpenBSD and NetBSD support slip.
    But I'm not starting from scratch.

    I'll look over your work.
    And with regard to the test suite, I got all the tests to pass back then: http://www.dragonlace.net/gnataux/netbsd64/

    Which reminds me: I'd only do this for x86_64 platform.
    Regards,
    John



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to John R. Marino on Wed Sep 1 16:58:47 2021
    Hi John,

    continuing our chat over on IRC and repeating a few things so that you
    can refer to this message.

    My work is mostly based on your gcc6-aux port. So you will not find many
    new things here.

    So, what have I actually done?

    - Copied your s-osinte__netbsd.ad{s,b} patches. I initially used the
    patched __freebsd one. However, as you already know, NetBSD changed the
    symbols of some of its libc and sys/* functions.

    - I also ended up reproducing parts of the patches you created, such as
    adding defined (__NetBSD__) where it was missing.

    - Patched the Makefile.rtl to support NetBSD x86_64.

    - Patched the symbols of _nanosleep and __gettimeofday50 in s-osprim__posix.adb.


    This is where I am right now. Most of the ACATS tests that use Tasks,
    fail due to time out. Everything else pretty much "just works" (there
    are a few more failed tests).

    So, what now? I am pretty sure that since gcc6-aux came out and today,
    some functions have been changed, see _nanosleep and __gettimeofday50.
    These two functions specifically, are my suspects. Maybe the input variables/structures got changed and I have not updated them. There are
    also a couple of other symbols in some GNAT libraries that need updating.

    A few more things:
    - The patches I have done are of very bad quality: modifying __posix
    files directly so that they will work only on NetBSD, for example.

    - These patches and are not satisfactory. Since interfacing with the
    NetBSD ABI is now dependent on the C preprocessor to correctly generate
    the symbols, the current approach of hardcoding new symbols is fragile
    and a loosing battle.

    - I think the long term solution is the one proposed by Simon. Creating
    some _gnat__*** C functions that wrap the NetBSD ABI. This is better,
    but does not save us from future functions breaking. A complete fix
    would be to completely _gnat__* all the C functions, which, in my humble opinion is just too much.

    On 01.09.21 15:28, John R. Marino wrote:

    Which reminds me: I'd only do this for x86_64 platform.
    Regards,
    John

    My goal would be to at the very least give support to ARM, ARM64 and
    RISC-V. To be honest with you, I would like it to work on any piece of
    hardware that can be currently bought. Also, not just NetBSD, also
    FreeBSD, DragonflyBSD (already done by you), improved OpenBSD support
    and Haiku. I would also like to see gcc-ada added to Guix, the GNU
    package manager, but that is a completely different story.

    Regards,
    --
    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Wright@21:1/5 to All on Wed Sep 1 22:41:22 2021
    Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

    [failing tests, log output ...]

    With 10.1.0, I see

    *** FAILURES: c250002 c324006 c350a01 c452003 c452005 c452006 c611a04
    c650b04 c760a02 cdd2b03 cdd2b04 cxai001 cxai010 cxaia01 cxaib05
    cxaib06 cxaib08 cxd1003 cxd1004 cxd1005 cxd2006 cxd3001 cxd3002

    (and c452003 was the one whose compilation I had to kill)

    ALSO! I get this error at the very beginning:
    ```
    cannot generate code for file b~impbit.ads (package spec)
    gnatmake: "b~impbit.ads" compilation error
    ```

    Yes, this is an error in my ACATS (attempts to compile specs, fails on
    the first one). Also, should really clear up the b~ files (part of
    executable build).

    So, Simon, Stephane, here I am leaving you with some goodies, should
    you want to take a look:

    Sounds as though John can give you a better steer than I can.

    The ACATS log: https://irvise.xyz/acats.tar.gz

    Thanks.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randy Brukardt@21:1/5 to Fernando Oleo Blanco on Thu Sep 2 17:16:07 2021
    "Fernando Oleo Blanco" <irvise_ml@irvise.xyz> wrote in message news:sgni2a$1ggh$1@gioia.aioe.org...
    ...
    What is the cause of failure? 95% is timeout.
    What about the tests that did not fail because of timeout? One I had to
    kill because gcc got stuck. It was indeed a C* test. To be more specific,
    it was C452003.

    Some GNAT versions have bugs with some newer tests. I believe that is one of them that hangs GNAT. You have to kill GNAT if that happens (yes, it is a
    pain if you are using a script that runs everything). I believe that this
    hang is fixed in the newest versions of GNAT, but that may not be the one
    that you are running.

    Randy.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Wright@21:1/5 to Randy Brukardt on Fri Sep 3 21:18:06 2021
    "Randy Brukardt" <randy@rrsoftware.com> writes:

    "Fernando Oleo Blanco" <irvise_ml@irvise.xyz> wrote in message news:sgni2a$1ggh$1@gioia.aioe.org...
    ...
    What is the cause of failure? 95% is timeout.
    What about the tests that did not fail because of timeout? One I had to
    kill because gcc got stuck. It was indeed a C* test. To be more specific,
    it was C452003.

    Some GNAT versions have bugs with some newer tests. I believe that is one of them that hangs GNAT. You have to kill GNAT if that happens (yes, it is a pain if you are using a script that runs everything). I believe that this hang is fixed in the newest versions of GNAT, but that may not be the one that you are running.

    Fernando is running 10.3, I think: c452003 hangs in 10.1, OK in 11.1.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to John R. Marino on Mon Sep 13 20:49:01 2021
    On 01.09.21 15:28, John R. Marino wrote:
    Which reminds me: I'd only do this for x86_64 platform.
    Regards,
    John

    An update on my side. I have not done any more work on the port.

    However, I have managed to get a Raspberry Pi 3 (aarch64). This would
    allow me (in theory) to test NetBSD, FreeBSD and OpenBSD on the board
    with different architectures. I have NetBSD-earmv6hf "intalled". I could
    try in the future v7 and aarch64. Same for FreeBSD (aarch64/arm{6?,7})
    and OpenBSD (aarch64).

    I wanted to ask you a question John, maybe you can answer it.

    In the Makefile.rtl, there are OS/architecture pairs. For example, there
    is an entry for FreeBSD-x86 and FreeBSD-x86_64. My basic question is,
    why not just have an entry per OS?

    I can already answer that question, some architectures have more support
    that others and the files that they use are different. Okay, I get that.
    But for the previous example with FreeBSD, as far as I can recall, the Makefile.rtl entries were exactly the same (minus the arch matching
    mechanism). If the arch is dropped, then, in theory, the OS would be
    able to compile on any arch without the need of patching. This is
    important if I want to run FreeBSD on arm, for example.

    And the differences I have seen regarding different architectures for
    different OSes, is mostly due to some advance features that the OS
    probably can already expose, so I am a bit surprised. After all, the OS
    is supposed to "hide" the hardware away.

    Anyhow. Regards,

    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dennis Lee Bieber@21:1/5 to All on Mon Sep 13 18:24:04 2021
    On Mon, 13 Sep 2021 20:49:01 +0200, Fernando Oleo Blanco
    <irvise_ml@irvise.xyz> declaimed the following:


    In the Makefile.rtl, there are OS/architecture pairs. For example, there
    is an entry for FreeBSD-x86 and FreeBSD-x86_64. My basic question is,
    why not just have an entry per OS?

    In typical usage, x86 is 32-bit only, x86_64 is 64-bit with support for running 32-bit applications.

    ARM 64-bit should support running 32-bit applications, but may not support the 16-bit "Thumb" instructions which are available in many of the 32-bit models. There is also the question of hardware floating point (which
    may only be 32-bit).

    The difference between 32 and 64 bit is significant when compiling code, as it determines if the code does native 64-bit "long integers" or requires software emulation for such data lengths.



    --
    Wulfraed Dennis Lee Bieber AF6VN
    wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to Dennis Lee Bieber on Fri Sep 17 19:19:54 2021
    On 14.09.21 00:24, Dennis Lee Bieber wrote:
    The difference between 32 and 64 bit is significant when compiling code, as it determines if the code does native 64-bit "long integers" or requires software emulation for such data lengths.


    While I understand that part, I still do not fully understand why do we
    need _exact_ entries for the same OS but different architectures. If we
    are just copypasting code, it would be cleaner, shorter, more
    maintainable and concise to just match over the OS and not the arch.

    And I think there are no architecture dependent bits int the (large) OS
    entries in the Makefile.rtl file. I would expect the compiler to do as
    you say, generate valid code for that architecture. But that would be
    the task of the compiler itself, not the RTL in large OSes (Linux,
    *BSDs), the RTL in those cases just simply translates the
    utilities/tools that the OS provides. Once again, the entries for x86
    and x86_64 of FreeBSD are a exact copy.

    I am not saying that you are wrong, I am just trying to understand the
    why of this multiplication of effort. I saw nothing there that would
    affect the type of compilation as you describe it, like compiler directives.

    Regards,
    --
    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to All on Fri Sep 17 19:36:01 2021
    Another update on my side, this time with a bit more content.

    Following the help provided by Arnaud, I modified the flags with which
    the ACATS's tests get compiled.

    To the gnatmake command I added the -f -a -g -j0 flags.

    -f to force the recompilation of all files needed with the exception of
    the runtime and library files.
    -a is to also force the recompilation of the library & runtime files.
    Whatever is needed.
    -g debugging.
    -j0 ignored by the ACATS suite provided by Simon (or so says the
    documentation in the shell file).

    This flags make the compilation much slower, obviously, since nearly for
    every test the entire Ada library needs to be recompiled. However, this
    started to give me a much better insight on what was going on. Specially
    since now I could debug the failing tests.

    I noticed that the first test I started debugging was stuck in a loop
    related to task management. This would explain why I was getting so many
    tests failing with timeouts. Great, but I could only get so much insight.

    Arnaud, once again came to the rescue and indicated that I should add
    the -gnata flag.

    -gnata is to enable assertions.

    And yes, now the tests were finally failing in a meaningful manner. I
    have written the assertions I have found that failed. Remember, I am
    using GCC 10.3 with the patch set that is available in my website. You
    can find it in one of the messages I have sent in this thread.

    So, what do we get?

    System.Assertions. Assert_Failure in s-tassta.adb:1643 (very common everywhere), s-tpopmo.adb:213 (fairly common) and s-taprop.adb:463
    (common in the c9 section).

    Storage_Error in s-intman.adb:136

    Stack overflow or erroneous memory access in a few tests. I got no
    pointer on where it was happening.

    And still some timeouts, but I think they are related to the first
    assertion mentioned.

    The "strange" (not that much) is that I have not touched any of these
    files. I will see where they are used in the compiler, how they are used
    and if the issues are related with how NetBSD handles some functions/standards... The s-tassta.adb problem I know is 100% related
    to POSIX Threads. Maybe the issue is in the POSIX Threads handling or
    maybe not.


    I will keep on digging. Regards,
    --
    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to All on Sat Sep 18 18:39:33 2021
    Welp, I have another "major" update...

    I talked to #netbsd and asked if there was anything I should be aware
    when dealing with pthreads in NetBSD. I did not get any much advice, but
    I was told that there were some issues with lwps that were fixed. Lwp
    stands for Lightweight processes.

    I went ahead and started debugging a failing test. After running the
    program a few times in gdb, I got a message related to a potential issue
    with the lwp (this test was using tasking).

    Interesting I told myself, but I did not dig any further. Here was the
    issue. I was using an installation of NetBSD that is modified, it is the
    OS108 "distro". It is created by a fellow Ada lover Jay Patelani. The
    thing is that OS108 as it stood when I installed, was based on a
    development version of NetBSD 9.1. I decided that if there were
    potential issues because of the development version, I did not want to
    find out; specially after being warned about lwps.

    So I updated to NetBSD 9.2, the latest stable release. And I ran the
    tests once again............ And guess what. I am getting the exact same failing tests, but, for the time being (the tests are still running),
    all have failed with the same raised exception. And this exception is
    "new", it was not part of the ones I named in the previous email.

    It is "raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : s-taprop.adb:659"
    s-taprop was already raising an exception before, but in line 463 and
    just in some cases. Let me repeat it once again, all tests that I have
    seen so far, that fail with an exception that is not related to Storage,
    are failing only with this "new" one. That is a great thing in terms of narrowing down where the potential issue may lie. It also means that
    much of my work is not really that helpful... And maybe even that it has
    always been working, and I just need to recompile GCC... Oh no... That
    idea just came up in my head while typing...

    I will be back in about 6 hours.

    Regards,
    --
    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to All on Wed Sep 22 22:05:59 2021
    Another followup. This may require a new thread, but we will see.

    So, very long story short. The assertion failure that I was getting, s-taprop.adb:659 was because "pthread_setschedparam" was returning a
    failure.

    After digging up a bit, I noticed that the SCHED_{OTHER,RR,FIFO}
    constants in s-osint__netbsd (taken from J. Marino) were wrong.

    I corrected the values and expected GNAT to finally work. It did not.

    The error being returned now by "pthread_setschedparam" was, however, different. The error was that the input values were invalid. I checked
    the input values, all seemed correct. I decided to take a look at the
    validity of the "Priority" variable, as I did not know anything about
    it. Which values could it take?

    Unsurprisingly, the priority for the task may take different values
    depending on the scheduler (SCHED_{OTHER,RR,FIFO}) and the OS. The link
    I found that showed/explained this is https://stackoverflow.com/questions/10657970/pthread-sched-get-priority-min-max-implementation-for-sched-other-sched-fifo

    So I ran the code in the link to see if the Priority value was valid in
    NetBSD and... Oh... Min: -1 and Max: -1... Reading the POSIX manual it
    says that -1 is an error... Was I getting an error code?

    I went into #netbsd, asked aaaaandd... No, it is no error, those are the
    actual values that NetBSD uses as valid ones... So NetBSD is _not_ POSIX compilant in this case... More quirks to take into account... However,
    this thing is going to get discussed with NetBSD people.

    But this is not where it ends...

    The priority number I was getting is the default in libgnat/system.ads: gcc/ada/libgnat/system.ads: Default_Priority : constant Priority := 15;

    Some OSs/architectures have different defaults, but 15 seems to be the
    most common one. However, this causes another question. If the valid
    range is 0..0 (as in Ubuntu), how does GNAT know which priority value to
    use? I have more or less followed the flow from where the value of
    Priority gets set and I have not found anything that caught my eye. So I
    would expect that in Ubuntu (for example) a Priority of 15 would create
    an error... But it does not (GNAT works fine there). Strange... This
    will require further research...

    BUT that is not all. In GDB I manually changed the value of Priority to
    -1 to see if it would work... And it did! But then when I told it to
    continue, it error out in another place, s-tpopmo.adb:213. That is no
    new error, in previous ACATS runs I was getting it in some places. And
    it seems related to the "adafinal" procedure, which is run when a
    program is done. Some tests were failing in adafinal while being
    debugged in gdb, and if I remember correctly, they were also failing in s-tpopmo.adb...

    This little project of mine is going deeper and deeper each week... Arg...

    Cheers,
    --
    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Wright@21:1/5 to All on Wed Sep 22 21:57:23 2021
    *Deeply* impressed by the effort you're putting into this!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luke A. Guest@21:1/5 to Fernando Oleo Blanco on Thu Sep 23 09:04:31 2021
    On 22/09/2021 21:05, Fernando Oleo Blanco wrote:

    So I ran the code in the link to see if the Priority value was valid in NetBSD and... Oh... Min: -1 and Max: -1... Reading the POSIX manual it
    says that -1 is an error... Was I getting an error code?

    I went into #netbsd, asked aaaaandd... No, it is no error, those are the actual values that NetBSD uses as valid ones... So NetBSD is _not_ POSIX compilant in this case... More quirks to take into account... However,
    this thing is going to get discussed with NetBSD people.

    But this is not where it ends...

    The priority number I was getting is the default in libgnat/system.ads: gcc/ada/libgnat/system.ads:   Default_Priority : constant Priority := 15;

    system.ads should be specific to each platform and you can change it to
    reflect that.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kevin Chadwick@21:1/5 to All on Thu Sep 23 03:48:37 2021
    Just wondering if any of these patches are useful?
    OpenBSD was forked from NetBSD, but that was a long time ago.

    "https://cvsweb.openbsd.org/ports/lang/gcc/11/patches/"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to Kevin Chadwick on Thu Sep 23 19:01:42 2021
    On 23.09.21 12:48, Kevin Chadwick wrote:
    Just wondering if any of these patches are useful?
    OpenBSD was forked from NetBSD, but that was a long time ago.

    "https://cvsweb.openbsd.org/ports/lang/gcc/11/patches/"


    I took a look. That is some nice patch work. However, sadly, not much
    can be derived from it. It is pretty similar to what is already there or
    that I patched. For example, the basic system.adb implementation is
    pretty similar to the customized ones. The rest is just like what J.
    Marino and I have done...

    But thanks nonetheless!
    --
    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to Luke A. Guest on Thu Sep 23 19:04:27 2021
    On 23.09.21 10:04, Luke A. Guest wrote:


    system.ads should be specific to each platform and you can change it to reflect that.


    Yup. But other systems also have defaults that are different from what
    they support. For example, the patches of OpenBSD also use a default
    priority of 15, same in Linux (x86). But these priorities are out of
    range. I am now debugging the ACATS suit in my computer to try to see
    what is going on in Linux and why does it not fail (or if the value is
    changed from the default one).

    Regards,
    --
    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to All on Thu Sep 23 21:53:47 2021
    Okay, so another short blog post. This is going to be a bit of a fucking
    rant.

    So... remember when I said that NetBSD expected a priority value of -1
    when using SCHED_ODER? And that that was not POSIX compilant? Well,
    after a nice conversation in #netbsd, it has been decided to escalate
    this matter into a PR/ML discussion. All that good :)

    But the question on how does Linux work then? Remained... So I ran the
    ACATS suite with debugging symbols, recompilation and assertions to
    check. And guess what?

    Let the code speak:


    else

    Param.sched_priority := 0;

    Result :=

    pthread_setschedparam

    (T.Common.LL.Thread,

    SCHED_OTHER, Param'Access);

    end if;


    pragma Assert (Result in 0 | EPERM | EINVAL);

    end Set_Priority;

    So the Set_Priority function receives the Default_Priority value, which
    I think was 48. But when it goes into the actual branch, it knows that
    that default value is stupid and discards it (sets it to 0). That would
    be all nice and dandy, but here is the problem, 0 is a valid value
    because most OS/arches use it, there is no reason 0 is valid (as per POSIX).

    And what really gets me is that Pragma... Whomever wrote it probably was getting errors and decided that that was fine. EPERM? EINVAL? Not my
    problem! No wonder there is a specific s-taprop__linux.adb...


    So here we are. NetBSD is not POSIX compliant (min and max SCHED_OTHER
    priority is -1, which is an error code for the function that should
    return it), and Linux hardcodes it. Amazing, just amazing...


    My solution? Email the NetBSD people. But that won't be enough. So I am thinking in patching the s-taprop__posix.adb file to try it with the
    default priority, if it fails, with 0, if it fails, with -1 for NetBSD...


    Oh well... I thought that the state of GNAT was better... Anyhow, regards,
    --
    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Wright@21:1/5 to Fernando Oleo Blanco on Fri Sep 24 08:48:34 2021
    Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

    pragma Assert (Result in 0 | EPERM | EINVAL);

    EINVAL was added 5 years ago. The others have been there for 20 years
    (when Ada was added to FSF GCC, according to git blame in https://github.com/gcc-mirror/gcc).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fernando Oleo Blanco@21:1/5 to Simon Wright on Fri Sep 24 11:44:56 2021
    On 24.09.21 09:48, Simon Wright wrote:
    Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

    pragma Assert (Result in 0 | EPERM | EINVAL);

    EINVAL was added 5 years ago. The others have been there for 20 years
    (when Ada was added to FSF GCC, according to git blame in https://github.com/gcc-mirror/gcc).


    Thank you for your reply Simon. But I think I have understood it now.

    It really does not matter what that function "pthread_set..." returns,
    even if it is an error.

    SCHED_OTHER is the default scheduler FIFO and RR are more RTOS-like and
    are generally reserved for root. I would expect that most programs that
    spawn threads generally do not care about the priority, since that is
    managed by the OS.

    That would mean that even if that function fails, once the program is
    spawns the actual process, the OS just does it, independently of what
    the program tried to do. That would explain why it works in OpenBSD,
    FreeBSD etc, and why I was not getting this error before I added
    assertions. Because it really does not matter.

    I am still very salty about code that knows it fails, but does
    nothing/is not cleaned up...

    I patched however that function and reran ACATS.

    Now, I am no longer getting that assertion failure (s-taprop.adb:659).
    And at the very least the test I worked with (a83a02b) is now fully
    fixed. However, now, other assertion failures in a couple other places
    are taking place, primarily s-tassta.adb:1643, which is related to

    pragma Assert (Self_ID.Common.Wait_Count = 0);

    Which, from the comments, the master should not have any slaves but it
    does somehow (mine is returning a 1). The s-tassta.adb file is shared
    among all systems (there are no OS specific files). Another common error
    is s-taprop.adb:463 and STORAGE_ERROR : s-intman.adb:136


    I will keep on debugging.........
    --
    Fernando Oleo Blanco
    https://irvise.xyz

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)