POSIX.Semaphores question

POSIX.Semaphores question

[awdorrin]

I'm using the Florist POSIX Libraries and have code that is similar to
the following:

In the spec file:

Sem_READY : Semaphore;
READY         : Semaphore_Descriptor;
pragma Export( Ada, READY, "ready");

Then in my body:

POSIX.Semaphores.Initialize( Sem_READY, 1);
READY := POSIX.Semaphores.Descriptor_Of( Sem_READY );

When executed, READY is always set to null.

If I run the code through GDB and print READY, it always displays 0x0.
However, if I call POSIX.Semaphores.Descriptor_Of( Sem_Ready )
I get the right address returned: (access posix.c.sem_t) 0x8321540

I have no idea why the assignment is failing and not generating an
exception....

Re: POSIX.Semaphores question

[awdorrin]

What I'm gathering so far is that the pragma export is making the
variable 'READY' static, which is why its staying uninitialized...

Not sure the right way to get this assigned and exported over to C.

Re: POSIX.Semaphores question

[Georg Bauhaus]

On 02.12.11 17:54, awdorrin wrote:
> What I'm gathering so far is that the pragma export is making the
> variable 'READY' static, which is why its staying uninitialized...
> 
> Not sure the right way to get this assigned and exported over to C.

READY looks like it is being exported with convention Ada, meaning
something like know yourself where READY is; I'd expect an address
attribute near it that provides for storage. Is convention Ada the intent?
Or should it by convention C or Standard if exported to some
C implementation, or as a system function?

Re: POSIX.Semaphores question

[Georg Bauhaus]

On 02.12.11 18:06, Georg Bauhaus wrote:

>  function?

variable, sorry

Re: POSIX.Semaphores question

[awdorrin]

I was thinking that this should be 'pragma Export(C, READY, "ready")'
instead - but that doesn't seem to have any effect.

As long as the pragma is present, I cannot assign a value.

I even tried:

Sem_READY : Semaphore;
READY         : Semaphore_Descriptor :=
POSIX.Semaphores.Descriptor_Of( Sem_READY );
pragma Export( Ada, READY, "ready");

thinking that it would initialize, but still get an uninitialized
'READY'...

Re: POSIX.Semaphores question

[awdorrin]

For some reason I used the word "static" above when I meant "constant"

Seems like no matter what I do, the moment I try to export the
variable, I can no longer assign to it within Ada.

I realize that a better way to do this would be to export a procedure
or function to pass the Ada Semaphore_Descriptor to a C sem_t*, but
this is functioning in the legacy code, so I'm trying to understand if
Gnat is doing something different, if exporting variables is no longer
allowed, or if there is something specific about a
Semaphore_Descriptor that is causing the pragmatic export to lock the
variable and treat it as a constant.

Thanks

Re: POSIX.Semaphores question

[Niklas Holsti]

On 11-12-02 17:43 , awdorrin wrote:
> I'm using the Florist POSIX Libraries and have code that is similar to
> the following:
>
> In the spec file:
>
> Sem_READY : Semaphore;
> READY         : Semaphore_Descriptor;
> pragma Export( Ada, READY, "ready");

This pragma gives the variable a very short linkage name, "ready", which 
is moreover a common word. Perhaps the same name is used by some other 
module of the program, for some other program item, and this confuses 
the linker. Does the linker give any errors or warnings?

Try it with a longer name, one less likely to be in use already for 
something else.

>
> Then in my body:
>
> POSIX.Semaphores.Initialize( Sem_READY, 1);
> READY := POSIX.Semaphores.Descriptor_Of( Sem_READY );
>
> When executed, READY is always set to null.
>
> If I run the code through GDB and print READY, it always displays 0x0.
> However, if I call POSIX.Semaphores.Descriptor_Of( Sem_Ready )
> I get the right address returned: (access posix.c.sem_t) 0x8321540
>
> I have no idea why the assignment is failing and not generating an
> exception....


-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: POSIX.Semaphores question

[awdorrin]

On Dec 3, 2:59 pm, Niklas Holsti <niklas.hol...@tidorum.invalid>
wrote:
>
> This pragma gives the variable a very short linkage name, "ready", which
> is moreover a common word. Perhaps the same name is used by some other
> module of the program, for some other program item, and this confuses
> the linker. Does the linker give any errors or warnings?
>
> Try it with a longer name, one less likely to be in use already for
> something else.
>

I simplified the example code that I posted - the actual name I'm
using is much longer. (Sem_R_RTSIM_SHM_READY, R_RTSIM_SHM_READY and
r_rtsim_shm_ready)

I see no warnings or errors during the compile or link. I am linking
the Ada files into a library which is compiled into a C main.

The only thing I do see, is when I add the compile flat to print out
the rep specs - the Semaphore is given two different sizes...

for SEM_R_RTSIM_SHM_READY'Size use 128;
for SEM_R_RTSIM_SHM_READY'Size use 192;

It should be 128, not sure why its later showing as 192... from
looking at the definition for sem_t on this linux system, it should be
128.

Re: POSIX.Semaphores question

[Georg Bauhaus]

On 05.12.11 13:25, awdorrin wrote:

> The only thing I do see, is when I add the compile flat to print out
> the rep specs - the Semaphore is given two different sizes...
> 
> for SEM_R_RTSIM_SHM_READY'Size use 128;
> for SEM_R_RTSIM_SHM_READY'Size use 192;
> 
> It should be 128, not sure why its later showing as 192... from
> looking at the definition for sem_t on this linux system, it should be
> 128.

That's odd. Is this really the same variable (or maybe just
the same name)?

FWIW, the following program appears to be working as expected,
in at least one environment.


with Interfaces.C;
with Assign_For_Ext_Use;
pragma Elaborate_All (Assign_For_Ext_Use);

package Exp_Imp is

   use Interfaces;

   type C_Compatible is new C.int;

   With_Convention_Ada : C_Compatible := 16#BEEF#;
   pragma Export (Ada, With_Convention_Ada, "exp_imp__with_convention_ada");

   For_Ext_Use : C_Compatible := C_Compatible(Assign_For_Ext_Use);
   pragma Export (C, For_Ext_Use, "exp_imp__for_ext_use");

end Exp_Imp;


with Interfaces.C;

function Assign_For_Ext_Use return Interfaces.C.int is
begin
   return 16#F00#;
end Assign_For_Ext_Use;


#include <stdio.h>

#define M(p, name) p ## __ ## name

extern int M(exp_imp, with_convention_ada);
extern int M(exp_imp, for_ext_use);
extern void adainit (void);
extern void adafinal (void);

int main()
{
     adainit();

     fprintf(stderr,
	     "with_convention_ada is %X\n",
	     M(exp_imp, with_convention_ada));
     fprintf(stderr,
	     "for_ext_use is %X\n",
	     M(exp_imp, for_ext_use));

     adafinal();
     return 0;
}

gnatmake -gnatwa -gnato -O -f exp_imp.ads && \
gnatbind -n exp_imp.ali && \
gnatmake -O -gnato b~exp_imp.adb && \
gcc use_from_c.c b~exp_imp.o assign_for_ext_use.o exp_imp.o \
   -o use_from_c -lgnat

$ ./use_from_c
with_convention_ada is BEEF
for_ext_use is F00

Re: POSIX.Semaphores question

[awdorrin]

On Dec 5, 9:19 am, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
wrote:
> On 05.12.11 13:25, awdorrin wrote:
>
> > The only thing I do see, is when I add the compile flat to print out
> > the rep specs - the Semaphore is given two different sizes...
>
> > for SEM_R_RTSIM_SHM_READY'Size use 128;
> > for SEM_R_RTSIM_SHM_READY'Size use 192;
>
> > It should be 128, not sure why its later showing as 192... from
> > looking at the definition for sem_t on this linux system, it should be
> > 128.
>
> That's odd. Is this really the same variable (or maybe just
> the same name)?

It looks like when I check the spec file (with a -gnatc) it shows the
size as '128' - but when I compile, it shows it as '192' - when I
check it with the debugger, it is 24 bytes/192 bits, not sure why
there is a discrepancy.


> FWIW, the following program appears to be working as expected,
> in at least one environment.
>

Thanks for your example - I build another test case using an Ada only
program - and the Semaphore_Descriptors were getting set fine,
although I did run into an odd problem...

I wanted to try and print out the address of the Semaphore_Descriptor
variable and the address to which it was pointing.
I tried the following line:

Text_IO.Put_Line( System.Address_Image(SemPtr'Address) & " -> " &
System.Address_Image(SemPtr.all'Address) );

The first Address_Image worked fine, but I could never get the second
to compile, I kept seeing the error:
"prefix of dereference must be an access type"

SemPtr is a Semaphore_Descriptor, which is defined as: type
Semaphore_Descriptor is access constant POSIX.C.sem_t;
I'm not sure if this is related to the GNAT bug reported here:
http://patchwork.ozlabs.org/patch/112485/

In any case, I went back to my original code and investigated further
and I think I figured out the problem...

I discovered that some of the Semaphore_Descriptors being exported
were working fine, while others were not.
Turns out it had to do with the export statement:

pragma export( C, SEM_PTR1, "SEM_PTR1"); -- does NOT work
pragma export( C, SEM_PTR2, "sem_ptr2"); -- DOES work

Apparently the export has to have the link name in lower case... Not
sure I understand why this is the case...
Of course I still don't understand how the convention (C vs Ada)
effects the export pragmas either :)

Program is getting a lot further now that the semaphores are working
properly!

Re: POSIX.Semaphores question

[Simon Wright]

awdorrin <awdorrin@gmail.com> writes:

> I tried the following line:
>
> Text_IO.Put_Line( System.Address_Image(SemPtr'Address) & " -> " &
> System.Address_Image(SemPtr.all'Address) );
>
> The first Address_Image worked fine, but I could never get the second
> to compile, I kept seeing the error:
> "prefix of dereference must be an access type"

That's because "type Semaphore_Descriptor is private;", so your code
can't see the fact that it's privately implemented as "access constant
POSIX.C.sem_t;".

Re: POSIX.Semaphores question

[awdorrin]

> That's because "type Semaphore_Descriptor is private;", so your code
> can't see the fact that it's privately implemented as "access constant
> POSIX.C.sem_t;".

That makes sense, and sounds like what that bug report I linked to was
addressing.

I'm guessing that the private tag is what is making the Semaphore and
Mutex have a larger size than I expect.
I would have thought that the 'Dummy' null record would have evaluated
to zero size, making the Semaphore and Mutex records defined in the
POSIX library map to the same size as the types within C.

However, it looks like GNAT is adding another 4 bytes to the size (for
the 'null' record), then GNAT is aligning multiple Semaphores/Mutexes
in a record to 16 byte boundaries...

Guess I could add padding to the C structs to get this to work with
GNAT - but seems like there should be a better way to get the sizes
correct.