This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On AMD64 the closure tests all fail with a segmentation fauilt. If you look e.g. at closure_fn0 you'll see that the trampoline is setup as: (gdb) disassemble &closure->tramp Dump of assembler code for function cl.0: 0x00000000005013c0 <cl.0+0>: mov $0x2a9566f78e,%r11 0x00000000005013ca <cl.0+10>: mov $0x5013c0,%r10 0x00000000005013d4 <cl.0+20>: jmpq *%r11 0x00000000005013d7 <cl.0+23>: add %dh,0x7fbfffef(%rax) 0x00000000005013dd <cl.0+29>: add %al,(%rax) 0x00000000005013df <cl.0+31>: add %al,(%rax) 0x00000000005013e1 <cl.0+33>: add %al,(%rax) 0x00000000005013e3 <cl.0+35>: add %al,(%rax) 0x00000000005013e5 <cl.0+37>: add %al,(%rax) 0x00000000005013e7 <cl.0+39>: add %al,(%rax) 0x00000000005013e9 <cl.0+41>: add %al,(%rax) 0x00000000005013eb <cl.0+43>: add %al,(%rax) 0x00000000005013ed <cl.0+45>: add %al,(%rax) 0x00000000005013ef <cl.0+47>: add %al,(%rax) End of assembler dump. So, this looks fine. But then we get a segmentation fault executing the trampoline: Breakpoint 5, 0x00000000005013c0 in cl.0 () (gdb) display /i $pc 1: x/i $pc 0x5013c0 <cl.0>: mov $0x2a9566f78e,%r11 (gdb) si Program received signal SIGSEGV, Segmentation fault. 0x00000000005013c0 in cl.0 () 1: x/i $pc 0x5013c0 <cl.0>: mov $0x2a9566f78e,%r11 (gdb) shell cat /proc/27491/maps 0000000000400000-0000000000401000 r-xp 0000000000000000 03:06 2758321 /builds/gcc/misc/x86_64-suse-linux-gnu/libffi/testsuite/closure_fn0.exe 0000000000501000-0000000000502000 rw-p 0000000000001000 03:06 2758321 /builds/gcc/misc/x86_64-suse-linux-gnu/libffi/testsuite/closure_fn0.exe 0000002a95556000-0000002a9556b000 r-xp 0000000000000000 03:02 279084 /lib64/ld-2.3.2.so 0000002a9556b000-0000002a9556d000 rw-p 0000000000000000 00:00 0 0000002a9566b000-0000002a9566d000 rw-p 0000000000015000 03:02 279084 /lib64/ld-2.3.2.so 0000002a9566d000-0000002a95670000 r-xp 0000000000000000 03:06 2611261 /builds/gcc/misc/x86_64-suse-linux-gnu/libffi/.libs/libffi-2.00-beta.so 0000002a95670000-0000002a9576d000 ---p 0000000000003000 03:06 2611261 /builds/gcc/misc/x86_64-suse-linux-gnu/libffi/.libs/libffi-2.00-beta.so 0000002a9576d000-0000002a95771000 rw-p 0000000000000000 03:06 2611261 /builds/gcc/misc/x86_64-suse-linux-gnu/libffi/.libs/libffi-2.00-beta.so 0000002a95771000-0000002a957c7000 r-xp 0000000000000000 03:02 279093 /lib64/libm.so.6 0000002a957c7000-0000002a95871000 ---p 0000000000056000 03:02 279093 /lib64/libm.so.6 0000002a95871000-0000002a958cb000 rw-p 0000000000000000 03:02 279093 /lib64/libm.so.6 0000002a958cb000-0000002a959ef000 r-xp 0000000000000000 03:02 279089 /lib64/libc.so.6 0000002a959ef000-0000002a95acb000 ---p 0000000000124000 03:02 279089 /lib64/libc.so.6 0000002a95acb000-0000002a95b09000 rw-p 0000000000100000 03:02 279089 /lib64/libc.so.6 0000002a95b09000-0000002a95b0d000 rw-p 0000000000000000 00:00 0 The problem is that the trampoline is non-executable, the variables are declared as static! If I change the put cl on the stack instead of static memory (removing the static keyword in line 48 of closure_fn0.c), the test is successfull and returns the desired argument: $ LD_LIBRARY_PATH=../.libs/ ./closure_fn0.exe 1 2 3 4 127 429 7 8 9 10 11 12 13 19 21 1 3: 680 res: 680 My question now is is that test is really correct to allocate the memory in static memory - and if it is correct, then how can this be fixed? Do other platforms have the same problem - and if not, what's different? Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Attachment:
pgp00000.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |