* Riku Voipio riku.voi...@iki.fi, 2014-11-24, 11:07:
Sparc is definitely not ok. For evidence, see #721617, liblo was
trying to fetch a double from a 4-byte aligned address. Experience
with liblo shows that other architectures are just fine (or at least
are just slower) with this type of
Usually when you're loading an unaligned value you're also loading a
particular representation and endianness, which might not be the
native one, so I've often written code like this:
uint32_t load32(void *p)
{
unsigned char *c = p;
return
c[0] | (uint32_t)c[1] 8 | (uint32_t)c[2] 16 |
On Fri, Nov 21, 2014 at 06:01:11PM +0100, Jakub Wilk wrote:
* Felipe Sateler fsate...@debian.org, 2014-11-21, 14:04:
Sparc is definitely not ok. For evidence, see #721617, liblo was
trying to fetch a double from a 4-byte aligned address. Experience
with liblo shows that other architectures are
On Sat, Nov 22, 2014 at 11:03:16PM +0100, Bastien ROUCARIES wrote:
On Sat, Nov 22, 2014 at 10:37 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Sat, Nov 22, 2014 at 09:42:43PM +0100, Jakub Wilk wrote:
* Henrique de Moraes Holschuh h...@debian.org, 2014-11-21, 17:34:
i386:
On Fri, Nov 21, 2014 at 02:40:01PM +, Wookey wrote:
Whilst that is nice and correct I'm not sure the meaning is clear to a
software engineer, which is: Don't do unaligned access on arm64. It's
always inefficient, sometimes extremely inefficient, and sometimes
won't work at all.
That's an
On Mon, Nov 24, 2014 at 10:38 AM, Riku Voipio riku.voi...@iki.fi wrote:
On Sat, Nov 22, 2014 at 11:03:16PM +0100, Bastien ROUCARIES wrote:
On Sat, Nov 22, 2014 at 10:37 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Sat, Nov 22, 2014 at 09:42:43PM +0100, Jakub Wilk wrote:
*
On 21/11/14 13:31, Bernhard R. Link wrote:
Otherwise that memory
might afterwards be regarded as lzo_memops_TU2_struct
lzo_memops_TU2_struct is declared with __attribute__((__may_alias__)),
so actually the right thing should be happening WRT aliasing in this case.
On 21/11/14 13:21, Thorsten
On 23/11/14 17:55, Simon McVittie wrote:
Unfortunately, on my x86-64 laptop, my patched liblzo2 with
-DLZO_CFG_NO_UNALIGNED on all architectures seems to be half as fast as
the unpatched one
[...]
I'm trying out a slightly different approach: keeping the unaligned
accesses via casts like
On 23.11.2014 23:11, Simon McVittie wrote:
On 23/11/14 17:55, Simon McVittie wrote:
Unfortunately, on my x86-64 laptop, my patched liblzo2 with
-DLZO_CFG_NO_UNALIGNED on all architectures seems to be half as fast as
the unpatched one
[...]
I'm trying out a slightly different approach:
On 23/11/14 22:30, Julian Taylor wrote:
what works well is just replacing the offending memory loads with the
memcpy call. As the size of the memcpy call is constant the compiler
will take care of emitting code appropriate for the platform.
Ah, even better; the timing on x86-64 comes out the
On Sun, 2014-11-23 at 23:30 +0100, Julian Taylor wrote:
On 23.11.2014 23:11, Simon McVittie wrote:
On 23/11/14 17:55, Simon McVittie wrote:
Unfortunately, on my x86-64 laptop, my patched liblzo2 with
-DLZO_CFG_NO_UNALIGNED on all architectures seems to be half as fast as
the unpatched one
On 23/11/14 22:54, Ben Hutchings wrote:
in this function
void copy_foo(struct foo *dst, const struct foo *src)
{
memcpy(dst, src, sizeof(*dst));
}
the compiler is still allowed to assume that src has the proper
alignment for struct foo and to optimise the
* Henrique de Moraes Holschuh h...@debian.org, 2014-11-21, 17:34:
i386:
__asm__(pushf\norl $0x4,(%esp)\npopf);
It works! Actually, it works so well it makes puts(hello world) die
with SIGBUS. :-(
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
On Sat, Nov 22, 2014 at 09:42:43PM +0100, Jakub Wilk wrote:
* Henrique de Moraes Holschuh h...@debian.org, 2014-11-21, 17:34:
i386:
__asm__(pushf\norl $0x4,(%esp)\npopf);
It works! Actually, it works so well it makes puts(hello world) die with
SIGBUS. :-(
Yeah, that's my experience,
On Sat, Nov 22, 2014 at 10:37 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Sat, Nov 22, 2014 at 09:42:43PM +0100, Jakub Wilk wrote:
* Henrique de Moraes Holschuh h...@debian.org, 2014-11-21, 17:34:
i386:
__asm__(pushf\norl $0x4,(%esp)\npopf);
It works! Actually, it
* Simon McVittie:
- OK: any-i386, any-amd64
SSE2 is part of amd64 and i386, and has strict alignment requirements.
This is why stack alignment bugs in the toolchain are usually fatal.
(We still support SSE2-less i386 installations, I think, but some
libraries will use SSE2 when available.)
A couple of questions for people who know low-level things:
* Of Debian's architectures (official and otherwise), which ones are
known/defined/designed to be OK with unaligned accesses from
user-space, and which ones (can be configured to) crash or give wrong
answers?
* Would it be safer
On Fri, 21 Nov 2014, Simon McVittie wrote:
failing to start up on armel due to unaligned memory accesses. lzo2 has
a cpp macro, LZO_CFG_NO_UNALIGNED which can be defined to stop it doing
clever things with casting pointers. If the maintainer doesn't object
Please define this macro
On Fri, Nov 21, 2014 at 12:42:34PM +, Simon McVittie wrote:
A couple of questions for people who know low-level things:
* Of Debian's architectures (official and otherwise), which ones are
known/defined/designed to be OK with unaligned accesses from
user-space, and which ones (can be
* Simon McVittie s...@debian.org [141121 13:42]:
A couple of questions for people who know low-level things:
* Of Debian's architectures (official and otherwise), which ones are
known/defined/designed to be OK with unaligned accesses from
user-space, and which ones (can be configured to)
https://wiki.debian.org/ArchitectureSpecificsMemo
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546f3ec4.5030...@zoho.com
I thought there was a flag bit you could set on x86 that causes
unaligned access to trap there too.
--Sam
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
On Fri, 21 Nov 2014 12:42:34 +, Simon McVittie wrote:
A couple of questions for people who know low-level things:
* Of Debian's architectures (official and otherwise), which ones are
known/defined/designed to be OK with unaligned accesses from
user-space, and which ones (can be
On Fri, Nov 21, 2014 at 12:42:34PM +, Simon McVittie wrote:
A couple of questions for people who know low-level things:
* Of Debian's architectures (official and otherwise), which ones are
known/defined/designed to be OK with unaligned accesses from
user-space, and which ones (can be
+++ Leif Lindholm [2014-11-21 14:00 +]:
On Fri, Nov 21, 2014 at 12:42:34PM +, Simon McVittie wrote:
A couple of questions for people who know low-level things:
* Of Debian's architectures (official and otherwise), which ones are
known/defined/designed to be OK with unaligned
* Felipe Sateler fsate...@debian.org, 2014-11-21, 14:04:
Sparc is definitely not ok. For evidence, see #721617, liblo was trying
to fetch a double from a 4-byte aligned address. Experience with liblo
shows that other architectures are just fine (or at least are just
slower) with this type of
On Fri, Nov 21, 2014 at 6:01 PM, Jakub Wilk jw...@debian.org wrote:
* Felipe Sateler fsate...@debian.org, 2014-11-21, 14:04:
Sparc is definitely not ok. For evidence, see #721617, liblo was trying to
fetch a double from a 4-byte aligned address. Experience with liblo shows
that other
On 21.11.2014 18:01, Jakub Wilk wrote:
* Felipe Sateler fsate...@debian.org, 2014-11-21, 14:04:
Sparc is definitely not ok. For evidence, see #721617, liblo was
trying to fetch a double from a 4-byte aligned address. Experience
with liblo shows that other architectures are just fine (or at
On 21/11/14 13:21, Thorsten Glaser wrote:
On Fri, 21 Nov 2014, Simon McVittie wrote:
failing to start up on armel due to unaligned memory accesses. lzo2 has
a cpp macro, LZO_CFG_NO_UNALIGNED which can be defined to stop it doing
clever things with casting pointers.
Please define this macro
On Fri, 2014-11-21 at 18:01:11 +0100, Jakub Wilk wrote:
* Felipe Sateler fsate...@debian.org, 2014-11-21, 14:04:
Sparc is definitely not ok. For evidence, see #721617, liblo was trying to
fetch a double from a 4-byte aligned address. Experience with liblo shows
that other architectures are
On Fri, 21 Nov 2014, Sam Hartman wrote:
I thought there was a flag bit you could set on x86 that causes
unaligned access to trap there too.
1. CR0.AM must be set.
2. Ask For The Pain!
i386:
__asm__(pushf\norl $0x4,(%esp)\npopf);
x86-64:
__asm__(pushf\norl $0x4,(%rsp)\npopf);
On Fri, Nov 21, 2014 at 12:42:34PM +, Simon McVittie wrote:
A couple of questions for people who know low-level things:
* Of Debian's architectures (official and otherwise), which ones are
known/defined/designed to be OK with unaligned accesses from
user-space, and which ones (can be
❦ 21 novembre 2014 17:34 -0200, Henrique de Moraes Holschuh h...@debian.org :
I thought there was a flag bit you could set on x86 that causes
unaligned access to trap there too.
1. CR0.AM must be set.
2. Ask For The Pain!
i386:
__asm__(pushf\norl $0x4,(%esp)\npopf);
x86-64:
On Fri, 21 Nov 2014, Vincent Bernat wrote:
❦ 21 novembre 2014 17:34 -0200, Henrique de Moraes Holschuh
h...@debian.org :
I thought there was a flag bit you could set on x86 that causes
unaligned access to trap there too.
1. CR0.AM must be set.
2. Ask For The Pain!
i386:
34 matches
Mail list logo
