On Thu, Jul 03, 2014 at 06:05:58PM +0100, Russell King - ARM Linux wrote:
quoted
On Thu, Jul 03, 2014 at 05:22:30PM +0100, Grant Likely wrote:
quoted
So, no. I completely reject any notion that breaking existing apps is
okay. If we're going to say that v8 still supports 32-bit apps, then
it has to be all of v7, not just the 'good' bits. Nor do I think
saying "it's just a bunch of games" justifies anything. We're kernel
engineers. Applications are applications and we don't break userspace.
Period.
+1 on all points above. I'd go further - if we're going to say that v8
still supports 32-bit apps, that covers at least v6 *as well*.
We've never pretended to support anything other than ARMv8 in the compat
layer. uname even reports this in the machine name.
If people are suddenly so concerned about *full* compatibility with an ARMv7
kernel, that needs a lot more than just SWP emulation:
- Alignment fixups for ldm/stm
No ARM variant ever supported unaligned ldm/stm.
--
M?ns Rullg?rd
mans at mansr.com
From: Russell King - ARM Linux <hidden> Date: 2014-07-03 22:47:53
On Thu, Jul 03, 2014 at 11:16:16PM +0100, M?ns Rullg?rd wrote:
Will Deacon [off-list ref] writes:
quoted
On Thu, Jul 03, 2014 at 06:05:58PM +0100, Russell King - ARM Linux wrote:
quoted
On Thu, Jul 03, 2014 at 05:22:30PM +0100, Grant Likely wrote:
quoted
So, no. I completely reject any notion that breaking existing apps is
okay. If we're going to say that v8 still supports 32-bit apps, then
it has to be all of v7, not just the 'good' bits. Nor do I think
saying "it's just a bunch of games" justifies anything. We're kernel
engineers. Applications are applications and we don't break userspace.
Period.
+1 on all points above. I'd go further - if we're going to say that v8
still supports 32-bit apps, that covers at least v6 *as well*.
We've never pretended to support anything other than ARMv8 in the compat
layer. uname even reports this in the machine name.
If people are suddenly so concerned about *full* compatibility with an ARMv7
kernel, that needs a lot more than just SWP emulation:
- Alignment fixups for ldm/stm
No ARM variant ever supported unaligned ldm/stm.
Quite right but that's not the point being discussed. Please note that
the sentence says "with an ARMv7 *kernel*" - we are not talking about
the architecture there.
So, what's more to the point is that on 32-bit ARM userspace under Linux,
we _have_ supported it since early 2000 up to present. It's not currently
supported on 64-bit ARM running Linux, even when running a 32-bit binary
in userspace.
Ergo, it's a user visible ABI change, one which we don't know whether it
matters. In all probability, it doesn't because (hopefully) no one ever
does unaligned LDMs/STMs - I think it would require hand-crafted assembly,
at which point you're talking about optimising something, and you'd be
silly to do it as it would invoke the alignment fault handling which
would be slow.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
On 4 July 2014 00:47, Russell King - ARM Linux [off-list ref] wrote:
On Thu, Jul 03, 2014 at 11:16:16PM +0100, M?ns Rullg?rd wrote:
quoted
Will Deacon [off-list ref] writes:
quoted
On Thu, Jul 03, 2014 at 06:05:58PM +0100, Russell King - ARM Linux wrote:
quoted
On Thu, Jul 03, 2014 at 05:22:30PM +0100, Grant Likely wrote:
quoted
So, no. I completely reject any notion that breaking existing apps is
okay. If we're going to say that v8 still supports 32-bit apps, then
it has to be all of v7, not just the 'good' bits. Nor do I think
saying "it's just a bunch of games" justifies anything. We're kernel
engineers. Applications are applications and we don't break userspace.
Period.
+1 on all points above. I'd go further - if we're going to say that v8
still supports 32-bit apps, that covers at least v6 *as well*.
We've never pretended to support anything other than ARMv8 in the compat
layer. uname even reports this in the machine name.
If people are suddenly so concerned about *full* compatibility with an ARMv7
kernel, that needs a lot more than just SWP emulation:
- Alignment fixups for ldm/stm
No ARM variant ever supported unaligned ldm/stm.
Quite right but that's not the point being discussed. Please note that
the sentence says "with an ARMv7 *kernel*" - we are not talking about
the architecture there.
So, what's more to the point is that on 32-bit ARM userspace under Linux,
we _have_ supported it since early 2000 up to present. It's not currently
supported on 64-bit ARM running Linux, even when running a 32-bit binary
in userspace.
Ergo, it's a user visible ABI change, one which we don't know whether it
matters. In all probability, it doesn't because (hopefully) no one ever
does unaligned LDMs/STMs - I think it would require hand-crafted assembly,
at which point you're talking about optimising something, and you'd be
silly to do it as it would invoke the alignment fault handling which
would be slow.
Well, if something like this
struct bar {
long l[4];
};
void foo(struct bar *dst, struct bar const *src)
{
*dst = *src;
}
produces this:
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov ip, r0
ldmia r1, {r0, r1, r2, r3}
stmia ip, {r0, r1, r2, r3}
bx lr
won't it take just a single cast from some unaligned char* to struct
bar* to trigger this?
--
Ard.
On Fri, Jul 04, 2014 at 08:08:05AM +0100, Ard Biesheuvel wrote:
On 4 July 2014 00:47, Russell King - ARM Linux [off-list ref] wrote:
quoted
On Thu, Jul 03, 2014 at 11:16:16PM +0100, M?ns Rullg?rd wrote:
quoted
Will Deacon [off-list ref] writes:
quoted
On Thu, Jul 03, 2014 at 06:05:58PM +0100, Russell King - ARM Linux wrote:
quoted
On Thu, Jul 03, 2014 at 05:22:30PM +0100, Grant Likely wrote:
quoted
So, no. I completely reject any notion that breaking existing apps is
okay. If we're going to say that v8 still supports 32-bit apps, then
it has to be all of v7, not just the 'good' bits. Nor do I think
saying "it's just a bunch of games" justifies anything. We're kernel
engineers. Applications are applications and we don't break userspace.
Period.
+1 on all points above. I'd go further - if we're going to say that v8
still supports 32-bit apps, that covers at least v6 *as well*.
We've never pretended to support anything other than ARMv8 in the compat
layer. uname even reports this in the machine name.
If people are suddenly so concerned about *full* compatibility with an ARMv7
kernel, that needs a lot more than just SWP emulation:
- Alignment fixups for ldm/stm
No ARM variant ever supported unaligned ldm/stm.
Quite right but that's not the point being discussed. Please note that
the sentence says "with an ARMv7 *kernel*" - we are not talking about
the architecture there.
So, what's more to the point is that on 32-bit ARM userspace under Linux,
we _have_ supported it since early 2000 up to present. It's not currently
supported on 64-bit ARM running Linux, even when running a 32-bit binary
in userspace.
Ergo, it's a user visible ABI change, one which we don't know whether it
matters. In all probability, it doesn't because (hopefully) no one ever
does unaligned LDMs/STMs - I think it would require hand-crafted assembly,
at which point you're talking about optimising something, and you'd be
silly to do it as it would invoke the alignment fault handling which
would be slow.
Well, if something like this
struct bar {
long l[4];
};
void foo(struct bar *dst, struct bar const *src)
{
*dst = *src;
}
produces this:
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov ip, r0
ldmia r1, {r0, r1, r2, r3}
stmia ip, {r0, r1, r2, r3}
bx lr
won't it take just a single cast from some unaligned char* to struct
bar* to trigger this?
Is this even allowed by the C ABI? The compiler generates the LDMs
because function foo() gets a struct pointer which is guaranteed to be
aligned.
--
Catalin
On 4 July 2014 10:24, Catalin Marinas [off-list ref] wrote:
On Fri, Jul 04, 2014 at 08:08:05AM +0100, Ard Biesheuvel wrote:
quoted
On 4 July 2014 00:47, Russell King - ARM Linux [off-list ref] wrote:
quoted
On Thu, Jul 03, 2014 at 11:16:16PM +0100, M?ns Rullg?rd wrote:
quoted
Will Deacon [off-list ref] writes:
quoted
On Thu, Jul 03, 2014 at 06:05:58PM +0100, Russell King - ARM Linux wrote:
quoted
On Thu, Jul 03, 2014 at 05:22:30PM +0100, Grant Likely wrote:
quoted
So, no. I completely reject any notion that breaking existing apps is
okay. If we're going to say that v8 still supports 32-bit apps, then
it has to be all of v7, not just the 'good' bits. Nor do I think
saying "it's just a bunch of games" justifies anything. We're kernel
engineers. Applications are applications and we don't break userspace.
Period.
+1 on all points above. I'd go further - if we're going to say that v8
still supports 32-bit apps, that covers at least v6 *as well*.
We've never pretended to support anything other than ARMv8 in the compat
layer. uname even reports this in the machine name.
If people are suddenly so concerned about *full* compatibility with an ARMv7
kernel, that needs a lot more than just SWP emulation:
- Alignment fixups for ldm/stm
No ARM variant ever supported unaligned ldm/stm.
Quite right but that's not the point being discussed. Please note that
the sentence says "with an ARMv7 *kernel*" - we are not talking about
the architecture there.
So, what's more to the point is that on 32-bit ARM userspace under Linux,
we _have_ supported it since early 2000 up to present. It's not currently
supported on 64-bit ARM running Linux, even when running a 32-bit binary
in userspace.
Ergo, it's a user visible ABI change, one which we don't know whether it
matters. In all probability, it doesn't because (hopefully) no one ever
does unaligned LDMs/STMs - I think it would require hand-crafted assembly,
at which point you're talking about optimising something, and you'd be
silly to do it as it would invoke the alignment fault handling which
would be slow.
Well, if something like this
struct bar {
long l[4];
};
void foo(struct bar *dst, struct bar const *src)
{
*dst = *src;
}
produces this:
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov ip, r0
ldmia r1, {r0, r1, r2, r3}
stmia ip, {r0, r1, r2, r3}
bx lr
won't it take just a single cast from some unaligned char* to struct
bar* to trigger this?
Is this even allowed by the C ABI? The compiler generates the LDMs
because function foo() gets a struct pointer which is guaranteed to be
aligned.
Well, I was merely responding to Russell's assertion that it would
require hand-crafted assembly to trigger alignment faults in ldm/stm
instructions.
The point is not whether the C ABI allows it, the point is whether
a) the current 32-bit ARM kernel allows it, and
b) how likely it is to appear in existing code
--
Ard.