Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Fri, 1 Dec 2006 10:15:08 -0700

Kay,

There are lots of good reasons to declare your pointers to device register
overlay structures with the volatile keyword, and if you do then you won't
need to be concern yourself with strict aliasing issues.

Jeff

> -----Original Message-----
> From: Kay-Uwe Kasemir [mailto:[email protected]]
> Sent: Friday, December 01, 2006 8:04 AM
> To: Core talk list
> Subject: Re: More strict aliasing
> 
> Hi:
> 
> So what is the solution?
> Avoid any clever pointer fiddling,
> instead perform every memory access
> (I/O buffer, mapped hardware registers)
> via routines like sysInByte(address),  sysInLong(address), ...
> where those routines are either offered by the OS
> (as in the case of vxWorks),
> or created via #asm statements and carefully tested?
> 
> Something like the libCom devLib could provide
> wrappers (ideally macros) for those OS-dependent
> implementations.
> 
> -Kay
> 
> 
> On Dec 1, 2006, at 09:54 , Eric Norum wrote:
> 
> > I'm forwarding this message from Till.    The -fno-strict-aliasing
> > debate is in full swing on the RTEMS mailing lists so I thought I'd
> > spread some of the excitement here.
> >
> > Begin forwarded message:
> >
> >> From: Till Straumann <[email protected]>
> >> Date: November 30, 2006 7:16:47 PM CST
> >> To: [email protected]
> >> Cc: Ralf Corsepius <[email protected]>
> >> Subject: More strict aliasing
> >>
> >> Here's another example that breaks strict aliasing rules
> >> but illustrates a scenario quite commonly found
> >> in a OS/driver environment:
> >>
> >> Assume we have a device (serial device, ethernet chip, fifo, ...)
> >> that can only be accessed with 16-bit bus cycles and we code an
> >> generic 'read' access routine:
> >>
> >> typedef uint16_t  PortType;
> >>
> >> extern volatile PortType *fifo_port;
> >>
> >> static inline void
> >> rd_fifo(void *item, int n_words)
> >> {
> >> PortType *dst = item;
> >>     while (n_words--)
> >>        *dst++ = *fifo_port;
> >> }
> >>
> >> Then someone reads bigger items from the device
> >>
> >> uint32_t readInt()
> >> {
> >>    uint32_t val;
> >>
> >>    rd_fifo(&val, sizeof(val)/sizeof(PortType));
> >>
> >>    return val;
> >> }
> >>
> >> And *bang* they have violated the rule (because val is an uint32_t
> >> and *dst is a uint16_t which must not alias).
> >>
> >> Indeed, gcc (checked i386 disassembly) generates code that
> >> doesn't produce the intended result. The store operation of the
> >> second 16-bit word is optimized away.
> >>
> >> OK, it would be easy to correct this particular example but
> >> I find the alias rule extremely cumbersome at the OS / driver
> >> level where you often deal with bit-representations etc.
> >>
> >> Try to code an inlineable 'rd_fifo()' routine w/o knowledge
> >> about the target objects where the data are to be deposited.
> >>
> >> Plus, there are much more obscure cases [dig around in the C99
> >> committee discussions for fun].
> >>
> >> Basically, it makes 'serializing' [other than into a byte-stream]
> >> almost impossible. Keep in mind that gcc doesn't fully enforce
> >> the standard [e.g., it doesn't use the rule if the accessed object
> >> is in a different compilation unit].
> >>
> >> Another good example are checksums:
> >>
> >> inline unsigned csum(void *data, int size);
> >>
> >> struct blah xx;
> >>
> >>            xx.non_int_nor_char_field = value;
> >>
> >>            csum(&xx, sizeof(xx));
> >>
> >> If the checksum is computed over 16-bit or 32-bit words
> >> (as usually done in networking stacks)
> >> then there is no guarantee that non_int_nor_char_field
> >> is written before the checksum is computed since the
> >> compiler can assume it doesn't alias to an 'int'.
> >>
> >> I wish they had made this optional but *it is not*.
> >> It is the C99 *standard*.
> >>
> >> To me, the fact that many software packages 'just work'
> >> doesn't indicate that they obey strictly to the rule but rather
> >> that it is extremely hard to check and enforce. I suspect
> >> that in many cases violation just goes undetected and doesn't
> >> cause problems because the compiler doesn't use the rule for
> >> optimization [because in many cases there is no gain].
> >>
> >> -- Till
> >> _______________________________________________
> >> rtems-users mailing list
> >> [email protected]
> >> http://rtems.rtems.org/mailman/listinfo/rtems-users
> >
> > --
> > Eric Norum <[email protected]>
> > Advanced Photon Source
> > Argonne National Laboratory
> > (630) 252-4793
> >
> >

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System