Re: Ada and signal handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Le 09/10/2019 à 18:23, Kacvinsky, Tom a écrit :

-----Original Message-----
From: gcc-help-owner@xxxxxxxxxxx <gcc-help-owner@xxxxxxxxxxx> On
Behalf Of Didier Kryn
Sent: Wednesday, October 9, 2019 4:36 AM
To: gcc-help@xxxxxxxxxxx
Subject: Re: Ada and signal handling

Le 07/10/2019 à 18:06, Kacvinsky, Tom a écrit :
I am using GCC 8.3.0 with the Ada tool chain, but cannot seem to find
a way of unsetting the signal handlers the Ada run time inserts.  I do
not want Ada to handle signals for me as I am in a missed C/C++/Ada
code base and would prefer to have the C signal handlers used.

Any ideas?

Thanks,

Tom
      Hello Tom.

      I subscribed to this list (and gcc) primarily to get help from Gnat people but
never received any reply. I'm sure they don't read this list and I don't know
how to reach them.

      I've no authority to reply on this list. I've just been a user of Ada and
managed sometimes to play with signals.

      Ada's API for signals is the package Ada.Interrupts (see
/usr/lib/gcc/x86_64-linux-gnu/6/adainclude/a-interr.ads or the like
depending on the arch and version of gcc). You will see that Ada provisions
the possibility for the runtime to reserve some signals - ie prevent user's
action on these.

      More details can be found in lower level packages like
System.Interrupt_Management (s-intman.ads and s-intman.adb) in which
you can see which signals are reserved by Gnat's runtime library.

      The usual system-raised signals are mapped as follows:

       case signo is
           when SIGFPE =>
              raise Constraint_Error;
           when SIGILL =>
              raise Program_Error;
           when SIGSEGV =>
              raise Storage_Error;
           when SIGBUS =>
              raise Storage_Error;
           when others =>
null;
        end case;

      Gnat reserves yet another signal to abort tasks.

      SIGINT is also reserved although there must be a way to avoid it, but I
don't remember how.

      I've mixed a lot Ada and C to call the C library to invoke IOCTL's, perform
memory mapping and manipulate pipes, but never with C++.

      Only two possible situations make sense in my opinion: either your
application is in Ada and you want to interface it with some C++ library, or
your application is in C++ and you want to interface it to an Ada library.

      Question: is your main program in Ada or in C++?
Hi Didier,

Our main programs are C++.  I "cheated" - after calling adainit() in C++ code,
which sets up the Ada signal handlers, I called signal() to restore the default
signal handlers.  Problem solved.

Tom

    I think this is fine as long as your Ada subprograms are straightforward with no risk of error, because essentially the gnat runtime library isn't used. Hacking the runtime behaviour is always at your risk. One of the reasons to write in Ada is when "it (apparently) works" isn't considered enough, but this isn't necessary the reason in your case.

        Didier






[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux