lkml.org 
[lkml]   [2012]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Follow-up to remaining issue with alignment of __log_buf in printk.c
On 06/14/2012 01:19 PM, Robert Jarzmik wrote:
>
> Hi Stephen and others,
>
> I have a XScale PXA based board with has the alignement issue which makes the
> kernel trap during its early stage.
>
> I wonder what is the status now, is there a fix available ?
>
> I have tracked what happens on PXA. The pxa is an ARM v5TE chip. The new printk
> version you submitted is translated to the following assembly on the line :
> msg->ts_nsec = local_clock();
> Into:
> => 0xc001bbe0 <log_store+496>: strd r0, [r4, r5]
>
> In ARMv5, the "strd" assembly opcode expects the address to be 64bits aligned,
> hence the bug.
>
> Now the solutions I have seen so far in the mailing lists :
> - #define LOG_ALIGN (__alignof__(u64))
> Does always work.
> - #define LOG_ALIGN (__alignof__(struct log))
> Doesn't work with my toolchain, as __alignof__(struct log) is 4, not 8

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 suppose this could be worked around with something like:

#define LOG_ALIGN max(__alignof__(struct log), __alignof__(u64))


\
 
 \ /
  Last update: 2012-06-14 22:21    [W:0.040 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site