Calling Ada from C (linux/gnat 4.3.2)

Calling Ada from C (linux/gnat 4.3.2)

[awdorrin]

I am trying to port a program originally written on VxWork to Linux.
The main program is written in C and spawns new threads and in the new
threads calls are made to Ada procedures.

In the original program, written with GreenHills AdaMulti, it appears
that there was a call being made that I am assuming was initializing
the Ada Runtime's task stack/control block (rts_init_task()) - however
this is just a guess.

In the version of the program I am migrating, I was seeing things that
made me believe that the Ada thread's did not have their stacks setup
properly, so I added the -fstack-check flag to the build.

Now, the C program creates the new thread, which calls the ada
procedure - and the moment the thread has an opportunity to run - the
application exits with 'raised STORAGE_ERROR : stack overflow
detected'

I cannot get gdb to provide me a backtrace, since the program exits.
If I try to break on the ada procedure name, I get a break, but trying
to 'step' or 'next' keeps me in the main thread until a 'sleep' call
lets the other thread run - at which point it raises the exception.

I am assuming that the ada runtime is initializing and the
STORAGE_ERROR is raised before it gets to execute any of the code in
my Ada procedure.

I have been trying to search to find what the proper way would be to
call an Ada procedure from a C pthread, but have had zero luck. I also
have been unable to determine what the equivalent of the
'rts_init_task' would be with Gnat.

Any have any ideas?

Re: Calling Ada from C (linux/gnat 4.3.2)

[Jeffrey Carter]

On 11/01/2011 11:46 AM, awdorrin wrote:
>
> Any have any ideas?

Does your C main program call adainit and adafinal [ARM B.1 (39)]?

-- 
Jeff Carter
"Sir Lancelot saves Sir Gallahad from almost certain temptation."
Monty Python & the Holy Grail
69

Re: Calling Ada from C (linux/gnat 4.3.2)

[Simon Wright]

awdorrin <awdorrin@gmail.com> writes:

> I have been trying to search to find what the proper way would be to
> call an Ada procedure from a C pthread, but have had zero luck. I also
> have been unable to determine what the equivalent of the
> 'rts_init_task' would be with Gnat.

The info on-line is sparse; if you google 'gnat foreign threads' you'll
find [1], which tells you to look at the documentation of GNAT.Threads
(g-thread.ads). What it wants you to do is to read the comments in that
file.

In the past I've had success calling Register_Thread from the called Ada
procedure before it does anything at all, but that's not what the
comments seem to be saying. For example, I might have said

procedure P;
pragma export (C, P, "my_ada_proc");
procedure P is
   Id : constant System.Address := GNAT.Threads.Register_Thread;
   ...
begin
   ...

Jeffrey is correct that you need to call adainit() (and you should call
adafinal() before program exit or unloading a shared library).

[1] http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gnat_rm/GNAT_002eThreads-_0028g_002dthread_002eads_0029.html  

Re: Calling Ada from C (linux/gnat 4.3.2)

[anon]

Within C use normal external calling

extern <name> <arg list>


And in Ada use a specification file to declare routine.

 procedure <name> ( arg list ) ;
   pragma Export ( C, <name> ) ;

or you could use
   pragma Export ( C, <name>, "<linked name>" ) ;

In Ada the routine may or may not be in a package.


In <8ba649f0-7ca1-4f05-a158-74b074e401ee@o19g2000vbk.googlegroups.com>, awdorrin <awdorrin@gmail.com> writes:
>I am trying to port a program originally written on VxWork to Linux.
>The main program is written in C and spawns new threads and in the new
>threads calls are made to Ada procedures.
>
>In the original program, written with GreenHills AdaMulti, it appears
>that there was a call being made that I am assuming was initializing
>the Ada Runtime's task stack/control block (rts_init_task()) - however
>this is just a guess.
>
>In the version of the program I am migrating, I was seeing things that
>made me believe that the Ada thread's did not have their stacks setup
>properly, so I added the -fstack-check flag to the build.
>
>Now, the C program creates the new thread, which calls the ada
>procedure - and the moment the thread has an opportunity to run - the
>application exits with 'raised STORAGE_ERROR : stack overflow
>detected'
>
>I cannot get gdb to provide me a backtrace, since the program exits.
>If I try to break on the ada procedure name, I get a break, but trying
>to 'step' or 'next' keeps me in the main thread until a 'sleep' call
>lets the other thread run - at which point it raises the exception.
>
>I am assuming that the ada runtime is initializing and the
>STORAGE_ERROR is raised before it gets to execute any of the code in
>my Ada procedure.
>
>I have been trying to search to find what the proper way would be to
>call an Ada procedure from a C pthread, but have had zero luck. I also
>have been unable to determine what the equivalent of the
>'rts_init_task' would be with Gnat.
>
>Any have any ideas?

Re: Calling Ada from C (linux/gnat 4.3.2)

[Stephen Leake]

awdorrin <awdorrin@gmail.com> writes:

> I am trying to port a program originally written on VxWork to Linux.
> The main program is written in C and spawns new threads and in the new
> threads calls are made to Ada procedures.

I suggest you rewrite the C main in Ada, and avoid all of these
problems. 

Having a C main is probably a good idea in VxWorks, but totally
unnecessary in Linux.

Getting "C threads" and Ada tasks to intermix properly is not trivial.

-- 
-- Stephe

Re: Calling Ada from C (linux/gnat 4.3.2)

[awdorrin]

Thanks for the suggestions

Jeff - yes, I'm calling adainit/final - the Ada code is executing when
I remove the -fstack-check, its just running rampant through memory
and the threads are clobbering each other.

Simon - Thanks, the GNAT.Threads.Register_Thread sounds promising -
I'm wondering if it may be the equivalent of the rts_init_task() call.

Stephen - believe me, I'd rather do that, but I'm limited in my
options for which parts of the program I can modify.

I haven't had a chance to try out Simon's suggestion yet. I had
problem with the Linux server that had me spending all day
reinstalling the OS...

Will follow up once I get things reconfigured.

Re: Calling Ada from C (linux/gnat 4.3.2)

[awdorrin]

Odd thing - after upgrading my Linux system (Fedora 10 to Debian 6) -
with the newer GCC and GNAT - these stack errors went away. I'm
wondering if GNAT changed behind the scenes and adhere to the native/
POSIX threads closer - and the stacks are working by default now.

Re: Calling Ada from C (linux/gnat 4.3.2)

[Pascal Obry]

Le 09/11/2011 00:22, awdorrin a �crit :
> Odd thing - after upgrading my Linux system (Fedora 10 to Debian 6) -
> with the newer GCC and GNAT - these stack errors went away. I'm
> wondering if GNAT changed behind the scenes and adhere to the native/
> POSIX threads closer - and the stacks are working by default now.

The answer is in the question: upgrading from Fedora 10 to Debian 6 :)

Ludovic will tell you about GNU/Debian magic :)

Pascal.


-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Calling Ada from C (linux/gnat 4.3.2)

[Ludovic Brenta]

Pascal Obry <pascal@obry.net> writes:
> Le 09/11/2011 00:22, awdorrin a écrit :
>> Odd thing - after upgrading my Linux system (Fedora 10 to Debian 6) -
>> with the newer GCC and GNAT - these stack errors went away. I'm
>> wondering if GNAT changed behind the scenes and adhere to the native/
>> POSIX threads closer - and the stacks are working by default now.
>
> The answer is in the question: upgrading from Fedora 10 to Debian 6 :)
>
> Ludovic will tell you about GNU/Debian magic :)

I cannot explain it; it must be real magic then :)

-- 
Ludovic Brenta.
The overarching concepts quickly generate parallel projections by
thinking outside of the box, whereas customer-centric cost efficiencies
synergize the enablers.

Re: Calling Ada from C (linux/gnat 4.3.2)

[Matt Grochowalski]

On Tuesday, November 1, 2011 2:46:07 PM UTC-4, awdorrin wrote:
> I am trying to port a program originally written on VxWork to Linux.
> The main program is written in C and spawns new threads and in the new
> threads calls are made to Ada procedures.
> 
> In the original program, written with GreenHills AdaMulti, it appears
> that there was a call being made that I am assuming was initializing
> the Ada Runtime's task stack/control block (rts_init_task()) - however
> this is just a guess.
> 
> In the version of the program I am migrating, I was seeing things that
> made me believe that the Ada thread's did not have their stacks setup
> properly, so I added the -fstack-check flag to the build.
> 
> Now, the C program creates the new thread, which calls the ada
> procedure - and the moment the thread has an opportunity to run - the
> application exits with 'raised STORAGE_ERROR : stack overflow
> detected'
> 
> I cannot get gdb to provide me a backtrace, since the program exits.
> If I try to break on the ada procedure name, I get a break, but trying
> to 'step' or 'next' keeps me in the main thread until a 'sleep' call
> lets the other thread run - at which point it raises the exception.
> 
> I am assuming that the ada runtime is initializing and the
> STORAGE_ERROR is raised before it gets to execute any of the code in
> my Ada procedure.
> 
> I have been trying to search to find what the proper way would be to
> call an Ada procedure from a C pthread, but have had zero luck. I also
> have been unable to determine what the equivalent of the
> 'rts_init_task' would be with Gnat.
> 
> Any have any ideas?

I have a simillar question using GCC 4.5.0 (the vanilla GNU distribution rather than AdaCore's).

There doesn't seem to be any issues calling Ada procedures from threads created using pthread_create in C, but GDB shows system__secondary_stack__ss_mark returning the same value in all threads. Could this create race conditions?