Re: Interfacing between Ada and C: records and structs

Re: Interfacing between Ada and C: records and structs

[Jeffrey Carter]

On 07/31/2012 09:27 AM, awdorrin wrote:
> I have some legacy code that I am working with, they share common data structures.
>
> Simplifying my code, In Ada, I have a record:
>
> type FP_SHARED_BUF_TYPE is
> record
>    LOCK_SHM_1 : aliased Mutex;
>    LOCK_SHM_2 : aliased Mutex;
>    LOCK_SHM_3 : aliased Mutex;
> end record;
>
> In C:
>
> struct FP_SHARED_TYPE {
>    pthread_mutex_t LOCK_SHM_1;
>    pthread_mutex_t LOCK_SHM_2;
>    pthread_mutex_t LOCK_SHM_3;
> };
>
> When I compile the program, the Ada code defines the record as:
>
> for FP_SHARED_BUF_TYPE'Alignment use 9;
> for FP_SHARED_BUF_TYPE use record
>    LOCK_SHM_1 at

Anything you define in Ada that should match something defined in C should have 
a "pragma Convention (C, ...);".

-- 
Jeff Carter
"The time has come to act, and act fast. I'm leaving."
Blazing Saddles
36



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Interfacing between Ada and C: records and structs

[awdorrin]

I have some legacy code that I am working with, they share common data structures.

Simplifying my code, In Ada, I have a record:

type FP_SHARED_BUF_TYPE is
record
  LOCK_SHM_1 : aliased Mutex;
  LOCK_SHM_2 : aliased Mutex;
  LOCK_SHM_3 : aliased Mutex;
end record;
pragma Convention(C,FP_SHARED_BUF_TYPE);

In C:

struct FP_SHARED_TYPE {
  pthread_mutex_t LOCK_SHM_1;
  pthread_mutex_t LOCK_SHM_2;
  pthread_mutex_t LOCK_SHM_3;
};

Now, the Mutex/pthread_mutex_t is 192bits, not 255bits, but when I compile the program.

The Ada code defines the record as:

for FP_SHARED_BUF_TYPE'Alignment use 9;
for FP_SHARED_BUF_TYPE use record
  LOCK_SHM_1 at - range  0 .. 255;
  LOCK_SHM_1 at - range 32 .. 255;
  LOCK_SHM_1 at - range 64 .. 255;
end record;

While the C code defines the structure elements as 192bits, and packs them right next to each other

Addresses of:
LOCK_SHM_1	0xF5650008
LOCK_SHM_2	0xF5650020
LOCK_SHM_3	0xF5650038

The only way I can get this to work, is to add padding to my C struct definition:

struct FP_SHARED_TYPE {
  pthread_mutex_t LOCK_SHM_1;
  int pad_for_m1[2];
  pthread_mutex_t LOCK_SHM_2;
  int pad_for_m2[2];
  pthread_mutex_t LOCK_SHM_3;
  int pad_for_m3[2];
};

Which, makes the C code really ugly.

Is there a way to make the Ada code pack the record?

I have been looking through the docs and haven't seen it yet.

Re: Interfacing between Ada and C: records and structs

[Niklas Holsti]

On 12-07-31 19:38 , awdorrin wrote:
> I have some legacy code that I am working with, they share common data structures.
> 
> Simplifying my code, In Ada, I have a record:
> 
> type FP_SHARED_BUF_TYPE is
> record
>   LOCK_SHM_1 : aliased Mutex;
>   LOCK_SHM_2 : aliased Mutex;
>   LOCK_SHM_3 : aliased Mutex;
> end record;
> pragma Convention(C,FP_SHARED_BUF_TYPE);
> 
> In C:
> 
> struct FP_SHARED_TYPE {
>   pthread_mutex_t LOCK_SHM_1;
>   pthread_mutex_t LOCK_SHM_2;
>   pthread_mutex_t LOCK_SHM_3;
> };
> 
> Now, the Mutex/pthread_mutex_t is 192bits, not 255bits, but when I compile the program.

How is pthread_mutex_t declared in Ada form? And in C form?

Have you checked that in Ada, pthread_mutex_t'Size is 192?

What is the storage unit of your target processor? 8 bits?

> The Ada code defines the record as:
> 
> for FP_SHARED_BUF_TYPE'Alignment use 9;

That is a strange alignment. Do you see any need for it? If not, try
removing it.

> for FP_SHARED_BUF_TYPE use record
>   LOCK_SHM_1 at - range  0 .. 255;
>   LOCK_SHM_1 at - range 32 .. 255;
>   LOCK_SHM_1 at - range 64 .. 255;
> end record;

