I've developed a version of GCC with an altered version of libgomp, and I'm now trying to run test OpenMP programs compiled with this altered GCC. I've had no trouble so far with programs written in C. Now I'd like to try to build one of the NPB benchmarks written in Fortran 77—namely, EP. Although I can build an executable, I get a segmentation fault when I run it. I've traced this to the destroy_unit_mutex routine. Below is an objdump disassembly of that routine in my executable. As you can see, instruction 0x4090e5 has "callq 0"! So the question is why GCC has generated this code. (More below the quoted disassembly.)
00000000004090d0 <destroy_unit_mutex>:
4090d0: b8 b0 c7 42 00 mov $0x42c7b0,%eax
4090d5: 53 push %rbx
4090d6: 48 89 fb mov %rdi,%rbx
4090d9: 48 85 c0 test %rax,%rax
4090dc: 74 0c je 4090ea <destroy_unit_mutex+0x1a>
4090de: 48 8d bf d0 00 00 00 lea 0xd0(%rdi),%rdi
4090e5: e8 16 6f bf ff callq 0 <__libc_resp>
4090ea: 48 89 df mov %rbx,%rdi
4090ed: 5b pop %rbx
4090ee: e9 bd a1 ff ff jmpq 4032b0 <_gfortrani_free_mem>
The source for this routine is in gcc/libgfortran/io/unit.c:
static void
destroy_unit_mutex (gfc_unit * u)
{
__gthread_mutex_destroy (&u->lock);
free_mem (u);
}
I'm guessing that GCC linked the version of __gthread_mutex_destroy in gcc/gthr-posix.h:
static inline int
__gthread_mutex_destroy (__gthread_mutex_t *__mutex)
{
if (__gthread_active_p ())
return __gthrw_(pthread_mutex_destroy) (__mutex);
else
return 0;
}
So is the "callq 0" just the inlining of "return 0"? Is it supposed to reflect an error state by provoking a segmentation fault? Can anybody explain what is happening and perhaps what I might do about it? Thanks!
Amittai Aviram
PhD Student in Computer Science
Yale University
646 483 2639
amittai.aviram@xxxxxxxx
http://www.amittai.com
