comp.lang.ada
 help / color / mirror / Atom feed
* Help: Ada in NetBSD
@ 2021-08-29 11:06 Fernando Oleo Blanco
  2021-08-29 13:19 ` Stephane Carrez
                   ` (2 more replies)
  0 siblings, 3 replies; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-08-29 11:06 UTC (permalink / raw)


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 (__linux__) || defined (__sun__) || defined (__FreeBSD__) \
-  || defined (__APPLE__)
+  || defined (__APPLE__) || defined (__NetBSD__)
  /* section for platforms having ftello/fseeko */

  __int64

--- gcc/ada/init.c.orig	2021-08-28 20:28:13.261558335 +0000
+++ gcc/ada/init.c	2021-08-28 20:29:48.573288829 +0000
@@ -2183,6 +2183,8 @@

  #include <signal.h>
  #include <unistd.h>
+#include <time.h>
+#include <sys/time.h>

  static void
  __gnat_error_handler (int sig)

--- gcc/ada/s-oscons-tmplt.c.orig	2021-08-28 18:50:50.086632028 +0000
+++ gcc/ada/s-oscons-tmplt.c	2021-08-28 18:53:35.037358487 +0000
@@ -406,9 +406,11 @@

  */

-/* ioctl(2) requests are "int" in UNIX, but "unsigned long" on FreeBSD */
+/* ioctl(2) requests are "int" in UNIX, but "unsigned long" on FreeBSD
+   and NetBSD
+*/

-#if defined (__FreeBSD__) || defined (__DragonFly__)
+#if defined (__FreeBSD__) || defined (__DragonFly__) || defined 
(__NetBSD__)
  # define CNI CNU
  # define IOCTL_Req_T "Interfaces.C.unsigned"
  #else
@@ -1020,7 +1022,8 @@

  */

-#if defined (__FreeBSD__) || defined (__linux__) || defined (__DragonFly__)
+#if defined (__FreeBSD__) || defined (__linux__) || defined 
(__DragonFly__) \
+  || defined (__NetBSD__)
  # define PTY_Library "-lutil"
  #else
  # define PTY_Library ""
@@ -1833,7 +1836,8 @@

  #if defined(__linux__) || defined(__FreeBSD__) \
   || (defined(_AIX) && defined(_AIXVERSION_530)) \
