Ada and signal handling

Ada and signal handling

[Kacvinsky, Tom]

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

Re: Ada and signal handling

[Didier Kryn]

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++?

         Didier

RE: Ada and signal handling

[Kacvinsky, Tom]

> -----Original Message-----
> From: gcc-help-owner@gcc.gnu.org <gcc-help-owner@gcc.gnu.org> On
> Behalf Of Didier Kryn
> Sent: Wednesday, October 9, 2019 4:36 AM
> To: gcc-help@gcc.gnu.org
> 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

Re: Ada and signal handling

[Didier Kryn]

Le 09/10/2019 à 18:23, Kacvinsky, Tom a écrit :
>
>> -----Original Message-----
>> From: gcc-help-owner@gcc.gnu.org <gcc-help-owner@gcc.gnu.org> On
>> Behalf Of Didier Kryn
>> Sent: Wednesday, October 9, 2019 4:36 AM
>> To: gcc-help@gcc.gnu.org
>> 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