From owner-freebsd-threads@FreeBSD.ORG Mon Dec 27 11:07:09 2010 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 621E310656C1 for ; Mon, 27 Dec 2010 11:07:09 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 35CC08FC1C for ; Mon, 27 Dec 2010 11:07:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oBRB79aQ055898 for ; Mon, 27 Dec 2010 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oBRB781E055896 for freebsd-threads@FreeBSD.org; Mon, 27 Dec 2010 11:07:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Dec 2010 11:07:08 GMT Message-Id: <201012271107.oBRB781E055896@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2010 11:07:09 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/150959 threads [libc] Stub pthread_once in libc should call _libc_onc o threa/149366 threads pthread_cleanup_pop never runs the configured routine o threa/148515 threads Memory / syslog strangeness in FreeBSD 8.x ( possible o threa/141721 threads rtprio(1): (id|rt)prio priority resets when new thread o threa/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 o threa/133734 threads 32 bit libthr failing pthread_create() o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. f threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r s threa/69020 threads pthreads library leaks _gc_mutex s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/34536 threads accept() blocks other threads s threa/30464 threads pthread mutex attributes -- pshared 29 problems total. From owner-freebsd-threads@FreeBSD.ORG Fri Dec 31 12:02:47 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E2A11065693 for ; Fri, 31 Dec 2010 12:02:47 +0000 (UTC) (envelope-from freebsdml@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) by mx1.freebsd.org (Postfix) with ESMTP id 3A5E68FC17 for ; Fri, 31 Dec 2010 12:02:47 +0000 (UTC) Received: from [192.168.1.33] (78.red-79-158-163.staticip.rima-tde.net [79.158.163.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 06A9A438EC for ; Fri, 31 Dec 2010 05:46:35 -0600 (CST) Message-ID: <4D1DC299.2090808@marino.st> Date: Fri, 31 Dec 2010 12:46:33 +0100 From: John Marino User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: AMD64 version of GNAT Ada compiler broken due to libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 12:02:47 -0000 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. Regards, John Starting program: /usr/home/marino/test_gnat/test_c9a009c/c9a009c [New LWP 100051] [New Thread 800a041c0 (LWP 100051)] [New Thread 800a0ae40 (LWP 100073)] [New Thread 800a64c80 (LWP 100080)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 800a64c80 (LWP 100080)] 0x00007fffffbfeb19 in ?? () * 4 Thread 800a64c80 (LWP 100080) 0x00007fffffbfeb19 in ?? () 3 Thread 800a0ae40 (LWP 100073) 0x00000008006923cc in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 2 Thread 800a041c0 (LWP 100051) 0x00000008006923cc in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 [Switching to thread 3 (Thread 800a0ae40 (LWP 100073))]#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=, mutex=0x800a0c850, abstime=0x0, cancel=1) at /usr/src/lib/libthr/thread/thr_cond.c:204 #2 0x000000000040ca0f in system.tasking.stages.activate_tasks ( chain_access=0x7fffffbfebb0) at s-tassta.adb:382 #3 0x0000000000405950 in c9a009c.t1 (<_task>=) at c9a009c.adb:52 #4 0x000000000040d655 in system.tasking.stages.task_wrapper ( self_id=0x800a0c700) at s-tassta.adb:1207 #5 0x0000000800688621 in thread_start (curthread=0x800a0ae40) at /usr/src/lib/libthr/thread/thr_create.c:288 #6 0x0000000000000000 in ?? () From owner-freebsd-threads@FreeBSD.ORG Fri Dec 31 12:35:18 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B39B106566C for ; Fri, 31 Dec 2010 12:35:18 +0000 (UTC) (envelope-from freebsdml@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) by mx1.freebsd.org (Postfix) with ESMTP id 24A2E8FC13 for ; Fri, 31 Dec 2010 12:35:18 +0000 (UTC) Received: from [192.168.1.33] (78.red-79-158-163.staticip.rima-tde.net [79.158.163.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 795C2438BE; Fri, 31 Dec 2010 06:35:16 -0600 (CST) Message-ID: <4D1DCE02.3050601@marino.st> Date: Fri, 31 Dec 2010 13:35:14 +0100 From: John Marino User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Kostik Belousov References: <4D1DC299.2090808@marino.st> <20101231122225.GK90883@deviant.kiev.zoral.com.ua> In-Reply-To: <20101231122225.GK90883@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org Subject: Re: AMD64 version of GNAT Ada compiler broken due to libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 12:35:18 -0000 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=, 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 >> From owner-freebsd-threads@FreeBSD.ORG Fri Dec 31 12:44:24 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11EF31065670 for ; Fri, 31 Dec 2010 12:44:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A207F8FC08 for ; Fri, 31 Dec 2010 12:44:23 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oBVCMQKW013010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Dec 2010 14:22:26 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oBVCMP5g099723; Fri, 31 Dec 2010 14:22:25 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oBVCMP8c099719; Fri, 31 Dec 2010 14:22:25 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 31 Dec 2010 14:22:25 +0200 From: Kostik Belousov To: John Marino Message-ID: <20101231122225.GK90883@deviant.kiev.zoral.com.ua> References: <4D1DC299.2090808@marino.st> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5nbaS3kz4OSBzmjj" Content-Disposition: inline In-Reply-To: <4D1DC299.2090808@marino.st> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-threads@freebsd.org Subject: Re: AMD64 version of GNAT Ada compiler broken due to libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 12:44:24 -0000 --5nbaS3kz4OSBzmjj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=20 > properly on the four major BSDs. The i386 FreeBSD, the i386 Dragonfly=20 > BSD, and the x86_64 Dragonfly BSD ports are currently perfect. The i386= =20 > and x86_64 ports of NetBSD are nearly perfect, and only lack a=20 > functional DWARF2 unwind mechanism, and the OpenBSD ports are in pretty= =20 > good shape too. The progress for this work can be seen at=20 > http://www.dragonlace.net >=20 > However the AMD64 FreeBSD version is unusable and it's due to libthr. =20 > I'm not sure why the i386 version works with libthr and AMD64 version=20 > doesn't. For all four BSDs, there is no configuration difference for=20 > threading between architectures. >=20 > The problem seems to be with the pthread_cond_wait functionality. >=20 > I've logged a test case segfault via gdb7.1 below. I would greatly=20 > appreciate some help in determining where the problem lies. If this=20 > problem can be solved, it will likely result in a perfect port of the=20 > GNAT Ada compiler for FreeBSD AMD64, something that has not existed befor= e. >=20 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 >=20 >=20 >=20 > Starting program: /usr/home/marino/test_gnat/test_c9a009c/c9a009c > [New LWP 100051] > [New Thread 800a041c0 (LWP 100051)] > [New Thread 800a0ae40 (LWP 100073)] > [New Thread 800a64c80 (LWP 100080)] >=20 > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 800a64c80 (LWP 100080)] > 0x00007fffffbfeb19 in ?? () > * 4 Thread 800a64c80 (LWP 100080) 0x00007fffffbfeb19 in ?? () > 3 Thread 800a0ae40 (LWP 100073) 0x00000008006923cc in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 2 Thread 800a041c0 (LWP 100051) 0x00000008006923cc in _umtx_op_err () > at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > [Switching to thread 3 (Thread 800a0ae40 (LWP 100073))]#0 =20 > 0x00000008006923cc in _umtx_op_err () at=20 > /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=3D, > mutex=3D0x800a0c850, abstime=3D0x0, cancel=3D1) > at /usr/src/lib/libthr/thread/thr_cond.c:204 > #2 0x000000000040ca0f in system.tasking.stages.activate_tasks ( > chain_access=3D0x7fffffbfebb0) at s-tassta.adb:382 > #3 0x0000000000405950 in c9a009c.t1 (<_task>=3D) > at c9a009c.adb:52 > #4 0x000000000040d655 in system.tasking.stages.task_wrapper ( > self_id=3D0x800a0c700) at s-tassta.adb:1207 > #5 0x0000000800688621 in thread_start (curthread=3D0x800a0ae40) > at /usr/src/lib/libthr/thread/thr_create.c:288 > #6 0x0000000000000000 in ?? () >=20 > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" --5nbaS3kz4OSBzmjj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0dywEACgkQC3+MBN1Mb4jgiACgzoYleA1zTSTDb+eI9lMBUIvh unMAoMLsA3f0gEJj96lql/hRexoajSCm =Fx6b -----END PGP SIGNATURE----- --5nbaS3kz4OSBzmjj-- From owner-freebsd-threads@FreeBSD.ORG Fri Dec 31 12:52:20 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2E5A106564A for ; Fri, 31 Dec 2010 12:52:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1C6248FC1C for ; Fri, 31 Dec 2010 12:52:19 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oBVCqF6P014569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Dec 2010 14:52:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oBVCqFhq027357; Fri, 31 Dec 2010 14:52:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oBVCqFOC027352; Fri, 31 Dec 2010 14:52:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 31 Dec 2010 14:52:15 +0200 From: Kostik Belousov To: John Marino Message-ID: <20101231125215.GL90883@deviant.kiev.zoral.com.ua> References: <4D1DC299.2090808@marino.st> <20101231122225.GK90883@deviant.kiev.zoral.com.ua> <4D1DCE02.3050601@marino.st> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXqTiZo38oDXuAlq" Content-Disposition: inline In-Reply-To: <4D1DCE02.3050601@marino.st> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_05, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-threads@freebsd.org Subject: Re: AMD64 version of GNAT Ada compiler broken due to libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 12:52:21 -0000 --OXqTiZo38oDXuAlq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 31, 2010 at 01:35:14PM +0100, John Marino wrote: > Hi Kostik, > You're right, that was an oversight. I'm using release 8.1, but I tried= =20 > troubleshooting this months ago on 8.0 and the result was identical. >=20 > I'm well above my head here. I don't know what I should be looking for.= =20 > Here's the dissembled _umtx_op_err function, along with the=20 > backtraces of the other two threads. They didn't look that interesting= =20 > to me the first time. The instruction counter is right before syscall, so I do think that the thread was executing the syscall. Backtrace for LWP 100073 indeed looks interesting, because the address 0x00007fffffbfeb19 belongs to the area used for stack(s), including the thread stacks. FreeBSD amd64 currently provides non-executable stacks for non-main threads, but executable stack for main thread. i386 has no support for nx bit on non-PAE kernels. As a useful experiment, go to src/lib/libthr/thread/thr_stack.c, find the following fragment if ((stackaddr =3D mmap(stackaddr, stacksize+guardsize, PROT_READ | PROT_WRITE, MAP_STACK, -1, 0)) !=3D MAP_FAILED && and change the flags from PROT_READ | PROT_WRITE to PROT_READ | PROT_WRITE | PROT_EXEC. Then recompile and reinstall libthr, and report back what happens with your test. >=20 > -- john >=20 >=20 >=20 > 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)] >=20 > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 800a64c80 (LWP 100073)] > 0x00007fffffbfeb19 in ?? () > Cannot set lwp 100073 registers: Invalid argument >=20 > 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 #=20 > 0x8007950e0 > 0x00000008006923d7 <+23>: push %rbx > 0x00000008006923d8 <+24>: cmp $0xffffffffffffffff,%rax > 0x00000008006923dc <+28>: je 0x8006923f5 <_umtx_op_err+53> > 0x00000008006923de <+30>: lea 0x102cfb(%rip),%rbx #=20 > 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=20 > 0x00000008006923cc in _umtx_op_err () at=20 > /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=3D, > mutex=3D0x800a0bb50, abstime=3D0x0, cancel=3D1) > at /usr/src/lib/libthr/thread/thr_cond.c:204 > #2 0x000000000040bfeb in=20 > 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=20 > 0x00007fffffbfeb19 in ?? () > #0 0x00007fffffbfeb19 in ?? () > #1 0x000000000040d655 in system.tasking.stages.task_wrapper ( > self_id=3D0x800a52500) at s-tassta.adb:1207 > #2 0x0000000800688621 in thread_start (curthread=3D0x800a64c80) > at /usr/src/lib/libthr/thread/thr_create.c:288 > #3 0x0000000000000000 in ?? () >=20 >=20 >=20 >=20 > 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=20 > >>properly on the four major BSDs. The i386 FreeBSD, the i386 Dragonfly= =20 > >>BSD, and the x86_64 Dragonfly BSD ports are currently perfect. The i38= 6=20 > >>and x86_64 ports of NetBSD are nearly perfect, and only lack a=20 > >>functional DWARF2 unwind mechanism, and the OpenBSD ports are in pretty= =20 > >>good shape too. The progress for this work can be seen at=20 > >>http://www.dragonlace.net > >> > >>However the AMD64 FreeBSD version is unusable and it's due to libthr. = =20 > >>I'm not sure why the i386 version works with libthr and AMD64 version= =20 > >>doesn't. For all four BSDs, there is no configuration difference for= =20 > >>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=20 > >>appreciate some help in determining where the problem lies. If this=20 > >>problem can be solved, it will likely result in a perfect port of the= =20 > >>GNAT Ada compiler for FreeBSD AMD64, something that has not existed=20 > >>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 interesti= ng. > > > >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 > >> --OXqTiZo38oDXuAlq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0d0f4ACgkQC3+MBN1Mb4hwqwCZAeMDG+MqPZzGjwHM0+8vKh88 6foAoPdcAgfqt+h46vo/EAF7zcjwMVlg =61kq -----END PGP SIGNATURE----- --OXqTiZo38oDXuAlq-- From owner-freebsd-threads@FreeBSD.ORG Fri Dec 31 13:08:56 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3FDE1065670 for ; Fri, 31 Dec 2010 13:08:56 +0000 (UTC) (envelope-from freebsdml@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) by mx1.freebsd.org (Postfix) with ESMTP id 8C9628FC14 for ; Fri, 31 Dec 2010 13:08:56 +0000 (UTC) Received: from [192.168.1.33] (78.red-79-158-163.staticip.rima-tde.net [79.158.163.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id DA6A3438BE; Fri, 31 Dec 2010 07:08:44 -0600 (CST) Message-ID: <4D1DD5CF.5020305@marino.st> Date: Fri, 31 Dec 2010 14:08:31 +0100 From: John Marino User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Kostik Belousov References: <4D1DC299.2090808@marino.st> <20101231122225.GK90883@deviant.kiev.zoral.com.ua> <4D1DCE02.3050601@marino.st> <20101231125215.GL90883@deviant.kiev.zoral.com.ua> In-Reply-To: <20101231125215.GL90883@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org Subject: Re: AMD64 version of GNAT Ada compiler broken due to libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 13:08:56 -0000 Hi Kostik, The result is the test passes. A small gdb log follows to prove it. So what does this mean? -- John Starting program: /usr/home/marino/test_gnat/test_c9a009c/c9a009c [New LWP 100064] [New Thread 800a041c0 (LWP 100064)] [New Thread 800a0ae40 (LWP 100051)] [New Thread 800a64c80 (LWP 100073)] [New Thread 800aa1ac0 (LWP 100090)] [Thread 800aa1ac0 (LWP 100090) exited] Invalid selected thread. [Switching to thread 2 (Thread 800a041c0 (LWP 100064))]#0 0x00000008006923cc in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 37 RSYSCALL_ERR(_umtx_op) Continuing. [Thread 800a64c80 (LWP 100073) exited] Invalid selected thread. [Switching to thread 2 (Thread 800a041c0 (LWP 100064))]#0 0x00000008006923cc in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 37 RSYSCALL_ERR(_umtx_op) Continuing. [Thread 800a0ae40 (LWP 100051) exited] Invalid selected thread. [Switching to thread 2 (Thread 800a041c0 (LWP 100064))]#0 0x00000008006923cc in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 37 RSYSCALL_ERR(_umtx_op) Continuing. Program exited normally. Kostik Belousov wrote: > On Fri, Dec 31, 2010 at 01:35:14PM +0100, John Marino wrote: >> 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. > The instruction counter is right before syscall, so I do think that the > thread was executing the syscall. > > Backtrace for LWP 100073 indeed looks interesting, because the address > 0x00007fffffbfeb19 belongs to the area used for stack(s), including > the thread stacks. > > FreeBSD amd64 currently provides non-executable stacks for non-main > threads, but executable stack for main thread. i386 has no support for > nx bit on non-PAE kernels. > > As a useful experiment, go to src/lib/libthr/thread/thr_stack.c, find > the following fragment > > if ((stackaddr = mmap(stackaddr, stacksize+guardsize, > PROT_READ | PROT_WRITE, MAP_STACK, > -1, 0)) != MAP_FAILED && > > and change the flags from PROT_READ | PROT_WRITE to > PROT_READ | PROT_WRITE | PROT_EXEC. Then recompile and reinstall libthr, > and report back what happens with your test. > From owner-freebsd-threads@FreeBSD.ORG Fri Dec 31 13:27:11 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A9AF106566C for ; Fri, 31 Dec 2010 13:27:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D0D8F8FC0A for ; Fri, 31 Dec 2010 13:27:10 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oBVDR6hP016684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Dec 2010 15:27:06 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oBVDR603017213; Fri, 31 Dec 2010 15:27:06 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oBVDR6GF017212; Fri, 31 Dec 2010 15:27:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 31 Dec 2010 15:27:06 +0200 From: Kostik Belousov To: John Marino Message-ID: <20101231132706.GN90883@deviant.kiev.zoral.com.ua> References: <4D1DC299.2090808@marino.st> <20101231122225.GK90883@deviant.kiev.zoral.com.ua> <4D1DCE02.3050601@marino.st> <20101231125215.GL90883@deviant.kiev.zoral.com.ua> <4D1DD5CF.5020305@marino.st> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i+iWqY68NNxfGGlH" Content-Disposition: inline In-Reply-To: <4D1DD5CF.5020305@marino.st> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-threads@freebsd.org Subject: Re: AMD64 version of GNAT Ada compiler broken due to libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 13:27:11 -0000 --i+iWqY68NNxfGGlH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 31, 2010 at 02:08:31PM +0100, John Marino wrote: > Hi Kostik, > The result is the test passes. A small gdb log follows to prove it. > So what does this mean? This means that the Ada complier or tasking library uses on-stack trampolines for something. Since FreeBSD threads on amd64 get non-executable stacks, the tasking fails. The proper solution is to provide a support for conditional non-executable stacks, as described in http://lists.freebsd.org/pipermail/freebsd-arch/2010-November/010826.html The latest WIP patch is http://people.freebsd.org/~kib/misc/nxstacks.3.patch I hope to get something in the tree not too long. >=20 > -- John >=20 >=20 > Starting program: /usr/home/marino/test_gnat/test_c9a009c/c9a009c > [New LWP 100064] > [New Thread 800a041c0 (LWP 100064)] > [New Thread 800a0ae40 (LWP 100051)] > [New Thread 800a64c80 (LWP 100073)] > [New Thread 800aa1ac0 (LWP 100090)] > [Thread 800aa1ac0 (LWP 100090) exited] > Invalid selected thread. > [Switching to thread 2 (Thread 800a041c0 (LWP 100064))]#0=20 > 0x00000008006923cc in _umtx_op_err () at=20 > /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 37 RSYSCALL_ERR(_umtx_op) > Continuing. > [Thread 800a64c80 (LWP 100073) exited] > Invalid selected thread. > [Switching to thread 2 (Thread 800a041c0 (LWP 100064))]#0=20 > 0x00000008006923cc in _umtx_op_err () at=20 > /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 37 RSYSCALL_ERR(_umtx_op) > Continuing. > [Thread 800a0ae40 (LWP 100051) exited] > Invalid selected thread. > [Switching to thread 2 (Thread 800a041c0 (LWP 100064))]#0=20 > 0x00000008006923cc in _umtx_op_err () at=20 > /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 > 37 RSYSCALL_ERR(_umtx_op) > Continuing. >=20 > Program exited normally. >=20 >=20 >=20 >=20 > Kostik Belousov wrote: > >On Fri, Dec 31, 2010 at 01:35:14PM +0100, John Marino wrote: > >>Hi Kostik, > >>You're right, that was an oversight. I'm using release 8.1, but I trie= d=20 > >>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= .=20 > >> Here's the dissembled _umtx_op_err function, along with the=20 > >>backtraces of the other two threads. They didn't look that interesting= =20 > >>to me the first time. > >The instruction counter is right before syscall, so I do think that the > >thread was executing the syscall. > > > >Backtrace for LWP 100073 indeed looks interesting, because the address > >0x00007fffffbfeb19 belongs to the area used for stack(s), including > >the thread stacks. > > > >FreeBSD amd64 currently provides non-executable stacks for non-main > >threads, but executable stack for main thread. i386 has no support for > >nx bit on non-PAE kernels. > > > >As a useful experiment, go to src/lib/libthr/thread/thr_stack.c, find > >the following fragment > > > > if ((stackaddr =3D mmap(stackaddr, stacksize+guardsize, > > PROT_READ | PROT_WRITE, MAP_STACK, > > -1, 0)) !=3D MAP_FAILED && > > > >and change the flags from PROT_READ | PROT_WRITE to > >PROT_READ | PROT_WRITE | PROT_EXEC. Then recompile and reinstall libthr, > >and report back what happens with your test. > > --i+iWqY68NNxfGGlH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0d2ioACgkQC3+MBN1Mb4gIzACdEJPYCtqMvUMqCBbGttvGSncT GaMAoKf08M+KJWuDFlB5waeG2J4CcSZe =Dj0O -----END PGP SIGNATURE----- --i+iWqY68NNxfGGlH-- From owner-freebsd-threads@FreeBSD.ORG Fri Dec 31 13:37:33 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E8F4106564A for ; Fri, 31 Dec 2010 13:37:33 +0000 (UTC) (envelope-from freebsdml@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) by mx1.freebsd.org (Postfix) with ESMTP id 55D588FC0A for ; Fri, 31 Dec 2010 13:37:33 +0000 (UTC) Received: from [192.168.1.33] (78.red-79-158-163.staticip.rima-tde.net [79.158.163.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id BA43A438BE; Fri, 31 Dec 2010 07:37:31 -0600 (CST) Message-ID: <4D1DDC99.7000400@marino.st> Date: Fri, 31 Dec 2010 14:37:29 +0100 From: John Marino User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Kostik Belousov References: <4D1DC299.2090808@marino.st> <20101231122225.GK90883@deviant.kiev.zoral.com.ua> <4D1DCE02.3050601@marino.st> <20101231125215.GL90883@deviant.kiev.zoral.com.ua> <4D1DD5CF.5020305@marino.st> <20101231132706.GN90883@deviant.kiev.zoral.com.ua> In-Reply-To: <20101231132706.GN90883@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org Subject: Re: AMD64 version of GNAT Ada compiler broken due to libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 13:37:33 -0000 Yeah, that's kind of what I was getting at. Would this patch get into FreeBSD 8.2, and would that mean that GNAT would start working properly starting with FreeBSD 8.2 if that happened? I guess that also means the other BSD's have been allowing executable stacks all along. Thanks! Kostik Belousov wrote: > This means that the Ada complier or tasking library uses on-stack > trampolines for something. Since FreeBSD threads on amd64 get > non-executable stacks, the tasking fails. > > The proper solution is to provide a support for conditional > non-executable stacks, as described in > http://lists.freebsd.org/pipermail/freebsd-arch/2010-November/010826.html > The latest WIP patch is > http://people.freebsd.org/~kib/misc/nxstacks.3.patch > I hope to get something in the tree not too long. > From owner-freebsd-threads@FreeBSD.ORG Fri Dec 31 13:44:22 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 405521065694 for ; Fri, 31 Dec 2010 13:44:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A3E528FC17 for ; Fri, 31 Dec 2010 13:44:21 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oBVDiIkd017664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Dec 2010 15:44:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oBVDiIsk016434; Fri, 31 Dec 2010 15:44:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oBVDiIPi016433; Fri, 31 Dec 2010 15:44:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 31 Dec 2010 15:44:18 +0200 From: Kostik Belousov To: John Marino Message-ID: <20101231134418.GO90883@deviant.kiev.zoral.com.ua> References: <4D1DC299.2090808@marino.st> <20101231122225.GK90883@deviant.kiev.zoral.com.ua> <4D1DCE02.3050601@marino.st> <20101231125215.GL90883@deviant.kiev.zoral.com.ua> <4D1DD5CF.5020305@marino.st> <20101231132706.GN90883@deviant.kiev.zoral.com.ua> <4D1DDC99.7000400@marino.st> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Oe/xgtOcljDBCKHf" Content-Disposition: inline In-Reply-To: <4D1DDC99.7000400@marino.st> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-threads@freebsd.org Subject: Re: AMD64 version of GNAT Ada compiler broken due to libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 13:44:22 -0000 --Oe/xgtOcljDBCKHf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 31, 2010 at 02:37:29PM +0100, John Marino wrote: > Yeah, that's kind of what I was getting at. Would this patch get into=20 > FreeBSD 8.2, and would that mean that GNAT would start working properly= =20 > starting with FreeBSD 8.2 if that happened? Definitely not in 8.2. Might be in 8.3, if successfully landed in HEAD. Besides the patch for the base system, compiler must be configured to properly mark the objects that need executable thunks on the stack. See the references in the arch@ message I pointed to. >=20 > I guess that also means the other BSD's have been allowing executable=20 > stacks all along. Or, there is a compiler configuration that prevents using the thunks on the stack. --Oe/xgtOcljDBCKHf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0d3jEACgkQC3+MBN1Mb4hfLQCeN4PPW63WUrnGPKNpddcSboD5 W38AoOaKFBzrN168fkU1/Lg6HOf6YXqD =BeEw -----END PGP SIGNATURE----- --Oe/xgtOcljDBCKHf-- From owner-freebsd-threads@FreeBSD.ORG Fri Dec 31 19:37:19 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3DE5106564A for ; Fri, 31 Dec 2010 19:37:18 +0000 (UTC) (envelope-from freebsdml@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) by mx1.freebsd.org (Postfix) with ESMTP id CA6008FC22 for ; Fri, 31 Dec 2010 19:37:18 +0000 (UTC) Received: from [192.168.1.33] (78.red-79-158-163.staticip.rima-tde.net [79.158.163.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 2758F438BE; Fri, 31 Dec 2010 13:37:16 -0600 (CST) Message-ID: <4D1E30EA.7050308@marino.st> Date: Fri, 31 Dec 2010 20:37:14 +0100 From: John Marino User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Kostik Belousov References: <4D1DC299.2090808@marino.st> <20101231122225.GK90883@deviant.kiev.zoral.com.ua> <4D1DCE02.3050601@marino.st> <20101231125215.GL90883@deviant.kiev.zoral.com.ua> <4D1DD5CF.5020305@marino.st> <20101231132706.GN90883@deviant.kiev.zoral.com.ua> <4D1DDC99.7000400@marino.st> <20101231134418.GO90883@deviant.kiev.zoral.com.ua> In-Reply-To: <20101231134418.GO90883@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org Subject: Re: AMD64 version of GNAT Ada compiler broken due to libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 19:37:19 -0000 Hi Kostik, Thanks for pointing me in the right direction. After some research, I discovered that only DragonFly BSD allows execution on the stack by default. NetBSD and OpenBSD (and Solaris and Darwin) all were specially configured within gcc to execute mprotect first to enable this functionality. FreeBSD never had this gcc configuration code and frankly it looks like it should have already been there. I created my own __enable_execute_stack macro function based on these previous works and now GNAT has passed all tests! Since i386 always worked, I only applied to macro to the AMD64 configuration header. You've been a great help! Once I understood what the issue was, everything fell into place. -- John Kostik Belousov wrote: > On Fri, Dec 31, 2010 at 02:37:29PM +0100, John Marino wrote: >> Yeah, that's kind of what I was getting at. Would this patch get into >> FreeBSD 8.2, and would that mean that GNAT would start working properly >> starting with FreeBSD 8.2 if that happened? > Definitely not in 8.2. > Might be in 8.3, if successfully landed in HEAD. > > Besides the patch for the base system, compiler must be configured > to properly mark the objects that need executable thunks on the stack. > See the references in the arch@ message I pointed to. > >> I guess that also means the other BSD's have been allowing executable >> stacks all along. > Or, there is a compiler configuration that prevents using the thunks > on the stack. From owner-freebsd-threads@FreeBSD.ORG Fri Dec 31 19:46:24 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA924106566B for ; Fri, 31 Dec 2010 19:46:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 69E2D8FC0C for ; Fri, 31 Dec 2010 19:46:22 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oBVJkJGt041344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Dec 2010 21:46:19 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oBVJkJth037731; Fri, 31 Dec 2010 21:46:19 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oBVJkJTq037730; Fri, 31 Dec 2010 21:46:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 31 Dec 2010 21:46:19 +0200 From: Kostik Belousov To: John Marino Message-ID: <20101231194619.GS90883@deviant.kiev.zoral.com.ua> References: <4D1DC299.2090808@marino.st> <20101231122225.GK90883@deviant.kiev.zoral.com.ua> <4D1DCE02.3050601@marino.st> <20101231125215.GL90883@deviant.kiev.zoral.com.ua> <4D1DD5CF.5020305@marino.st> <20101231132706.GN90883@deviant.kiev.zoral.com.ua> <4D1DDC99.7000400@marino.st> <20101231134418.GO90883@deviant.kiev.zoral.com.ua> <4D1E30EA.7050308@marino.st> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y+49MuJt7Df6jcOH" Content-Disposition: inline In-Reply-To: <4D1E30EA.7050308@marino.st> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-threads@freebsd.org Subject: Re: AMD64 version of GNAT Ada compiler broken due to libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 19:46:24 -0000 --Y+49MuJt7Df6jcOH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 31, 2010 at 08:37:14PM +0100, John Marino wrote: > Hi Kostik, >=20 > Thanks for pointing me in the right direction. After some research, I=20 > discovered that only DragonFly BSD allows execution on the stack by=20 > default. NetBSD and OpenBSD (and Solaris and Darwin) all were specially= =20 > configured within gcc to execute mprotect first to enable this=20 > functionality. FreeBSD never had this gcc configuration code and=20 > frankly it looks like it should have already been there. >=20 > I created my own __enable_execute_stack macro function based on these=20 > previous works and now GNAT has passed all tests! Since i386 always=20 > worked, I only applied to macro to the AMD64 configuration header. You need the same application of mprotect() for i386 too, since 32bit binary executed on amd64 kernel gets non-executable stack as well. >=20 > You've been a great help! Once I understood what the issue was,=20 > everything fell into place. Will you upstream the changes to gcc ? >=20 > -- John >=20 >=20 > Kostik Belousov wrote: > >On Fri, Dec 31, 2010 at 02:37:29PM +0100, John Marino wrote: > >>Yeah, that's kind of what I was getting at. Would this patch get into= =20 > >>FreeBSD 8.2, and would that mean that GNAT would start working properly= =20 > >>starting with FreeBSD 8.2 if that happened? > >Definitely not in 8.2. > >Might be in 8.3, if successfully landed in HEAD. > > > >Besides the patch for the base system, compiler must be configured > >to properly mark the objects that need executable thunks on the stack. > >See the references in the arch@ message I pointed to. > > > >>I guess that also means the other BSD's have been allowing executable= =20 > >>stacks all along. > >Or, there is a compiler configuration that prevents using the thunks > >on the stack. --Y+49MuJt7Df6jcOH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0eMwoACgkQC3+MBN1Mb4jBfgCcDEREfiAa4wpplDR5dWTgK/kw HJEAoOPJ+Nfr2yNaPwoTAgE8zStHRQJn =U9Zg -----END PGP SIGNATURE----- --Y+49MuJt7Df6jcOH-- From owner-freebsd-threads@FreeBSD.ORG Fri Dec 31 20:19:57 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FD9F1065730 for ; Fri, 31 Dec 2010 20:19:57 +0000 (UTC) (envelope-from freebsdml@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) by mx1.freebsd.org (Postfix) with ESMTP id 051C78FC18 for ; Fri, 31 Dec 2010 20:19:56 +0000 (UTC) Received: from [192.168.1.33] (78.red-79-158-163.staticip.rima-tde.net [79.158.163.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 34CEC438BE; Fri, 31 Dec 2010 14:19:54 -0600 (CST) Message-ID: <4D1E3AE8.8090907@marino.st> Date: Fri, 31 Dec 2010 21:19:52 +0100 From: John Marino User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Kostik Belousov References: <4D1DC299.2090808@marino.st> <20101231122225.GK90883@deviant.kiev.zoral.com.ua> <4D1DCE02.3050601@marino.st> <20101231125215.GL90883@deviant.kiev.zoral.com.ua> <4D1DD5CF.5020305@marino.st> <20101231132706.GN90883@deviant.kiev.zoral.com.ua> <4D1DDC99.7000400@marino.st> <20101231134418.GO90883@deviant.kiev.zoral.com.ua> <4D1E30EA.7050308@marino.st> <20101231194619.GS90883@deviant.kiev.zoral.com.ua> In-Reply-To: <20101231194619.GS90883@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org Subject: Re: AMD64 version of GNAT Ada compiler broken due to libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 20:19:57 -0000 Ah, interesting. I didn't realize the ramifications of AMD64-only application of mprotect(). It's easy enough to apply the same macro to both architectures. As far as pushing it upstream, I've got literally a few dozen patches, and the majority of them should be contributed back. I haven't gone through the absurdly difficult and time-consuming process of assigning copyright over to the FSF, partly because I reside in France with a Dutch employer and nobody I work for would sign the legal documents FSF requests (if I even wanted to share with my employers what I do in my own time.) I may go through the process some day if we can leave my employers out of it, but it's not a priority at this moment. I'm not philosophically opposed to giving back, although I am dismayed at the number of offered patches that are never reviewed by the gcc developers and die on the vine. If I could find a way to "fast-track" these patches in where I wouldn't be wasting my time, I'd do it. It's a pain to maintain a parallel fork and I'd love to reduce the number of differences between the code bases. Obviously if you have any ideas that get my FreeBSD work into the gcc efficiently, I'm all ears. Regards, John Kostik Belousov wrote: > On Fri, Dec 31, 2010 at 08:37:14PM +0100, John Marino wrote: >> Hi Kostik, >> >> Thanks for pointing me in the right direction. After some research, I >> discovered that only DragonFly BSD allows execution on the stack by >> default. NetBSD and OpenBSD (and Solaris and Darwin) all were specially >> configured within gcc to execute mprotect first to enable this >> functionality. FreeBSD never had this gcc configuration code and >> frankly it looks like it should have already been there. >> >> I created my own __enable_execute_stack macro function based on these >> previous works and now GNAT has passed all tests! Since i386 always >> worked, I only applied to macro to the AMD64 configuration header. > You need the same application of mprotect() for i386 too, since > 32bit binary executed on amd64 kernel gets non-executable stack as well. > >> You've been a great help! Once I understood what the issue was, >> everything fell into place. > Will you upstream the changes to gcc ? > From owner-freebsd-threads@FreeBSD.ORG Fri Dec 31 21:27:11 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0DEE106564A for ; Fri, 31 Dec 2010 21:27:11 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 516A08FC19 for ; Fri, 31 Dec 2010 21:27:10 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id oBVLBGBL030062; Fri, 31 Dec 2010 16:11:16 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Fri, 31 Dec 2010 16:11:16 -0500 (EST) Date: Fri, 31 Dec 2010 16:11:16 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Marino In-Reply-To: <4D1E3AE8.8090907@marino.st> Message-ID: References: <4D1DC299.2090808@marino.st> <20101231122225.GK90883@deviant.kiev.zoral.com.ua> <4D1DCE02.3050601@marino.st> <20101231125215.GL90883@deviant.kiev.zoral.com.ua> <4D1DD5CF.5020305@marino.st> <20101231132706.GN90883@deviant.kiev.zoral.com.ua> <4D1DDC99.7000400@marino.st> <20101231134418.GO90883@deviant.kiev.zoral.com.ua> <4D1E30EA.7050308@marino.st> <20101231194619.GS90883@deviant.kiev.zoral.com.ua> <4D1E3AE8.8090907@marino.st> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-threads@freebsd.org Subject: Re: AMD64 version of GNAT Ada compiler broken due to libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 21:27:11 -0000 On Fri, 31 Dec 2010, John Marino wrote: > Ah, interesting. I didn't realize the ramifications of AMD64-only > application of mprotect(). It's easy enough to apply the same macro to both > architectures. > > As far as pushing it upstream, I've got literally a few dozen patches, and > the majority of them should be contributed back. I haven't gone through the > absurdly difficult and time-consuming process of assigning copyright over to > the FSF, partly because I reside in France with a Dutch employer and nobody I > work for would sign the legal documents FSF requests (if I even wanted to > share with my employers what I do in my own time.) > > I may go through the process some day if we can leave my employers out of it, > but it's not a priority at this moment. I'm not philosophically opposed to > giving back, although I am dismayed at the number of offered patches that are > never reviewed by the gcc developers and die on the vine. If I could find a > way to "fast-track" these patches in where I wouldn't be wasting my time, I'd > do it. It's a pain to maintain a parallel fork and I'd love to reduce the > number of differences between the code bases. > > Obviously if you have any ideas that get my FreeBSD work into the gcc > efficiently, I'm all ears. I've got FSF paperwork on file, specifically to submit my original FreeBSD and VxWorks GNAT ports to AdaCore (which they then upstreamed to GCC). It's been a few years since I submitted the paperwork, however, and I'm not sure if they require resubmittal at periodic intervals. It may be possible for you to explain your changes to me, without me looking at your original code or changes. -- DE