* POSIX.Semaphores question @ 2011-12-02 15:43 awdorrin 2011-12-02 16:54 ` awdorrin 2011-12-03 19:59 ` Niklas Holsti 0 siblings, 2 replies; 12+ messages in thread From: awdorrin @ 2011-12-02 15:43 UTC (permalink / raw) 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.... ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: POSIX.Semaphores question 2011-12-02 15:43 POSIX.Semaphores question awdorrin @ 2011-12-02 16:54 ` awdorrin 2011-12-02 17:06 ` Georg Bauhaus 2011-12-03 19:59 ` Niklas Holsti 1 sibling, 1 reply; 12+ messages in thread From: awdorrin @ 2011-12-02 16:54 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: POSIX.Semaphores question 2011-12-02 16:54 ` awdorrin @ 2011-12-02 17:06 ` Georg Bauhaus 2011-12-02 17:09 ` Georg Bauhaus 0 siblings, 1 reply; 12+ messages in thread From: Georg Bauhaus @ 2011-12-02 17:06 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: POSIX.Semaphores question 2011-12-02 17:06 ` Georg Bauhaus @ 2011-12-02 17:09 ` Georg Bauhaus 2011-12-02 17:22 ` awdorrin 0 siblings, 1 reply; 12+ messages in thread From: Georg Bauhaus @ 2011-12-02 17:09 UTC (permalink / raw) On 02.12.11 18:06, Georg Bauhaus wrote: > function? variable, sorry ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: POSIX.Semaphores question 2011-12-02 17:09 ` Georg Bauhaus @ 2011-12-02 17:22 ` awdorrin 2011-12-03 16:32 ` awdorrin 0 siblings, 1 reply; 12+ messages in thread From: awdorrin @ 2011-12-02 17:22 UTC (permalink / raw) 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'... ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: POSIX.Semaphores question 2011-12-02 17:22 ` awdorrin @ 2011-12-03 16:32 ` awdorrin 0 siblings, 0 replies; 12+ messages in thread From: awdorrin @ 2011-12-03 16:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: POSIX.Semaphores question 2011-12-02 15:43 POSIX.Semaphores question awdorrin 2011-12-02 16:54 ` awdorrin @ 2011-12-03 19:59 ` Niklas Holsti 2011-12-05 12:25 ` awdorrin 1 sibling, 1 reply; 12+ messages in thread From: Niklas Holsti @ 2011-12-03 19:59 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: POSIX.Semaphores question 2011-12-03 19:59 ` Niklas Holsti @ 2011-12-05 12:25 ` awdorrin 2011-12-05 14:19 ` Georg Bauhaus 0 siblings, 1 reply; 12+ messages in thread From: awdorrin @ 2011-12-05 12:25 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: POSIX.Semaphores question 2011-12-05 12:25 ` awdorrin @ 2011-12-05 14:19 ` Georg Bauhaus 2011-12-05 16:58 ` awdorrin 0 siblings, 1 reply; 12+ messages in thread From: Georg Bauhaus @ 2011-12-05 14:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: POSIX.Semaphores question 2011-12-05 14:19 ` Georg Bauhaus @ 2011-12-05 16:58 ` awdorrin 2011-12-05 17:59 ` Simon Wright 0 siblings, 1 reply; 12+ messages in thread From: awdorrin @ 2011-12-05 16:58 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: POSIX.Semaphores question 2011-12-05 16:58 ` awdorrin @ 2011-12-05 17:59 ` Simon Wright 2011-12-06 0:53 ` awdorrin 0 siblings, 1 reply; 12+ messages in thread From: Simon Wright @ 2011-12-05 17:59 UTC (permalink / raw) 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;". ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: POSIX.Semaphores question 2011-12-05 17:59 ` Simon Wright @ 2011-12-06 0:53 ` awdorrin 0 siblings, 0 replies; 12+ messages in thread From: awdorrin @ 2011-12-06 0:53 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-12-06 0:53 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-12-02 15:43 POSIX.Semaphores question awdorrin 2011-12-02 16:54 ` awdorrin 2011-12-02 17:06 ` Georg Bauhaus 2011-12-02 17:09 ` Georg Bauhaus 2011-12-02 17:22 ` awdorrin 2011-12-03 16:32 ` awdorrin 2011-12-03 19:59 ` Niklas Holsti 2011-12-05 12:25 ` awdorrin 2011-12-05 14:19 ` Georg Bauhaus 2011-12-05 16:58 ` awdorrin 2011-12-05 17:59 ` Simon Wright 2011-12-06 0:53 ` awdorrin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox