Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.ada > #49352 > unrolled thread

Help: Ada in NetBSD

Back to article view | Back to comp.lang.ada

Contents

  Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-08-29 13:06 +0200
    Re: Help: Ada in NetBSD Stephane Carrez <stephane.carrez@gmail.com> - 2021-08-29 06:19 -0700
      Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-08-29 20:08 +0200
        Re: Help: Ada in NetBSD Simon Wright <simon@pushface.org> - 2021-08-29 19:25 +0100
          Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-08-29 22:36 +0200
            Re: Help: Ada in NetBSD Stephane Carrez <stephane.carrez@gmail.com> - 2021-08-29 15:08 -0700
              Re: Help: Ada in NetBSD Simon Wright <simon@pushface.org> - 2021-08-30 08:37 +0100
              Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-08-30 10:14 +0200
                Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-08-30 12:24 +0200
                  Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-08-30 14:15 +0200
                    Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-08-30 20:49 +0200
                      Re: Help: Ada in NetBSD Simon Wright <simon@pushface.org> - 2021-08-30 20:23 +0100
                        Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-09-01 11:44 +0200
                          Re: Help: Ada in NetBSD Simon Wright <simon@pushface.org> - 2021-09-01 22:41 +0100
                          Re: Help: Ada in NetBSD "Randy Brukardt" <randy@rrsoftware.com> - 2021-09-02 17:16 -0500
                            Re: Help: Ada in NetBSD Simon Wright <simon@pushface.org> - 2021-09-03 21:18 +0100
    Re: Help: Ada in NetBSD Simon Wright <simon@pushface.org> - 2021-08-29 18:34 +0100
      Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-08-29 19:45 +0200
    Re: Help: Ada in NetBSD "John R. Marino" <mfl-commissioner@marino.st> - 2021-09-01 06:28 -0700
      Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-09-01 16:58 +0200
        Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-09-17 19:36 +0200
          Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-09-18 18:39 +0200
            Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-09-22 22:05 +0200
              Re: Help: Ada in NetBSD Simon Wright <simon@pushface.org> - 2021-09-22 21:57 +0100
              Re: Help: Ada in NetBSD "Luke A. Guest" <laguest@archeia.com> - 2021-09-23 09:04 +0100
                Re: Help: Ada in NetBSD Kevin Chadwick <m8il1ists@gmail.com> - 2021-09-23 03:48 -0700
                  Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-09-23 19:01 +0200
                Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-09-23 19:04 +0200
              Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-09-23 21:53 +0200
                Re: Help: Ada in NetBSD Simon Wright <simon@pushface.org> - 2021-09-24 08:48 +0100
                  Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-09-24 11:44 +0200
      Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-09-13 20:49 +0200
        Re: Help: Ada in NetBSD Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-09-13 18:24 -0400
          Re: Help: Ada in NetBSD Fernando Oleo Blanco <irvise_ml@irvise.xyz> - 2021-09-17 19:19 +0200

Page 1 of 2  [1] 2  Next page →

#49352 — Help: Ada in NetBSD

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

[toc] | [next] | [standalone]

#49353

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

[toc] | [prev] | [next] | [standalone]

#49356

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

[toc] | [prev] | [next] | [standalone]

#49357

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

[toc] | [prev] | [next] | [standalone]

#49359

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

[toc] | [prev] | [next] | [standalone]

#49360

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

[toc] | [prev] | [next] | [standalone]

#49361

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.

[toc] | [prev] | [next] | [standalone]

#49363

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

[toc] | [prev] | [next] | [standalone]

#49365

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

[toc] | [prev] | [next] | [standalone]

#49366

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

[toc] | [prev] | [next] | [standalone]

#49367

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

[toc] | [prev] | [next] | [standalone]

#49368

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)

[toc] | [prev] | [next] | [standalone]

#49374

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

[toc] | [prev] | [next] | [standalone]

#49382

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.

[toc] | [prev] | [next] | [standalone]

#49391

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

[toc] | [prev] | [next] | [standalone]

#49404

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

[toc] | [prev] | [next] | [standalone]

#49354

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

[toc] | [prev] | [next] | [standalone]

#49355

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

Regards,

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

[toc] | [prev] | [next] | [standalone]

#49375

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

 

[toc] | [prev] | [next] | [standalone]

#49376

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.ada

csiph-web