AMD64 version of GNAT Ada compiler broken due to libthr

[John Marino]

Hi Kostik,
You're right, that was an oversight.  I'm using release 8.1, but I tried 
troubleshooting this months ago on 8.0 and the result was identical.

I'm well above my head here.  I don't know what I should be looking for. 
   Here's the dissembled _umtx_op_err function, along with the 
backtraces of the other two threads.  They didn't look that interesting 
to me the first time.

-- john



Starting program: /usr/home/marino/test_gnat/test_c9a009c/c9a009c
[New LWP 100086]
[New Thread 800a041c0 (LWP 100086)]
[New Thread 800a0ae40 (LWP 100051)]
[New Thread 800a64c80 (LWP 100073)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 800a64c80 (LWP 100073)]
0x00007fffffbfeb19 in ?? ()
Cannot set lwp 100073 registers: Invalid argument

An error occurred while in a function called from GDB.
Evaluation of the expression containing the function
(_umtx_op_err) will be abandoned.
When the function is done executing, GDB will silently stop.
Dump of assembler code for function _umtx_op_err:
    0x00000008006923c0 <+0>:	mov    $0x1c6,%rax
    0x00000008006923c7 <+7>:	mov    %rcx,%r10
    0x00000008006923ca <+10>:	syscall
    0x00000008006923cc <+12>:	retq
    0x00000008006923cd <+13>:	nop
    0x00000008006923ce <+14>:	nop
    0x00000008006923cf <+15>:	nop
    0x00000008006923d0 <+16>:	mov    0x102d09(%rip),%rax        # 
0x8007950e0
    0x00000008006923d7 <+23>:	push   %rbx
    0x00000008006923d8 <+24>:	cmp    $0xffffffffffffffff,%rax
    0x00000008006923dc <+28>:	je     0x8006923f5 <_umtx_op_err+53>
    0x00000008006923de <+30>:	lea    0x102cfb(%rip),%rbx        # 
0x8007950e0
    0x00000008006923e5 <+37>:	callq  *%rax
    0x00000008006923e7 <+39>:	mov    -0x8(%rbx),%rax
    0x00000008006923eb <+43>:	sub    $0x8,%rbx
    0x00000008006923ef <+47>:	cmp    $0xffffffffffffffff,%rax
    0x00000008006923f3 <+51>:	jne    0x8006923e5 <_umtx_op_err+37>
    0x00000008006923f5 <+53>:	pop    %rbx
    0x00000008006923f6 <+54>:	retq
    0x00000008006923f7 <+55>:	nop
End of assembler dump.
[Switching to thread 2 (Thread 800a041c0 (LWP 100086))]#0 
0x00000008006923cc in _umtx_op_err () at 
/usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
37	RSYSCALL_ERR(_umtx_op)
#0  0x00000008006923cc in _umtx_op_err ()
     at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
#1  0x00000008006904c5 in cond_wait_common (cond=<value optimized out>,
     mutex=0x800a0bb50, abstime=0x0, cancel=1)
     at /usr/src/lib/libthr/thread/thr_cond.c:204
#2  0x000000000040bfeb in 
system.tasking.stages.vulnerable_complete_master ()
     at s-tassta.adb:1696
#3  0x000000000040620a in c9a009c () at c9a009c.adb:44
[Switching to thread 4 (Thread 800a64c80 (LWP 100073))]#0 
0x00007fffffbfeb19 in ?? ()
#0  0x00007fffffbfeb19 in ?? ()
#1  0x000000000040d655 in system.tasking.stages.task_wrapper (
     self_id=0x800a52500) at s-tassta.adb:1207
#2  0x0000000800688621 in thread_start (curthread=0x800a64c80)
     at /usr/src/lib/libthr/thread/thr_create.c:288
#3  0x0000000000000000 in ?? ()




Kostik Belousov wrote:
> On Fri, Dec 31, 2010 at 12:46:33PM +0100, John Marino wrote:
>> For several months I have been getting the GNAT Ada compiler to work 
>> properly on the four major BSDs.  The i386 FreeBSD, the i386 Dragonfly 
>> BSD, and the x86_64 Dragonfly BSD ports are currently perfect.  The i386 
>> and x86_64 ports of NetBSD are nearly perfect, and only lack a 
>> functional DWARF2 unwind mechanism, and the OpenBSD ports are in pretty 
>> good shape too.  The progress for this work can be seen at 
>> http://www.dragonlace.net
>>
>> However the AMD64 FreeBSD version is unusable and it's due to libthr.  
>> I'm not sure why the i386 version works with libthr and AMD64 version 
>> doesn't.  For all four BSDs, there is no configuration difference for 
>> threading between architectures.
>>
>> The problem seems to be with the pthread_cond_wait functionality.
>>
>> I've logged a test case segfault via gdb7.1 below.  I would greatly 
>> appreciate some help in determining where the problem lies.  If this 
>> problem can be solved, it will likely result in a perfect port of the 
>> GNAT Ada compiler for FreeBSD AMD64, something that has not existed before.
>>
> First, you did not specified which version of the base system you use.
> 
> Second, I suspect that the backtrace you have shown is not from the
> thread that generated SIGSEGV. Switch to other threads and see their
> backtraces, I am almost sure that there will be something more interesting.
> 
> Just to be sure, in gdb, disassemble _umtx_op_err() and see which
> instruction is executed when SIGSEGV generated. I think that the thread
> with the backtrace below is sleeping in syscall.
> 
>> Regards,
>> John
>>