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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

"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)

"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)

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)

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)

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)

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)

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)

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)

*Deeply* impressed by the effort you're putting into this!

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

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)

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)

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)

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)

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)

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)

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)