Question about libffi closure

[Andreas Jaeger <aj at suse dot de>]

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