On Sat, Jun 05, 2010 at 09:19:51AM +0200, Geert Uytterhoeven wrote: > On Sat, Jun 5, 2010 at 00:52, Richard Zidlicky <r...@linux-m68k.org> wrote: > > On Fri, Jun 04, 2010 at 10:57:50PM +0200, Geert Uytterhoeven wrote:
> > this is the hardware behaviour but the compiler is free to use more > > alignment > > and it does that. At least for function calls I am pretty sure the minumum > > is > > guaranteed to be 4 bytes. > > This is because for function calls the compiler must work work with the > > assumption that the function may be invoked without a proper prototype > > declaration from an external module (which is hackish but perfectly legal > > in K&R) and for this reason K&R mandates a storage size that is large enough > > to accomodate both long or pointer. > > And the alignment rules for long and pointer are 2-byte alignment... they are. Otoh the compiler is free to align them to 4 bytes without breaking api - the exception is alignment inside structs and arrays which are part of defined api. However as I understand it futexes are new api (which never worked so far) so we do not break anything if the futexes get a special attribute forcing their alignment inside structs. I think Andreas was specifically worrying about the case where a futex is allocated inside a struct that gets allocated on stack. Its easy (I think) to align the futex inside the struct but more complicated to control how the whole struct gets placed on stack. As I see it the stack-allocated futex could be automagicaly aligned when pushed as argument to a function - the arguments allways ocupy at least 4 bytes but the stack must be possibly aligned before starting tu push function args. This would not break any api as far as I can see but may require some work and might require new or patched compiler. It should be doable with some of the gcc stack align options but better not rely that it won't get overriden in some makefile. Allocating futexes as local stack variable would work with an align attrib and would not break any api either. Richard -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100605083521.ga6...@linux-m68k.org
