# Weird behaviour in record mapping **URL:** https://forum.ada-lang.io/t/weird-behaviour-in-record-mapping/1825 **Category:** General **Tags:** embedded **Created:** [February 17, 2025, 10:47am UTC](https://forum.ada-lang.io/t/weird-behaviour-in-record-mapping/1825 "2025-02-17T10:47:33Z") **Posts on this page:** 1 **Showing post:** 2
### Author: ![Irvise](https://forum.ada-lang.io/letter_avatar_proxy/v4/letter/i/7ba0ec/32.png) [@Irvise](https://forum.ada-lang.io/u/Irvise) #### Post date: [February 17, 2025, 6:04pm UTC](https://forum.ada-lang.io/t/weird-behaviour-in-record-mapping/1825/2 "2025-02-17T18:04:26Z")
Hi @sidisyom, Here are my two cents (which may fully help you or may get you closer to a solution). I would mark the variable `SYSCFG_EXTICR_Reg` as `aliased` just in case. Aliased just tells the compiler that the variable needs to live somewhere in memory but not the heap. It may not be needed, but still. Secondly, if you think there is some endianess issues… Tell the compiler to follow the convention you want! See [Gem #140: Bridging the Endianness Gap | AdaCore](https://www.adacore.com/gems/gem-140-bridging-the-endianness-gap) `type Arbitrary_Unmapped_Space is array (Positive range <>) of Boolean with Component_Size => 1, Unreferenced;` I would add the `Pack` attribute or even the `Size` too, just for good measure. > [@sidisyom](#): > > Interestingly enough, the _exact_ same mapping when passed through an older gprbuild i.e.: If you sourced the Community package from 2021, you are not just using an older GPRbuild, but an entirely different toolchain too! I believe Alire already has the newer GPRbuild v24, so you should be able to update to it using the `toolchain` system of Alire. Additionally, what happens if you build your code in release mode in Alire? What happens if you do an assembly comparison between the different generated binaries from the different toolchains? Best regards, Fer --- _[View the full topic](https://forum.ada-lang.io/t/weird-behaviour-in-record-mapping/1825)._