Re: GNAT 4.4.5 Record Bit_Order Endian issues

[awdorrin <awdorrin@gmail.com>]

So, now on Debian 7 with GNAT 4.6.

Current record definition starts with:

  for MY_RECORD_TYPE'Bit_Order use System.High_Order_First;
  for MY_RECORD_TYPE use
    record
      TRACK_ID_X                  at   0 range  0 .. 11;
      TRACK_ID_USE_COUNTR_X       at   0 range 12 .. 17;
      NORMAL_RAW_DATA_X           at   0 range 18 .. 18;
      TRACK_STATUS_X              at   0 range 19 .. 21;
      DEAD_RECKONING_FLG_X        at   0 range 22 .. 22;
      TRACK_CONVERGENCE_X         at   0 range 23 .. 23;
      BLOCKED_TRACK_FLAG_X        at   0 range 24 .. 24;
      TRACK_INRFRNCE_ALRT_X       at   0 range 25 .. 25;
      MNUVRING_TARGET_FLG_X       at   0 range 26 .. 26;
      DESGNATED_TRACK_FLG_X       at   0 range 27 .. 27;
      SPAREA                      at   0 range 28 .. 31;
   end record;

Within my code, I have something like:
  MY_TRK_REC.TRACK_ID_X := 1;
  MY_TRK_REC.TRACK_ID_USE_COUNTR_X :=1;

Examining things through GDB:

"p MY_TRK_REC.TRACK_ID_X'Address" returns 0xb5cd0cd2
"p MY_TRK_REC.SPAREA'Address" returns 0xb5cd0cd0

The record elements are being laid out backwards in memory, despite the use System.High_Order_First directive.

Looking at the rep-spec output from my compile I get:

for MY_RECORD_TYPE use record
   TRACK_ID_X            at   2 range  4 .. 15;
   TRACK_ID_USE_COUNTR_X at   1 range  6 .. 11;
   NORMAL_RAW_DATA_X     at   1 range  5 ..  5;
   TRACK_STATUS_X        at   1 range  2 ..  4;
   DEAD_RECKONING_FLG_X  at   1 range  1 ..  1;
   TRACK_CONVERGENCE_X   at   1 range  0 ..  0;
   BLOCKED_TRACK_FLAG_X  at   0 range  7 ..  7;
   TRACK_INRFRNCE_ALRT_X at   0 range  6 ..  6;
   MNUVRING_TARGET_FLG_X at   0 range  5 ..  5;
   DESGNATED_TRACK_FLG_X at   0 range  4 ..  4;
   SPAREA                at   0 range  0 ..  3;

So, despite my earlier post today, I'm back to believing that the GNAT4.6 implementation is buggy. (or not documented clearly)