Do you see any need for this representation clause? If not, remove it.
Or change it to use 192 bits per component.

(What are the "-" characters after the "at" keywords? Shouldn't it read
"at 0 range"?)

> While the C code defines the structure elements as 192bits, and packs them right next to each other
> 
> Addresses of:
> LOCK_SHM_1	0xF5650008
> LOCK_SHM_2	0xF5650020
> LOCK_SHM_3	0xF5650038
> 
> The only way I can get this to work, is to add padding to my C struct definition:
> 
> struct FP_SHARED_TYPE {
>   pthread_mutex_t LOCK_SHM_1;
>   int pad_for_m1[2];
>   pthread_mutex_t LOCK_SHM_2;
>   int pad_for_m2[2];
>   pthread_mutex_t LOCK_SHM_3;
>   int pad_for_m3[2];
> };
> 
> Which, makes the C code really ugly.
> 
> Is there a way to make the Ada code pack the record?

If your Ada code includes the record representation clause quoted above,
just remove it, or change it to specify 192 bits per component.

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

Re: Interfacing between Ada and C: records and structs

[awdorrin]

On Tuesday, July 31, 2012 1:16:10 PM UTC-4, Niklas Holsti wrote:
> 
> How is pthread_mutex_t declared in Ada form? And in C form?
> 

Digging into the POSIX module:

private
  type Dummy is tagged null record;
  type Mutex is record
    Mutex : aliased POSIX.C.pthread_mutex_t;
    D : Dummy;
  end record

> 
> Have you checked that in Ada, pthread_mutex_t'Size is 192?
> 

In the POSIX.C package:
ALIGNMENT : constant := Natural'Min(Standard'Maximum_Alignment, 8);
type pthread_mutex_t'Alignment use ALIGNMENT;
type pthread_mutex_t'Size use 192;

However, when I write a simple test program I get 256 bits from 'Size, I'm not sure why...
But that is probably the source of my problem.
 
> 
> What is the storage unit of your target processor? 8 bits?

The system is an Intel core2Duo E4600 - so a 64bit processor running x86_64 variant of Debian. (32-bit mode) So the storage unit is 8 bits.

> 
> That is a strange alignment. Do you see any need for it? If not, try
> removing it.

That was a typo on my part, should have read 'Alignment use 8;

> 
> Do you see any need for this representation clause? If not, remove it.
> 
> Or change it to use 192 bits per component.

That is the output from the -gnatR3 parameter, I don't have the rep spec defined in the code.

> 
> (What are the "-" characters after the "at" keywords? Shouldn't it read
> "at 0 range"?)

Sorry, that was apparently another typo on my part. (Cut and paste isn't working between my Linux VNC session and my desktop Windows PC)

Re: Interfacing between Ada and C: records and structs

[awdorrin]

I am wondering if the Dummy element in the Mutex record is not being treated as a null, but as a null pointer, adding 8 bytes to the record size.

I tried forcing the sizes to '192' in Ada by adding the rep spec and got the following error messages:

size for "LOCK_SHM_1" too small, minimum allowed is 224
position of aliased field "LOCK_SHM_1" must be multiple of 64 bits

So I'm guessing 192 (pthread_mutex_t) + 32 ( tagged null record) = 224 bits, rounded to 256 due to the address position requirement of an aliased field. (Still not sure I understand what a tagged or aliased field is, will have to read up on it.)

So, I guess this turns out to be more of a C question - on if I can pad/align the structs via compiler flags, or if I am better off sticking with manually adding the padding.

Not sure if there is a standard method used 'in modern times' to do this, other than defining a record in Ada and a corresponding struct in C.

Re: Interfacing between Ada and C: records and structs

[Simon Wright]

awdorrin <awdorrin@gmail.com> writes:

> I am wondering if the Dummy element in the Mutex record is not being
> treated as a null, but as a null pointer, adding 8 bytes to the record
> size.

If you say

   type Dummy is null record;

then no space is reserved for the tag.

But if that is OK, what is it _for_? Normally something like this is
needed to pad out parts of a C struct that you don't need to bother
with, but that's clearly not the case here.

Re: Interfacing between Ada and C: records and structs

[awdorrin]

This is code from the POSIX Florist API for Ada. There is a comment in the code that says that the 'Dummy' tagged null record is:
 "to force by-reference parameter mode"

Your test code matches up with similar code I wrote on my system, except being 32-bit I get D as "range 0 .. 31"

The 'rep' files generated by -gnatR3s for the Florist POSIX API gives:
for DUMMY'Size use 32;
for DUMMY'Alignment use 4;
for DUMMY use record
   _TAG at 0 range  0 .. 31;
end record;

for MUTEX'Object_Size use 256;
for MUTEX'Value_Size use 224;
for MUTEX'Alignment use 8;
for MUTEX use record
   MUTEX at  0 range  0 .. 191;
   D     at 24 range  0 .. 31;
end record;


So at least I understand why it isn't 192 bits, but 256.

Re: Interfacing between Ada and C: records and structs

[Niklas Holsti]

On 12-07-31 22:44 , awdorrin wrote:
> This is code from the POSIX Florist API for Ada. There is a comment
> in the code that says that the 'Dummy' tagged null record is: "to
> force by-reference parameter mode"

Perhaps, in some earlier GNAT, a "tagged null record" would have a zero
size, but the same is not true in the current GNAT.

If the goal is to force passing by reference, another way is to make the
Mutex type limited:

   type Mutex is limited record
      Mutex : aliased POSIX.C.pthread_mutex_t;
   end record;

Being "limited" should not increase the size of the record. But it
forbids some operations on the type, chiefly ":=".

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

Re: Interfacing between Ada and C: records and structs

[awdorrin]

On Tuesday, July 31, 2012 4:46:34 PM UTC-4, Niklas Holsti wrote:
>
> If the goal is to force passing by reference, another way is to make the
> Mutex type limited:
> 
>    type Mutex is limited record
>       Mutex : aliased POSIX.C.pthread_mutex_t;
>    end record;
> 
> Being "limited" should not increase the size of the record. But it
> forbids some operations on the type, chiefly ":=".

I am a bit hesitant to change the Florist library code in my project. But from looking at the Florist SourceForge website, it doesn't look like this API is actively developed by the open source community any longer.

For now, I think I'll keep padding in my C-code to match up to the memory space generated in Ada. I'm starting to get too 'distracted' from the main goal of running gnatpp on this legacy code. :)

Thanks!

Re: Interfacing between Ada and C: records and structs

[Simon Wright]

awdorrin <awdorrin@gmail.com> writes:

> private
>   type Dummy is tagged null record;
>   type Mutex is record
>     Mutex : aliased POSIX.C.pthread_mutex_t;
>     D : Dummy;
>   end record

What's D : Dummy doing here? There's no equivalent in the C.

Here, on an x86_64 compiler,

   package Mutex is
      type pthread_mutex_t is new Boolean with
        Alignment => 8,
        Size => 192;
      type Dummy is tagged null record;
      type Mutex is record
         Mutex : aliased pthread_mutex_t;
         D : Dummy;
      end record;
   end Mutex;

compiled with -gnat12 -gnatR3 gives

   for Pthread_Mutex_T'Size use 192;
   for Pthread_Mutex_T'Alignment use 8;

   for Dummy'Size use 64;
   for Dummy'Alignment use 8;
   for Dummy use record
      _Tag at 0 range  0 .. 63;
   end record;

   for Mutex'Size use 256;
   for Mutex'Alignment use 8;
   for Mutex use record
      Mutex at  0 range  0 .. 191;
      D     at 24 range  0 .. 63;
   end record;

Re: Interfacing between Ada and C: records and structs

[Shark8]

> Digging into the POSIX module:
> 
> 
> 
> private
> 
>   type Dummy is tagged null record;
> 
>   type Mutex is record
> 
>     Mutex : aliased POSIX.C.pthread_mutex_t;
> 
>     D : Dummy;
> 
>   end record
> 
> 
> 
> > 
> 
> > Have you checked that in Ada, pthread_mutex_t'Size is 192?
> 
> > 
> 
> 
> 
> In the POSIX.C package:
> 
> ALIGNMENT : constant := Natural'Min(Standard'Maximum_Alignment, 8);
> 
> type pthread_mutex_t'Alignment use ALIGNMENT;
> 
> type pthread_mutex_t'Size use 192;
> 
> 
> 
> However, when I write a simple test program I get 256 bits from 'Size, I'm not sure why...

Try adding Pragma Pack( DATA_STRUCTURE ); to the record.

Re: Interfacing between Ada and C: records and structs

[awdorrin]

On Thursday, August 2, 2012 12:39:46 AM UTC-4, Shark8 wrote:
>
> Try adding Pragma Pack( DATA_STRUCTURE ); to the record.
>

Even with the pragma Pack, it produces the same output.

I think Niklas is correct that an older version of GNAT must have treated the 'tagged null record' differently.