swordlea
版主
发贴: 652
积分: 0
来自: 论坛神游夜
注册日期: 2006-05-16
发表时间: 2006-09-30 00:46:16
--------------------------------------------------------------------------------
某些架构上访问数据时有对齐的要求,比如只能从4字节边界上读取一个4字节的
数据类型。IA-32架构没有硬性要求对齐,尽管未对齐的访问降低执行效率。另外
一些架构,比如SPARC、m68k,要求对齐访问,否则向当前进程分发SIGBUS信号。
SIGBUS与SIGSEGV信号一样,可以正常捕获。SIGBUS的缺省行为是终止当前进程并产
生core dump。
SIGBUS与SIGSEGV信号的一般区别如下:
1) SIGBUS(Bus error)意味着指针所对应的地址是有效地址,但总线不能正常使用该
指针。通常是未对齐的数据访问所致。
2) SIGSEGV(Segment fault)意味着指针所对应的地址是无效地址,没有物理内存对
应该地址。
参"2.4 如何编程获取栈底地址"中如何捕获SIGBUS与SIGSEGV信号,并利用sigsetjmp、
siglongjmp重获控制权。
测试表明,在x86/Linux、x86/Solaris、SPARC/Solaris平台上,越过栈底的地址访
问导致SIGSEGV信号。在x86/FreeBSD、x86/NetBSD、x86/OpenBSD平台上,越过栈底
的地址访问导致SIGBUS信号,而不是SIGSEGV信号。
下面举例解释一下,什么叫未对齐的数据访问。
--------------------------------------------------------------------------
/*
* Test: SPARC/Solaris 8 64-bit kernel mode
* gcc -Wall -pipe -g -o bus bus.c
*/
#include <stdio.h>
#include <stdlib.h>
int main ( int argc, char * argv[] )
{
unsigned int i = 0x12345678;
unsigned short int *q = NULL;
unsigned char *p = ( unsigned char * )&i;
*p = 0x00;
q = ( unsigned short int * )( p + 1 );
*q = 0x0000;
return( EXIT_SUCCESS );
} /* end of main */
--------------------------------------------------------------------------
$ ./bus
总线错误 (core dumped)
$ gdb ./bus core
GNU gdb 5.0
#0 0x1084c in main (argc=1, argv=0xffbefc54) at bus.c:16
16 *q = 0x0000;
(gdb) disas main
Dump of assembler code for function main:
0x10810 <main> : save %sp, -128, %sp
0x10814 <main+4> : st %i0, [ %fp + 0x44 ]
0x10818 <main+8> : st %i1, [ %fp + 0x48 ]
0x1081c <main+12>: sethi %hi(0x12345400), %o1
0x10820 <main+16>: or %o1, 0x278, %o0 ! 0x12345678
0x10824 <main+20>: st %o0, [ %fp + -20 ]
0x10828 <main+24>: clr [ %fp + -24 ]
0x1082c <main+28>: add %fp, -20, %o0
0x10830 <main+32>: st %o0, [ %fp + -28 ]
0x10834 <main+36>: ld [ %fp + -28 ], %o0
0x10838 <main+40>: clrb [ %o0 ]
0x1083c <main+44>: ld [ %fp + -28 ], %o0
0x10840 <main+48>: add %o0, 1, %o1
0x10844 <main+52>: st %o1, [ %fp + -24 ]
0x10848 <main+56>: ld [ %fp + -24 ], %o0
0x1084c <main+60>: clrh [ %o0 ]
0x10850 <main+64>: clr %i0
0x10854 <main+68>: b 0x1085c <main+76>
0x10858 <main+72>: nop
0x1085c <main+76>: ret
0x10860 <main+80>: restore
End of assembler dump.
(gdb) i r pc
pc 0x1084c 67660
(gdb) i r o0
o0 0xffbefbdd -4260899
(gdb) x/3bx 0xffbefbdd
0xffbefbdd: 0x34 0x56 0x78
(gdb)
从C语言来说,执行"*q = 0x0000;"时导致SIGBUS了。从汇编指令来说,执行"clrh [%o0]"
时导致SIGBUS了,寄存器%o0值为0xffbefbdd,这个地址未对齐在双字节边界上。
注意,gcc编译时并未指定-O<n>进行优化,但仍然使用clrh,而不是两次clrb。类似
的汇编指令有ldw、lduh等等。有人可能碰上读操作也导致SIGBUS,觉得不可理解,
其实读写导致SIGBUS没有本质区别,比如ldw只能读4字节边界上的地址。
bus.c是显式的未对齐。程序员实际最容易面对的是隐式未对齐,主要来自指针的强
制类型转换。下面举例说明这种情形。
--------------------------------------------------------------------------
/*
* Test: SPARC/Solaris 8 64-bit kernel mode
* gcc -Wall -pipe -g -o other_bus other_bus.c
*/
#include <stdio.h>
#include <stdlib.h>
int main ( int argc, char * argv[] )
{
unsigned int i = 0x12345678;
unsigned short int j = 0x0000;
j = *( ( unsigned short int * )( ( ( unsigned char * )&i ) + 1 ) );
return( EXIT_SUCCESS );
} /* end of main */
--------------------------------------------------------------------------
$ ./other_bus
总线错误 (core dumped)
$ gdb ./other_bus core
GNU gdb 5.0
#0 main (argc=1, argv=0xffbefc44) at other_bus.c:13
13 j = *( ( unsigned short int * )( ( ( unsigned char * )&i ) + 1 ) );
(gdb) disas main
Dump of assembler code for function main:
0x10810 <main> : save %sp, -120, %sp
0x10814 <main+4> : st %i0, [ %fp + 0x44 ]
0x10818 <main+8> : st %i1, [ %fp + 0x48 ]
0x1081c <main+12>: sethi %hi(0x12345400), %o1
0x10820 <main+16>: or %o1, 0x278, %o0 ! 0x12345678
0x10824 <main+20>: st %o0, [ %fp + -20 ]
0x10828 <main+24>: clrh [ %fp + -22 ]
0x1082c <main+28>: lduh [ %fp + -19 ], %o0
0x10830 <main+32>: sth %o0, [ %fp + -22 ]
0x10834 <main+36>: clr %i0
0x10838 <main+40>: b 0x10840 <main+48>
0x1083c <main+44>: nop
0x10840 <main+48>: ret
0x10844 <main+52>: restore
End of assembler dump.
(gdb) i r pc
pc 0x1082c 67628
(gdb)
因此在SPARC架构上编程,一定要留神强制类型转换,务必清楚自己正在干什么,有
没有隐患。
<---- 以上言论仅代表本人立场 ---->
__________________
- Is life always this hard,or it just when you're a kid?
- Always like this. |
|