- || defined(__DragonFly__) || defined(__QNX__)
+ || defined(__DragonFly__) || defined(__QNX__) \
+ || defined (__NetBSD__)
  /** On these platforms use system provided monotonic clock instead of
   ** the default CLOCK_REALTIME. We then need to set up cond var attributes
   ** appropriately (see thread.c).

--- gcc/ada/sysdep.c.orig	2021-08-28 13:11:25.681014624 +0000
+++ gcc/ada/sysdep.c	2021-08-28 13:21:14.748176113 +0000
@@ -320,7 +320,7 @@
    || (defined (__svr4__) && defined (__i386__)) || defined (__Lynx__) \
    || defined (__CYGWIN__) || defined (__FreeBSD__) || defined 
(__OpenBSD__) \
    || defined (__GLIBC__) || defined (__APPLE__) || defined 
(__DragonFly__) \
-  || defined (__QNX__)
+  || defined (__QNX__) || defined (__NetBSD__)

  # ifdef __MINGW32__
  #  if OLD_MINGW
@@ -373,7 +373,7 @@
      || defined (_AIX) || (defined (__svr4__) && defined (__i386__)) \
      || defined (__Lynx__) || defined (__FreeBSD__) || defined 
(__OpenBSD__) \
      || defined (__GLIBC__) || defined (__APPLE__) || defined 
(__DragonFly__) \
-    || defined (__QNX__)
+    || defined (__QNX__) || defined (__NetBSD__)
    char c;
    int nread;
    int good_one = 0;
@@ -394,7 +394,7 @@
      || defined (_AIX) || (defined (__svr4__) && defined (__i386__)) \
      || defined (__Lynx__) || defined (__FreeBSD__) || defined 
(__OpenBSD__) \
      || defined (__GLIBC__) || defined (__APPLE__) || defined 
(__DragonFly__) \
-    || defined (__QNX__)
+    || defined (__QNX__) || defined (__NetBSD__)
        eof_ch = termios_rec.c_cc[VEOF];

        /* If waiting (i.e. Get_Immediate (Char)), set MIN = 1 and wait for
@@ -831,7 +831,7 @@

  #elif defined (__APPLE__) || defined (__FreeBSD__) || defined 
(__linux__) \
    || defined (__GLIBC__) || defined (__DragonFly__) || defined 
(__OpenBSD__) \
-  || defined (__DJGPP__) || defined (__QNX__)
+  || defined (__DJGPP__) || defined (__QNX__) || defined (__NetBSD__)
  {
    localtime_r (timer, &tp);
    *off = tp.tm_gmtoff;

-------

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-08-29 11:06 Help: Ada in NetBSD Fernando Oleo Blanco
@ 2021-08-29 13:19 ` Stephane Carrez
  2021-08-29 18:08   ` Fernando Oleo Blanco
  2021-08-29 17:34 ` Simon Wright
  2021-09-01 13:28 ` John R. Marino
  2 siblings, 1 reply; 34+ messages in thread
From: Stephane Carrez @ 2021-08-29 13:19 UTC (permalink / raw)


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


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-08-29 11:06 Help: Ada in NetBSD Fernando Oleo Blanco
  2021-08-29 13:19 ` Stephane Carrez
@ 2021-08-29 17:34 ` Simon Wright
  2021-08-29 17:45   ` Fernando Oleo Blanco
  2021-09-01 13:28 ` John R. Marino
  2 siblings, 1 reply; 34+ messages in thread
From: Simon Wright @ 2021-08-29 17:34 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-08-29 17:34 ` Simon Wright
@ 2021-08-29 17:45   ` Fernando Oleo Blanco
  0 siblings, 0 replies; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-08-29 17:45 UTC (permalink / raw)


Thanks Simon, I will take into account this failures when I get to the 
final testing round.

Regards,

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-08-29 13:19 ` Stephane Carrez
@ 2021-08-29 18:08   ` Fernando Oleo Blanco
  2021-08-29 18:25     ` Simon Wright
  0 siblings, 1 reply; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-08-29 18:08 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-08-29 18:08   ` Fernando Oleo Blanco
@ 2021-08-29 18:25     ` Simon Wright
  2021-08-29 20:36       ` Fernando Oleo Blanco
  0 siblings, 1 reply; 34+ messages in thread
From: Simon Wright @ 2021-08-29 18:25 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-08-29 18:25     ` Simon Wright
@ 2021-08-29 20:36       ` Fernando Oleo Blanco
  2021-08-29 22:08         ` Stephane Carrez
  0 siblings, 1 reply; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-08-29 20:36 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-08-29 20:36       ` Fernando Oleo Blanco
@ 2021-08-29 22:08         ` Stephane Carrez
  2021-08-30  7:37           ` Simon Wright
  2021-08-30  8:14           ` Fernando Oleo Blanco
  0 siblings, 2 replies; 34+ messages in thread
From: Stephane Carrez @ 2021-08-29 22:08 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-08-29 22:08         ` Stephane Carrez
@ 2021-08-30  7:37           ` Simon Wright
  2021-08-30  8:14           ` Fernando Oleo Blanco
  1 sibling, 0 replies; 34+ messages in thread
From: Simon Wright @ 2021-08-30  7:37 UTC (permalink / raw)


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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-08-29 22:08         ` Stephane Carrez
  2021-08-30  7:37           ` Simon Wright
@ 2021-08-30  8:14           ` Fernando Oleo Blanco
  2021-08-30 10:24             ` Fernando Oleo Blanco
  1 sibling, 1 reply; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-08-30  8:14 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-08-30  8:14           ` Fernando Oleo Blanco
@ 2021-08-30 10:24             ` Fernando Oleo Blanco
  2021-08-30 12:15               ` Fernando Oleo Blanco
  0 siblings, 1 reply; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-08-30 10:24 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-08-30 10:24             ` Fernando Oleo Blanco
@ 2021-08-30 12:15               ` Fernando Oleo Blanco
  2021-08-30 18:49                 ` Fernando Oleo Blanco
  0 siblings, 1 reply; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-08-30 12:15 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-08-30 12:15               ` Fernando Oleo Blanco
@ 2021-08-30 18:49                 ` Fernando Oleo Blanco
  2021-08-30 19:23                   ` Simon Wright
  0 siblings, 1 reply; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-08-30 18:49 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-08-30 18:49                 ` Fernando Oleo Blanco
@ 2021-08-30 19:23                   ` Simon Wright
  2021-09-01  9:44                     ` Fernando Oleo Blanco
  0 siblings, 1 reply; 34+ messages in thread
From: Simon Wright @ 2021-08-30 19:23 UTC (permalink / raw)


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)

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-08-30 19:23                   ` Simon Wright
@ 2021-09-01  9:44                     ` Fernando Oleo Blanco
  2021-09-01 21:41                       ` Simon Wright
  2021-09-02 22:16                       ` Randy Brukardt
  0 siblings, 2 replies; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-09-01  9:44 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-08-29 11:06 Help: Ada in NetBSD Fernando Oleo Blanco
  2021-08-29 13:19 ` Stephane Carrez
  2021-08-29 17:34 ` Simon Wright
@ 2021-09-01 13:28 ` John R. Marino
  2021-09-01 14:58   ` Fernando Oleo Blanco
  2021-09-13 18:49   ` Fernando Oleo Blanco
  2 siblings, 2 replies; 34+ messages in thread
From: John R. Marino @ 2021-09-01 13:28 UTC (permalink / raw)


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

 

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-01 13:28 ` John R. Marino
@ 2021-09-01 14:58   ` Fernando Oleo Blanco
  2021-09-17 17:36     ` Fernando Oleo Blanco
  2021-09-13 18:49   ` Fernando Oleo Blanco
  1 sibling, 1 reply; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-09-01 14:58 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-01  9:44                     ` Fernando Oleo Blanco
@ 2021-09-01 21:41                       ` Simon Wright
  2021-09-02 22:16                       ` Randy Brukardt
  1 sibling, 0 replies; 34+ messages in thread
From: Simon Wright @ 2021-09-01 21:41 UTC (permalink / raw)


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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-01  9:44                     ` Fernando Oleo Blanco
  2021-09-01 21:41                       ` Simon Wright
@ 2021-09-02 22:16                       ` Randy Brukardt
  2021-09-03 20:18                         ` Simon Wright
  1 sibling, 1 reply; 34+ messages in thread
From: Randy Brukardt @ 2021-09-02 22:16 UTC (permalink / raw)


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



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-02 22:16                       ` Randy Brukardt
@ 2021-09-03 20:18                         ` Simon Wright
  0 siblings, 0 replies; 34+ messages in thread
From: Simon Wright @ 2021-09-03 20:18 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-01 13:28 ` John R. Marino
  2021-09-01 14:58   ` Fernando Oleo Blanco
@ 2021-09-13 18:49   ` Fernando Oleo Blanco
  2021-09-13 22:24     ` Dennis Lee Bieber
  1 sibling, 1 reply; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-09-13 18:49 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-13 18:49   ` Fernando Oleo Blanco
@ 2021-09-13 22:24     ` Dennis Lee Bieber
  2021-09-17 17:19       ` Fernando Oleo Blanco
  0 siblings, 1 reply; 34+ messages in thread
From: Dennis Lee Bieber @ 2021-09-13 22:24 UTC (permalink / raw)


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/

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-13 22:24     ` Dennis Lee Bieber
@ 2021-09-17 17:19       ` Fernando Oleo Blanco
  0 siblings, 0 replies; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-09-17 17:19 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-01 14:58   ` Fernando Oleo Blanco
@ 2021-09-17 17:36     ` Fernando Oleo Blanco
  2021-09-18 16:39       ` Fernando Oleo Blanco
  0 siblings, 1 reply; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-09-17 17:36 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-17 17:36     ` Fernando Oleo Blanco
@ 2021-09-18 16:39       ` Fernando Oleo Blanco
  2021-09-22 20:05         ` Fernando Oleo Blanco
  0 siblings, 1 reply; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-09-18 16:39 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-18 16:39       ` Fernando Oleo Blanco
@ 2021-09-22 20:05         ` Fernando Oleo Blanco
  2021-09-22 20:57           ` Simon Wright
                             ` (2 more replies)
  0 siblings, 3 replies; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-09-22 20:05 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-22 20:05         ` Fernando Oleo Blanco
@ 2021-09-22 20:57           ` Simon Wright
  2021-09-23  8:04           ` Luke A. Guest
  2021-09-23 19:53           ` Fernando Oleo Blanco
  2 siblings, 0 replies; 34+ messages in thread
From: Simon Wright @ 2021-09-22 20:57 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-22 20:05         ` Fernando Oleo Blanco
  2021-09-22 20:57           ` Simon Wright
@ 2021-09-23  8:04           ` Luke A. Guest
  2021-09-23 10:48             ` Kevin Chadwick
  2021-09-23 17:04             ` Fernando Oleo Blanco
  2021-09-23 19:53           ` Fernando Oleo Blanco
  2 siblings, 2 replies; 34+ messages in thread
From: Luke A. Guest @ 2021-09-23  8:04 UTC (permalink / raw)


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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-23  8:04           ` Luke A. Guest
@ 2021-09-23 10:48             ` Kevin Chadwick
  2021-09-23 17:01               ` Fernando Oleo Blanco
  2021-09-23 17:04             ` Fernando Oleo Blanco
  1 sibling, 1 reply; 34+ messages in thread
From: Kevin Chadwick @ 2021-09-23 10:48 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-23 10:48             ` Kevin Chadwick
@ 2021-09-23 17:01               ` Fernando Oleo Blanco
  0 siblings, 0 replies; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-09-23 17:01 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-23  8:04           ` Luke A. Guest
  2021-09-23 10:48             ` Kevin Chadwick
@ 2021-09-23 17:04             ` Fernando Oleo Blanco
  1 sibling, 0 replies; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-09-23 17:04 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-22 20:05         ` Fernando Oleo Blanco
  2021-09-22 20:57           ` Simon Wright
  2021-09-23  8:04           ` Luke A. Guest
@ 2021-09-23 19:53           ` Fernando Oleo Blanco
  2021-09-24  7:48             ` Simon Wright
  2 siblings, 1 reply; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-09-23 19:53 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-23 19:53           ` Fernando Oleo Blanco
@ 2021-09-24  7:48             ` Simon Wright
  2021-09-24  9:44               ` Fernando Oleo Blanco
  0 siblings, 1 reply; 34+ messages in thread
From: Simon Wright @ 2021-09-24  7:48 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Help: Ada in NetBSD
  2021-09-24  7:48             ` Simon Wright
@ 2021-09-24  9:44               ` Fernando Oleo Blanco
  0 siblings, 0 replies; 34+ messages in thread
From: Fernando Oleo Blanco @ 2021-09-24  9:44 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2021-09-24  9:44 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-29 11:06 Help: Ada in NetBSD Fernando Oleo Blanco
2021-08-29 13:19 ` Stephane Carrez
2021-08-29 18:08   ` Fernando Oleo Blanco
2021-08-29 18:25     ` Simon Wright
2021-08-29 20:36       ` Fernando Oleo Blanco
2021-08-29 22:08         ` Stephane Carrez
2021-08-30  7:37           ` Simon Wright
2021-08-30  8:14           ` Fernando Oleo Blanco
2021-08-30 10:24             ` Fernando Oleo Blanco
2021-08-30 12:15               ` Fernando Oleo Blanco
2021-08-30 18:49                 ` Fernando Oleo Blanco
2021-08-30 19:23                   ` Simon Wright
2021-09-01  9:44                     ` Fernando Oleo Blanco
2021-09-01 21:41                       ` Simon Wright
2021-09-02 22:16                       ` Randy Brukardt
2021-09-03 20:18                         ` Simon Wright
2021-08-29 17:34 ` Simon Wright
2021-08-29 17:45   ` Fernando Oleo Blanco
2021-09-01 13:28 ` John R. Marino
2021-09-01 14:58   ` Fernando Oleo Blanco
2021-09-17 17:36     ` Fernando Oleo Blanco
2021-09-18 16:39       ` Fernando Oleo Blanco
2021-09-22 20:05         ` Fernando Oleo Blanco
2021-09-22 20:57           ` Simon Wright
2021-09-23  8:04           ` Luke A. Guest
2021-09-23 10:48             ` Kevin Chadwick
2021-09-23 17:01               ` Fernando Oleo Blanco
2021-09-23 17:04             ` Fernando Oleo Blanco
2021-09-23 19:53           ` Fernando Oleo Blanco
2021-09-24  7:48             ` Simon Wright
2021-09-24  9:44               ` Fernando Oleo Blanco
2021-09-13 18:49   ` Fernando Oleo Blanco
2021-09-13 22:24     ` Dennis Lee Bieber
2021-09-17 17:19       ` Fernando Oleo Blanco

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox