This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH, AARCH64] align long branch stubs
- From: Jim Wilson <jim dot wilson at linaro dot org>
- To: Andrew Pinski <pinskia at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Thu, 2 Jun 2016 23:56:47 -0700
- Subject: Re: [PATCH, AARCH64] align long branch stubs
- Authentication-results: sourceware.org; auth=none
- References: <CABXYE2UOkCbiFQTJ7kijLUTMy25unww4w2Q_xSMf6icLS7xxog at mail dot gmail dot com> <CA+=Sn1=X-kjvxZVcqkzF5tzL2qE2bTtgeg4HyRzPjwDNnN0N5w at mail dot gmail dot com>
On Thu, Jun 2, 2016 at 10:43 PM, Andrew Pinski <email@example.com> wrote:
> On Thu, Jun 2, 2016 at 10:16 PM, Jim Wilson <firstname.lastname@example.org> wrote:
>> I got a bug report from Qualcomm that says if you set the A bit in the
>> SCTLR register, to trap on unaligned accesses, their code fails,
>> because the toolchain itself is emitting unaligned data accesses.
> That should not matter. Setting bit A on the SCTLR register is not a
> valid thing to do for A class processors.
> Not that it is a problem in general to align the data after all but it
> should not matter in general.
I think what you mean here is that it is wrong to permanently set bit
A in SCTLR on a multiuser multiprogrammed server running Linux. But
on a single user device, being used for software development and
testing, I don't see why it is wrong to set the A bit in SCTLR,
perhaps temporarily, to verify that code has been correctly written
and compiled to avoid unaligned accesses which are slower than aligned
accesses. This should work, and can work, if the toolchain stops
emitting unaligned data in long branch stubs.