RE: [Bluez-devel] Alignment issue

[David Woodhouse <dwmw2@infradead.org>]

On Thu, 2004-08-12 at 11:27 +0200, Marcel Holtmann wrote:
> I am not an expert when it comes to specific compiler stuff and I can't
> make the best decision with my limited information. What I realized is
> that we need our own unaligned access implementation, because we can't
> rely on the asm/unaligned.h. So I started to put our own in bluetooth.h
> for general access. If this was wrong, please correct me.

No, that was entirely correct. I may even have prodded you to do it
after packaging bluez-utils for all the Fedora architectures. 

> Some platforms can do unaligned access by themself and some are not. At
> the moment only the i386 is listed, but we should list others like AMD64
> and PowerPC. Patches and hints are welcome. For the rest the generic way
> is to use memcpy, but actually every architecture uses memmove, because
> of the GCC __builtin_memcpy problem. Some of them like Alpha and ARM are
> using specific implementations, but using the macro with memmove seems
> also to work fine there. I like to keep the unaligned macros as short as
> possible.
> 
> Do anyone wrote an autoconf macro for checking if memmove works like
> expected or if it gets optimized by the compiler?

Autocrap considered harmful; I'd rather let the compiler do it.
The reason the compiler isn't doing what you want with memcpy is because
it 'knows' the source pointer is aligned, because it was a pointer to,
for example, an int, and it knows that such pointers have certain
alignment. You need to stop the compiler from 'knowing' that. Ways of
achieving this include __attribute__((packed)) -- you could try
something like this:

#define put_unaligned(ptr, val) { \
	struct { typeof(*ptr) __v } __attribute__((packed)) __p; \
	__p = (void *)(ptr); \
	__p->__v = (val); \
}

Now gcc will know that the object '__v' it's loading from the packed
structure may not be aligned, and it should emit code optimal for the
architecture in question.

The above was typed into the email -- it probably won't even compile,
let alone work. But variations on the theme should work. In fact I'm not
entirely sure we even need the structure -- we might be able to get away
with 
	(typeof (*ptr)) *__p __attribute__((packed));
	*__p = (val);

-- 
dwmw2