[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87y5np1qks.fsf@free.fr>
Date: Fri, 15 Jun 2012 00:22:43 +0200
From: Robert Jarzmik <robert.jarzmik@...e.fr>
To: Stephen Warren <swarren@...dotorg.org>,
Andrew Lunn <andrew@...n.ch>
Cc: swarren@...dia.com, linux-kernel@...r.kernel.org,
haojian.zhuang@...il.com, linux-arm-kernel@...ts.infradead.org,
jic23@....ac.uk, kay@...y.org
Subject: Re: Follow-up to remaining issue with alignment of __log_buf in printk.c
Stephen Warren <swarren@...dotorg.org> writes:
> Isn't that a bug in the toolchain; isn't the alignment of a struct
> required to be the greatest alignment of any of its members? Otherwise,
> this problem could arise with any usage of that struct.
I'm not a compiler expert, but I think EABI requires 64-bit data types to be
8-bytes aligned. If that assertion is true, then clearly my eabi compiler is a
little liar with its __alignof__(struct log) result.
And I think also that ISO C standard requires a structure to be aligned by
default to the <quote>least perfect multiple of the lowest common multiple of
the alignments of all the members of the struct</quote>. Which here means 8
bytes ...
> I suppose this could be worked around with something like:
> #define LOG_ALIGN max(__alignof__(struct log), __alignof__(u64))
Well, I wonder what is the correct approach here. In the end, the compiler
should be fixed ... But meanwhile, your proposition would solve the PXA
problem. The real deal is to know whether we want a compiler work-around in
printk.c ... and that's rather a policy issue than a technical one.
I wonder what others think about it ... let's wait for another pair of point of
views.
Cheers.
--
Robert
PS: For Andrew, I saw your patch. It won't solve my problem as my compiler
believes __alignof__(struct log) == 4 ... bad luck for me.
PPS: My toolchain is arm-2011.09
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists