[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v1] xen/arm: align *(.proc.info) in the linker script



Hi Julien,
> > > On Wed, 2023-03-01 at 16:21 +0000, Julien Grall wrote:
> > > > Hi Oleksii,
> > > > 
> > > > On 01/03/2023 16:14, Oleksii Kurochko wrote:
> > > > > During testing of bug.h's macros generic implementation
> > > > > yocto-
> > > > > qemuarm
> > > > > job crashed with data abort:
> > > > 
> > > > The commit message is lacking some information. You are telling
> > > > us
> > > > that
> > > > there is an error when building with your series, but this
> > > > doesn't
> > > > tell
> > > > me why this is the correct fix.
> > > > 
> > > > This is also why I asked to have the xen binary because I want
> > > > to
> > > > check
> > > > whether this was a latent bug in Xen or your series effectively
> > > > introduce a bug.
> > > > 
> > > > Note that regardless what I just wrote this is a good idea to
> > > > align
> > > > __proc_info_start. I will try to have a closer look later and
> > > > propose
> > > > a
> > > > commit message and/or any action for your other series.
> > > Regarding binaries please take a look here:
> > > https://lore.kernel.org/xen-devel/aa2862eacccfb0574859bf4cda8f4992baa5d2e1.camel@xxxxxxxxx/
> > > 
> > > I am not sure if you get my answer as I had the message from
> > > delivery
> > > server that it was blocked for some reason.
> > 
> > I got the answer. The problem now is gitlab only keep the artifact
> > for 
> > the latest build and it only provide a zImage (having the ELF would
> > be 
> > easier).
> > 
> > I will try to reproduce the error on my end.
> 
> I managed to reproduce it. It looks like that after your bug patch, 
> *(.rodata.*) will not be end on a 4-byte boundary. Before your patch,
> all the messages will be in .rodata.str. Now they are in
> .bug_frames.*, 
> so there some difference in .rodata.*.
> 
> That said, it is not entirely clear why we never seen the issue
> before 
> because my guessing there are no guarantee that .rodata.* will be 
> suitably aligned.
> 
> Anyway, here a proposal for the commit message:
> 
> "
> xen/arm: Ensure the start *(.proc.info) of is 4-byte aligned
> 
> The entries in *(.proc.info) are expected to be 4-byte aligned and
> the 
> compiler will access them using 4-byte load instructions. On Arm32,
> the 
> alignment is strictly enforced by the processor and will result to a 
> data abort if it is not correct.
> 
> However, the linker script doesn't encode this requirement. So we are
> at 
> the mercy of the compiler/linker to have aligned the previous
> sections 
> suitably.
> 
> This was spotted when trying to use the upcoming generic bug 
> infrastructure with the compiler provided by Yocto.
> 
> Link: 
> https://lore.kernel.org/xen-devel/6735859208c6dcb7320f89664ae298005f70827b.camel@xxxxxxxxx/
> "
> 
> If you are happy with the proposed commit message, then I can update
> it 
> while committing.
I am happy with the proposed commit message.

Thanks a lot.

~ Oleksii



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.