Hi Lennart On Wed, Sep 27, 2017 at 3:39 PM, Lennart Sorensen <[email protected]> wrote: > On Wed, Sep 27, 2017 at 02:37:39PM +0100, Andreas Glatz wrote: >> It's true according to the ARM doc [1]. But the pDat alignment is >> prescribed by the sender and we're at the receiver. So I guess the >> question is how to tell the assembler not to use ldm in the first >> place? > > It certainly looks like the code somehow is optimizing two consequitive > 32 bit reads into a single 64 bit read, but then the input is not 64 bit > aligned (but is 32 bit aligned) which causes an alignment exception on > the 64 bit read while the 32 bit reads were fine. > > One would think the compiler should NOT be doing that.
Yes, one would think so... > > Now as far as I remember, armv7 (which is what you appear to have) > allows unaligned accesses to normal memory, but not to IO ports or other > special memory. I recall hitting a case where someone had flagged > some memory as DMA which caused the alignement exception to be hit. > Since the memory really had no reason to be flagged for DMA or anything > else special it was easy to fix. I shall try to play with these options then. As explained to Philippe and hinted by you one would ideally want a flag to mark a memory regions as 'unaligned' so that the compiler/assembler know that they should only use instructions that support unaligned access, albeit being slower. > > Is the memory at your pointer allocated with any special flags or is > it device memory? Because if it isn't, then you shouldn't as far as I > recall be hitting that exception. The memory is malloc'd before the Xenomai thread starts, but after locking all the pages into memory (the usual Xenomai startup stuff). > > Part of the problem seems to be that gcc optimizes with the assumption > that it is always talking to normal memory on arm and hence no alignment > rules apply anymore, but in driver code talking to IO and in cases where > you are flagging memory for DMA and such, gcc's optimizations get you > in trouble if you don't hit it with a stick in the right places. Apparently :) Other option would be to write my own access function for this piece of memory in assembly... then there'd be no room for wiggling around anymore. Cheers, A. _______________________________________________ Xenomai mailing list [email protected] https://xenomai.org/mailman/listinfo/xenomai
