Re: GNAT 4.4.5 Record Bit_Order Endian issues

[Simon Wright <simon@pushface.org>]

awdorrin <awdorrin@gmail.com> writes:

> 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.

That is *because of* the use of the Bit_Order clause.

If you comment-out the Bit_Order clause and do the same, you'll find
that My_Trk_Rec.Track_Id_X'Address is the same as My_Trk_Rec'Address,
and My_Trk_Rec.Sparea'Address is 3 greater.