回复: PR 1098: "struct ipovly" not packed.

[Pavel Pisa]

Hello All,

On Tuesday 27 June 2006 14:26, Denny.Bai wrote:
>   C does give the programmer the ability to violate alignment
> restrictions by casting pointers to different types.  ......... If the
> alignment requirement for a type S is less stringent than that for
> type D, then the conversion from a "pointer to types S"  to a "pointer
> to type D" could result in either of two kinds of unexpected behavior.
>  Firts, an attempt to use the reulting pointer to fetch or store an
> object of type D may cause an error, halting the program. Second,
> either the hardware or the implementation may "adjust" the destination
> pointer to be valid, usually by forcing ti back to the nearest
> previous valid address.

I have only some notices to alignment problems and ARM
architecture. According to my memory, older ARM architecture
members do not recognize misaligned accesses and simply discards
low order bits. It is possible to control, how would ARM
core behave in this situation for newer implementations.
I have not checked now, but it should be controlled
by one of CP15/MMU or MPU registers.

If threre is really requirement to access two (uint32_t+uint16_t) serialized
body to body, than there is problem for ARM (but even for some PowerPC,
m68k, etc), because uint32_t has to be accessed as unaligned data or
at least as two uint16_t. Problem is, that older ARM architecture
versions <4 do not have even LDRH instruction, so 16 bits entities
has to be read by two LDRB => volatile uint_16 is not atomic.

As for RTEMS, there has been some attempt to allow unaligned accesses
for ARM by LDR instruction emulation if core supports unaligned trap.
But this support has been broken and asymmetric, only for LDR and not
for STR instruction. The code has tried to fixup even real program
addressing faults and touched incorrectly computed addresses
(at least according to my observations). Because of safety concerns
I have disabled it. This means, that such access attempt ends
same as other faults. The RTEMS output is fixed, that it provides
to locate offending piece of code

rtems-cvs/cpukit/score/cpu/arm/cpu.c:311

    case INSN_LDR:
        printk("\n\nINSN_LDR\n");

#if 0
        rn = GET_RN(insn);
        rd = GET_RD(insn);

If you find, that this case is triggered by code, then output
could be analyzed. If some emulation is really really required,
it could be done there by enabling fixup code, repairing and testing
it and adding STR support. But I would sleep better, if this
hack would not to be reintroduced.

Best wishes
                Pavel Pisa
        e-mail: pisa at cmp.felk.cvut.cz
        www:    http://cmp.felk.cvut.cz/~pisa
        work:   http://www.pikron.com