RE: [Bluez-devel] Alignment issue

[Marcel Holtmann <marcel@holtmann.org>]

Hi David,

> > 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. 

btw what is the status of BlueZ for Fedora Core. Currently I know the
status of them for Debian and SuSE. Are there any extra patches that I
must know of? How do you split the bluez-utils into different packages?

> > 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.

Actually I meant to let autoconf compile some test code, then run it and
analyse that result.

> 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);

For now I will use memmove, but we need clarification on this. I lost my
Sun Ultra system, so I can't do any tests.

Please send me the additional compiler defines for architectures that
can do unaligned access by themself.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel