x86: cómo detectar fallas de alineación de datos (también conocido como SIGBUS en sparc)

Question

¿Es de alguna manera posible detectar fallas de alineación de datos incluso en i386? Tal vez estableciendo un registro de máquina específica para i386 o algo así.

En Solaris-Sparc Estoy recibiendo un SIGBUS en este caso, pero en i386 todo está bien.

Medio Ambiente:

• 32-bit de aplicación
• Ubuntu Karmic
• gcc/g ++ v4.4.1

EDITAR: Aquí es por eso que estoy pidiendo esto:

• nuestra aplicación se bloquea en Sol-Sparc con SIGBUS. A los efectos de la depuración, trataría de obtener un comportamiento similar en nuestra plataforma i386.
• nuestra máquina Sol-sparc es muy lenta, por lo que la compilación y la depuración llevan mucho tiempo allí. Y nuestra máquina i386 es increíblemente rápida (8 núcleos, 32G de memoria).
• Incluso en las plataformas i386 hay un costo de rendimiento en las fallas de alineación de datos. Y, por lo tanto, me gustaría corregir las fallas de alineación de datos siempre que sea posible.

Answer 1

Para ampliar la respuesta de Vokuhila-Oliba mirando el hilo "SOF Mis-aligned pointers on x86.", parece que gcc puede generar código con acceso a memoria mal alineado. AFAIK no tienes ningún control sobre esto.

Habilitar las comprobaciones de alineación en el código compilado de gcc sería una mala idea. Se arriesga a obtener errores de SIGBUS para el código bueno C.

reeditado: Lo siento

Answer 2

Intel incorporó transferencias desalineadas desde el principio: era uno de los puntos de venta cuando x86 era completamente nuevo. Entiendo tus razones para querer atrapar el acceso no alineado, pero no creo que sea posible.

Edit: muy contento de haber demostrado estar equivocado.

Answer 3

Mientras tanto, encontré un documento de la CPU Intel que aborda este tema.

Ver Intel® 64 and IA-32 Architectures Software Developer’s Manual.

Parece ser difícil juntar todas estas cosas. Sin embargo, no parece que sea completamente imposible. El capítulo interesante es 4.10.5 Comprobación de la alineación

EDITAR (un poco de material condensado del citado documento):

página 5-60

Interrupt 17 Alignment Check Exception (#AC) 

to enable alignment checking, the following conditions must be true: 

AM flag is set(bit 18 of control regisster CR0) 
AC flag is set (bit 18 of the EFLAGS) 
The CPL is 3 (protected mode or virtual-8086 mode). 

adicionalmente - en 14.8.2.6 - Se mencionan los errores del controlador de memoria. No sé si es lo mismo solo en otras palabras:

table 14-11, Encoding of MMM and CCCC Sub-Fields 
Address/Command Error AC 011 

Answer 4

¡He encontrado una solución muy simple en SOF! Ver: Mis-aligned pointers on x86.

int main(int argc, char **argv) 
{ 
# if defined i386 
    /* EDIT: enable AC check */ 
    asm("pushf; " 
    "orl $(1<<18), (%esp); " 
    "popf;"); 
# endif 

    char d[] = "12345678"; /* yep! - causes SIGBUS even on Linux-i386 */ 
    return 0; 
} 

Pero debo confesar que no entiendo por qué la asignación

carbón d [] = "12345678";

se supone que está mal alineada?

EDIT:

en la máquina SPARC no hay SIGBUS en la línea de la asignación a Char d [].

Answer 5

Intel son muy grandes en el apoyo a las cargas no alineados. Si tuviera que detectar tales cargas en una plataforma Intel, creo que tendría que modificar valgrind para tratar las cargas desalineadas como errores. Tal modificación no es trivial, pero valgrind se diseñó con la idea en mente de que los usuarios podían crear nuevas 'herramientas'. Creo que una simple modificación de la herramienta memcheck detectaría sus referencias desalineadas. Y el informe de errores es realmente muy bueno.

Answer 6

Muchos años después: si tu gcc/clang es lo suficientemente nuevo (GCC 4.9, clang 3.3?), Puedes construir tu código con el desinfectante de comportamiento indefinido (-fsanitize=undefined) para recibir advertencias sobre accesos desalineados en una plataforma determinada (pero tenga en cuenta que las diferentes plataformas tienen diferentes requisitos de alineación, diferentes compiladores elegirán diferentes diseños, etc.). Vea https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html y https://developers.redhat.com/blog/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/ para más detalles.