Re: Architectures with strict alignment?

On Sat, Dec 29, 2007 at 01:12:04PM +0200, Kostik Belousov wrote:
On Sat, Dec 29, 2007 at 12:14:11AM -0800, Kip Macy wrote:
Isn't it everything except x86?

-Kip
x86 has the AC bit in the eflags. The AM bit in cr0 is enabled by the
kernel, and AC could be switched on by LD_PRELOADed shared object.

Last time I checked, our libc caused unaligned access in the locale
initialization code.

Out of curiosity, I wrote the following simple LD_PRELOADable shared object.

/* $Id: align.c,v 1.2 2007/12/30 13:06:32 kostik Exp $ */

#define AC "(1 << 18)"

static void
enable_AC()
{
__asm volatile("pushfl\n\t"
"orl\t$" AC ", (%%esp)\n\t"
"popfl\n" : : : "cc");
}

static void
disable_AC(void)
{
__asm volatile("pushfl\n\t"
"andl\t$~" AC ", (%%esp)\n\t"
"popfl\n" : : : "cc");
}

static void set_AC(void) __attribute__ ((constructor));
void set_AC(void)
{
enable_AC();
}

cc -O2 -shared -o align.so align.c

Doing
LD_PRELOAD=./align.so /bin/ls
results in the
[1] 12032 bus error (core dumped) LD_PRELOAD=./align.so /bin/ls

gdb session:
Program terminated with signal 10, Bus error.
#0 0x2816ee8d in __collate_load_tables (encoding=0x281c1280 "ru_RU.KOI8-R")
at /usr/home/kostik/work/MY/align/src/lib/libc/locale/collate.c:87
87 (void)strcat(buf, "/");
(gdb) disassemble 0x2816ee8d 0x2816ee8d+10
Dump of assembler code from 0x2816ee8d to 0x2816ee97:
0x2816ee8d <__collate_load_tables+205>: movw $0x2f,-0x1(%esi,%ecx,1)
0x2816ee94 <__collate_load_tables+212>: mov 0x8(%ebp),%eax

(half-word)0x2f == asciz '/'

I.e., it seems that gcc does not feel too guilty generating unaligned
half-word writes on i386. :(

Attachment: pgpbPxhOv4y6J.pgp
Description: PGP signature