On Wed, Jul 31, 2013 at 11:03:09AM +0200, Jean-Francois Moine wrote:
>On Tue, 30 Jul 2013 10:49:04 +0100
>Will Deacon wrote:
>
>> On Tue, Jul 30, 2013 at 10:38:53AM +0100, Jean-Francois Moine wrote:
>> > BTW, kernels compiled with gcc-4.8 don't work.
>>
>> Erm. Can you elaborate please? There w
[Adding Gregory, as this is a Marvell CPU]
On Wed, Jul 31, 2013 at 10:03:09AM +0100, Jean-Francois Moine wrote:
> I compiled the 3.11.0-rc3 with gcc-4.8.1 and I still get oops in ext3
> (no problem when compiled with gcc-4.6). Here is the dmesg.
There were some recent errata fixes from Gregory an
On Tue, 30 Jul 2013 10:49:04 +0100
Will Deacon wrote:
> On Tue, Jul 30, 2013 at 10:38:53AM +0100, Jean-Francois Moine wrote:
> > BTW, kernels compiled with gcc-4.8 don't work.
>
> Erm. Can you elaborate please? There was an issue where SLUB would get
> miscompiled with 4.8 due to some per-cpu
On 07/30/2013 06:09 AM, Jean-Francois Moine wrote:
> On Tue, 30 Jul 2013 10:44:57 +0100
> Dave Martin wrote:
>> On Tue, Jul 30, 2013 at 11:38:53AM +0200, Jean-Francois Moine wrote:
>>> On Tue, 30 Jul 2013 10:25:18 +0100
>>> Dave Martin wrote:
The pragmatic route is less contraversial and low
On Tue, Jul 30, 2013 at 12:09:07PM +0200, Jean-Francois Moine wrote:
> On Tue, 30 Jul 2013 10:44:57 +0100
> Dave Martin wrote:
>
> > On Tue, Jul 30, 2013 at 11:38:53AM +0200, Jean-Francois Moine wrote:
> > > On Tue, 30 Jul 2013 10:25:18 +0100
> > > Dave Martin wrote:
> > >
> > > > The pragmat
On Tue, 30 Jul 2013 10:44:57 +0100
Dave Martin wrote:
> On Tue, Jul 30, 2013 at 11:38:53AM +0200, Jean-Francois Moine wrote:
> > On Tue, 30 Jul 2013 10:25:18 +0100
> > Dave Martin wrote:
> >
> > > The pragmatic route is less contraversial and lower overhead: even though
> > > it's not correct
On Tue, Jul 30, 2013 at 10:38:53AM +0100, Jean-Francois Moine wrote:
> BTW, kernels compiled with gcc-4.8 don't work.
Erm. Can you elaborate please? There was an issue where SLUB would get
miscompiled with 4.8 due to some per-cpu variable reordering across
barrier(), but I fixed that for ARM in 3.
On Tue, Jul 30, 2013 at 11:38:53AM +0200, Jean-Francois Moine wrote:
> On Tue, 30 Jul 2013 10:25:18 +0100
> Dave Martin wrote:
>
> > The pragmatic route is less contraversial and lower overhead: even though
> > it's not correct as per the ABI, GCC is the only supported compiler for
> > building t
On Tue, 30 Jul 2013 10:25:18 +0100
Dave Martin wrote:
> The pragmatic route is less contraversial and lower overhead: even though
> it's not correct as per the ABI, GCC is the only supported compiler for
> building the kernel anyway.
BTW, kernels compiled with gcc-4.8 don't work.
Did anybody su
On Mon, Jul 29, 2013 at 02:21:40PM -0700, Jed Davis wrote:
> On Mon, Jul 22, 2013 at 07:52:39PM +0100, Dave Martin wrote:
> > On Sun, Jul 21, 2013 at 10:37:53PM +0100, Will Deacon wrote:
> > > Ok, I think I'm with you now. I also think that a better solution would be
> > > to try and limit the r7/f
On Mon, Jul 22, 2013 at 07:52:39PM +0100, Dave Martin wrote:
> On Sun, Jul 21, 2013 at 10:37:53PM +0100, Will Deacon wrote:
> > Ok, I think I'm with you now. I also think that a better solution would be
> > to try and limit the r7/fp confusion to one place, perhaps behind something
> > like:
> >
>
On Sun, Jul 21, 2013 at 10:37:53PM +0100, Will Deacon wrote:
> Hello Jed,
>
> Thanks for the reply.
>
> On Sat, Jul 20, 2013 at 05:46:55AM +0100, Jed Davis wrote:
> > On Mon, Jul 15, 2013 at 02:54:20PM +0100, Will Deacon wrote:
> > > On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
> >
On 21.07.13 22:37:53, Will Deacon wrote:
> Ok, I think I'm with you now. I also think that a better solution would be
> to try and limit the r7/fp confusion to one place, perhaps behind something
> like:
>
> void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe
> *frame);
In un
Hello Jed,
Thanks for the reply.
On Sat, Jul 20, 2013 at 05:46:55AM +0100, Jed Davis wrote:
> On Mon, Jul 15, 2013 at 02:54:20PM +0100, Will Deacon wrote:
> > On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
> [...]
> > > Effects of this are probably limited to failure of EHABI unwindin
On Mon, Jul 15, 2013 at 02:54:20PM +0100, Will Deacon wrote:
> On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
[...]
> > Effects of this are probably limited to failure of EHABI unwinding when
> > starting from a function that uses r7 to restore its stack pointer, but
> > the possibility
Hi Jed,
On Sat, Jul 13, 2013 at 04:18:20AM +0100, Jed Davis wrote:
> There is currently some inconsistency about the "frame pointer" on ARM.
> r11 is the register with assemblers recognize and disassemblers often
> print as "fp", and which is sufficient for stack unwinding when using
> the APCS fr
There is currently some inconsistency about the "frame pointer" on ARM.
r11 is the register with assemblers recognize and disassemblers often
print as "fp", and which is sufficient for stack unwinding when using
the APCS frame pointer option; but when unwinding with the Exception
Handling ABI, the
17 matches
Mail list logo
