On Fri, Jun 17, 2011 at 03:23:49PM -0700, Steve Langasek wrote:
> On Fri, Jun 17, 2011 at 01:10:11PM +0100, Dave Martin wrote:
>
> > For ARM, we can achieve the goal by augmenting the default kernel command-
> > line options: either
>
> > alignment=3
> > Fix up each alingment fault, b
On Sat, Jun 18, 2011 at 10:48:16AM -0400, Nicolas Pitre wrote:
> On Sat, 18 Jun 2011, Arnd Bergmann wrote:
>
> > On Friday 17 June 2011, Nicolas Pitre wrote:
> > > On Fri, 17 Jun 2011, Arnd Bergmann wrote:
> > > > On Friday 17 June 2011 14:10:11 Dave Martin wrote:
> > > >
> > > > > As part of the
On Sat, Jun 18, 2011 at 03:17:59PM -0400, Nicolas Pitre wrote:
> On Sat, 18 Jun 2011, Arnaud Patard wrote:
>
> > Dave Martin writes:
> > Hi,
> >
> > > Hi all,
> > >
> > > I've recently become aware that a few packages are causing alignment
> > > faults on ARM, and are relying on the alignment fi
On Fri, Jun 17, 2011 at 11:53:21PM +0100, Paul Brook wrote:
> > >> There is still going to be a small cost even in hardware fixup so this
> > >> is very much worth solving despite it's "becoming invisible" because the
> > >> chips are hiding / solving it already.
> > >
> > > But I believe that h/w
On 18 June 2011 22:17, Nicolas Pitre wrote:
> Turns out that a prominent ARM developer still has binaries from the
> ARMv3 era around, and the default of not fixing up misaligned user space
> accesses is for remaining compatible with them.
> So if you do have a version of glibc that is not from 1
On Sat, 18 Jun 2011, Arnaud Patard wrote:
> Dave Martin writes:
> Hi,
>
> > Hi all,
> >
> > I've recently become aware that a few packages are causing alignment
> > faults on ARM, and are relying on the alignment fixup emulation code in
> > the kernel in order to work.
> >
> > Such faults are ve
On Sat, 18 Jun 2011, Nicolas Pitre wrote:
> int main(int argc, char * argv[])
> {
> char buf[8];
> void *v = &buf[1];
> unsigned int *p = (unsigned int *)v;
>
> strcpy(buf, "abcdefg");
>
> printf("*%p = 0x%08x\n", p, *p);
>
> return 0;
> }
Obviously, there is a bu
On Sat, 18 Jun 2011, Arnd Bergmann wrote:
> On Friday 17 June 2011, Nicolas Pitre wrote:
> > On Fri, 17 Jun 2011, Arnd Bergmann wrote:
> > > On Friday 17 June 2011 14:10:11 Dave Martin wrote:
> > >
> > > > As part of the general effort to make open source on ARM better, I
> > > > think
> > > >
On Sat, 18 Jun 2011, Paul Brook wrote:
> > > > char buf[8];
> > > > void *v = &buf[1];
> > > > unsigned int *p = (unsigned int *)v;
> > >
> > > This does not (reliably) do what you expect. The compiler need not align
> > > buf.
> >
> > Printing the value of p should clarify th
Dave Martin writes:
Hi,
> Hi all,
>
> I've recently become aware that a few packages are causing alignment
> faults on ARM, and are relying on the alignment fixup emulation code in
> the kernel in order to work.
>
> Such faults are very expensive in terms of CPU cycles, and can generally
> only r
On 06/17/2011 11:53 PM, Somebody in the thread at some point said:
Hi -
int main(int argc, char * argv[])
{
char buf[8];
void *v =&buf[1];
unsigned int *p = (unsigned int *)v;
This does not (reliably) do what you expect. The compiler need not align buf.
What? Somebod
> > > char buf[8];
> > > void *v = &buf[1];
> > > unsigned int *p = (unsigned int *)v;
> >
> > This does not (reliably) do what you expect. The compiler need not align
> > buf.
>
> Printing the value of p should clarify this.
>
> And, as we can see above, the "simple" accesses
On Friday 17 June 2011, Nicolas Pitre wrote:
> On Fri, 17 Jun 2011, Arnd Bergmann wrote:
> > On Friday 17 June 2011 14:10:11 Dave Martin wrote:
> >
> > > As part of the general effort to make open source on ARM better, I think
> > > it would be great if we can disable the alignment fixups (or at
On Fri, 17 Jun 2011, Paul Brook wrote:
> > >> There is still going to be a small cost even in hardware fixup so this
> > >> is very much worth solving despite it's "becoming invisible" because the
> > >> chips are hiding / solving it already.
> > >
> > > But I believe that h/w feature is turned o
> >> There is still going to be a small cost even in hardware fixup so this
> >> is very much worth solving despite it's "becoming invisible" because the
> >> chips are hiding / solving it already.
> >
> > But I believe that h/w feature is turned off in Linux by default. You
> > have to add noalig
On Fri, Jun 17, 2011 at 01:10:11PM +0100, Dave Martin wrote:
> For ARM, we can achieve the goal by augmenting the default kernel command-
> line options: either
> alignment=3
> Fix up each alingment fault, but also log the faulting address
> and name of the offending process t
On 06/17/2011 08:17 PM, Somebody in the thread at some point said:
On 06/17/2011 08:11 AM, Andy Green wrote:
On 06/17/2011 01:10 PM, Somebody in the thread at some point said:
Hi -
I've recently become aware that a few packages are causing alignment
faults on ARM, and are relying on the align
On Fri, 17 Jun 2011, Arnd Bergmann wrote:
> On Friday 17 June 2011 14:10:11 Dave Martin wrote:
>
> > As part of the general effort to make open source on ARM better, I think
> > it would be great if we can disable the alignment fixups (or at least
> > enable logging) and work with upstreams to g
On 06/17/2011 08:11 AM, Andy Green wrote:
> On 06/17/2011 01:10 PM, Somebody in the thread at some point said:
>
> Hi -
>
>> I've recently become aware that a few packages are causing alignment
>> faults on ARM, and are relying on the alignment fixup emulation code in
>> the kernel in order to wo
On 06/17/2011 01:10 PM, Somebody in the thread at some point said:
Hi -
I've recently become aware that a few packages are causing alignment
faults on ARM, and are relying on the alignment fixup emulation code in
the kernel in order to work.
Just a FYI a lot of later ARM chips are solving ali
On Friday 17 June 2011 14:10:11 Dave Martin wrote:
> As part of the general effort to make open source on ARM better, I think
> it would be great if we can disable the alignment fixups (or at least
> enable logging) and work with upstreams to get the affected packages
> fixed.
>
> For release im
Hi all,
I've recently become aware that a few packages are causing alignment
faults on ARM, and are relying on the alignment fixup emulation code in
the kernel in order to work.
Such faults are very expensive in terms of CPU cycles, and can generally
only result from wrong code (for example, C/C+
22 matches
Mail list logo
