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
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 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
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
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
> > > 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 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
21 matches
Mail list logo
