From owner-freebsd-threads@FreeBSD.ORG Sun Jul 22 20:00:19 2012 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3328D106564A for ; Sun, 22 Jul 2012 20:00:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E8F6C8FC18 for ; Sun, 22 Jul 2012 20:00:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6MK0I6f040592 for ; Sun, 22 Jul 2012 20:00:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6MK0IMo040590; Sun, 22 Jul 2012 20:00:18 GMT (envelope-from gnats) Resent-Date: Sun, 22 Jul 2012 20:00:18 GMT Resent-Message-Id: <201207222000.q6MK0IMo040590@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-threads@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Ariane van der Steldt Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 951991065672 for ; Sun, 22 Jul 2012 19:51:57 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 80B1C8FC16 for ; Sun, 22 Jul 2012 19:51:57 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q6MJpumd071442 for ; Sun, 22 Jul 2012 19:51:56 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q6MJpuZl071441; Sun, 22 Jul 2012 19:51:56 GMT (envelope-from nobody) Message-Id: <201207221951.q6MJpuZl071441@red.freebsd.org> Date: Sun, 22 Jul 2012 19:51:56 GMT From: Ariane van der Steldt To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: threads/170073: stdatomic.h doesn't use clang builtings for C 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: Sun, 22 Jul 2012 20:00:19 -0000 >Number: 170073 >Category: threads >Synopsis: stdatomic.h doesn't use clang builtings for C >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Jul 22 20:00:18 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Ariane van der Steldt >Release: freebsd HEAD >Organization: >Environment: FreeBSD mud.stack.nl 9.0-STABLE FreeBSD 9.0-STABLE #0: Thu Jun 14 13:51:30 CEST 2012 root@mud.stack.nl:/usr/obj/usr/src/sys/GENERIC amd64 >Description: First a little disclaimer: I tested this with clang-3.1 on bitrig. The freebsd I ran this on is using clang-3.0 which does returns 0 for the c{,xx}_atomic feature/extension. stdatomic.h tests for __has_feature(cxx_atomic) which is only true when compiling in c++11 mode. However since stdatomic.h is a C header file, it should also work in c11 mode. Running: echo '__has_feature(cxx_atomic)' | clang-3.1 -x c -std=c11 -E - yields 0, while running: echo '__has_feature(c_atomic)' | clang-3.1 -x c -std=c11 -E - yields 1. In addition, I'm contemplating if __has_feature should be replaced by __has_extension, so that non-c11 code can also include stdatomic.h. >How-To-Repeat: Run the clang 3.1 preprocessor on stdatomic.h for C code and it will use the GNU counterparts of the contained code. Running the same code through the clang++ 3.1 preprocessor yields the clang counterpart of the code. >Fix: See provided diff below, using __has_extension instead of __has_feature. This also requires a compatibility define in sys/cdefs.h: #ifndef __has_extension #define __has_extension(x) 0 #endif diff --git a/include/stdatomic.h b/include/stdatomic.h index b0d1ea9..89f77dd 100644 --- a/include/stdatomic.h +++ b/include/stdatomic.h @@ -33,7 +33,7 @@ #include #include -#if __has_feature(cxx_atomic) +#if __has_extension(c_atomic) || __has_extension(cxx_atomic) #define __CLANG_ATOMICS #elif __GNUC_PREREQ__(4, 7) #define __GNUC_ATOMICS >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Mon Jul 23 11:07:27 2012 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 96973106567E for ; Mon, 23 Jul 2012 11:07:27 +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 665D58FC1C for ; Mon, 23 Jul 2012 11:07:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6NB7R1a090179 for ; Mon, 23 Jul 2012 11:07:27 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6NB7Qa7090177 for freebsd-threads@FreeBSD.org; Mon, 23 Jul 2012 11:07:26 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Jul 2012 11:07:26 GMT Message-Id: <201207231107.q6NB7Qa7090177@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, 23 Jul 2012 11:07:27 -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/170073 threads [patch] stdatomic.h doesn't use clang builtins for C o threa/168417 threads pthread_getcpuclockid() does not work to specification o threa/165173 threads [build] clang buildworld breaks libthr o threa/163512 threads libc defaults to single threaded o threa/160708 threads possible security problem with RLIMIT_VMEM o threa/150959 threads [libc] Stub pthread_once in libc should call _libc_onc 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/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 o threa/128922 threads threads hang with xorg running 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/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. 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/30464 threads [patch] pthread mutex attributes -- pshared 22 problems total. From owner-freebsd-threads@FreeBSD.ORG Wed Jul 25 18:04:57 2012 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 E2C19106564A for ; Wed, 25 Jul 2012 18:04: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 B7F638FC12 for ; Wed, 25 Jul 2012 18:04:57 +0000 (UTC) Received: from [192.168.1.33] (123.red-81-32-112.dynamicip.rima-tde.net [81.32.112.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 76516438BE for ; Wed, 25 Jul 2012 13:04:50 -0500 (CDT) Message-ID: <50103539.5090200@marino.st> Date: Wed, 25 Jul 2012 20:04:41 +0200 From: John Marino User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-threads@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Signal trampoline frame changed location on FreeBSD 9 AMD64? 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: Wed, 25 Jul 2012 18:04:58 -0000 Hi guys, I know this isn't a thread issue, but I'm hoping one of you either knows the answer or can point me to someone that does. After I patched lib/libthr/thread/thr_setschedparam.c, all the threading issues with the GNAT testsuite running on FreeBSD 9.0 disappeared. On i386-FreeBSD, GNAT passes all tests perfectly. This is not the case for x86_64-FreeBSD. GNAT fails all the stack-check / dereference tests. It can no longer detect when it's at the end of the stack during the unwind process, because it can't find the signal trampoline. For FreeBSD, it was easy. Use the kern.ps_strings sysctl and subtract X from it's address (where X is 128 on i386 and 32 on AMD64). If the stack pointer is between the addr kern.ps_strings and addr kern.ps_strings - X then it's at the end of the stack. For AMD64, according to GDB, it seems the signal trampoline frame is now ahead of the ps_strings address rather than behind it. Who can confirm this or conversely tell me how wrong I am? By the way, if I'm right, it also breaks the base system's GDB end-of-stack detection as well. It uses the same algorithm. I haven't tested this on FreeBSD 9.1 beta - just 9.0 release. Regards, John From owner-freebsd-threads@FreeBSD.ORG Wed Jul 25 18:10:48 2012 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB511106575F for ; Wed, 25 Jul 2012 18:10:48 +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 2578B8FC08 for ; Wed, 25 Jul 2012 18:10:47 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q6PIAutP063639; Wed, 25 Jul 2012 21:10:56 +0300 (EEST) (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.5/8.14.5) with ESMTP id q6PIAhir090508; Wed, 25 Jul 2012 21:10:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q6PIAhSc090507; Wed, 25 Jul 2012 21:10:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 25 Jul 2012 21:10:43 +0300 From: Konstantin Belousov To: John Marino Message-ID: <20120725181043.GP2676@deviant.kiev.zoral.com.ua> References: <50103539.5090200@marino.st> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EdHV1ukt9aOURWQF" Content-Disposition: inline In-Reply-To: <50103539.5090200@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=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham 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: Signal trampoline frame changed location on FreeBSD 9 AMD64? 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: Wed, 25 Jul 2012 18:10:48 -0000 --EdHV1ukt9aOURWQF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2012 at 08:04:41PM +0200, John Marino wrote: > Hi guys, > I know this isn't a thread issue, but I'm hoping one of you either knows= =20 > the answer or can point me to someone that does. >=20 > After I patched lib/libthr/thread/thr_setschedparam.c, all the threading= =20 > issues with the GNAT testsuite running on FreeBSD 9.0 disappeared. On=20 > i386-FreeBSD, GNAT passes all tests perfectly. >=20 > This is not the case for x86_64-FreeBSD. GNAT fails all the stack-check= =20 > / dereference tests. It can no longer detect when it's at the end of=20 > the stack during the unwind process, because it can't find the signal=20 > trampoline. >=20 > For FreeBSD, it was easy. Use the kern.ps_strings sysctl and subtract X= =20 > from it's address (where X is 128 on i386 and 32 on AMD64). If the=20 > stack pointer is between the addr kern.ps_strings and addr=20 > kern.ps_strings - X then it's at the end of the stack. >=20 > For AMD64, according to GDB, it seems the signal trampoline frame is now= =20 > ahead of the ps_strings address rather than behind it. >=20 > Who can confirm this or conversely tell me how wrong I am? > By the way, if I'm right, it also breaks the base system's GDB=20 > end-of-stack detection as well. It uses the same algorithm. >=20 > I haven't tested this on FreeBSD 9.1 beta - just 9.0 release. =46rom quite some time, the signal trampoline was moved into the separate 'shared' page. This was done to allow to remove the executable permissions from the stack mapping. BTW, I do see that at least gdb 7.4.1 stock can detect our trampoline. In-tree gdb indeed have issue understanding signal stack frame. The way forward is to implement vdso and add dwarf annotation to the trampoline code. --EdHV1ukt9aOURWQF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAQNqMACgkQC3+MBN1Mb4gzeACbBjL47IdcOCdmquzxyLZHQa7s +JwAoOTaPMDZHz/Y+6GU5fXwTmF4VymJ =g6Ae -----END PGP SIGNATURE----- --EdHV1ukt9aOURWQF-- From owner-freebsd-threads@FreeBSD.ORG Wed Jul 25 18:13:50 2012 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 81EFF1065672 for ; Wed, 25 Jul 2012 18:13:50 +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 53F8A8FC1E for ; Wed, 25 Jul 2012 18:13:50 +0000 (UTC) Received: from [192.168.1.33] (123.red-81-32-112.dynamicip.rima-tde.net [81.32.112.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 49ACD438BE; Wed, 25 Jul 2012 13:13:49 -0500 (CDT) Message-ID: <50103754.2030501@marino.st> Date: Wed, 25 Jul 2012 20:13:40 +0200 From: John Marino User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Konstantin Belousov References: <50103539.5090200@marino.st> <20120725181043.GP2676@deviant.kiev.zoral.com.ua> In-Reply-To: <20120725181043.GP2676@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: Signal trampoline frame changed location on FreeBSD 9 AMD64? 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: Wed, 25 Jul 2012 18:13:50 -0000 On 7/25/2012 20:10, Konstantin Belousov wrote: > > From quite some time, the signal trampoline was moved into the separate > 'shared' page. This was done to allow to remove the executable permissions > from the stack mapping. > > BTW, I do see that at least gdb 7.4.1 stock can detect our trampoline. > In-tree gdb indeed have issue understanding signal stack frame. > > The way forward is to implement vdso and add dwarf annotation to the > trampoline code. Thanks for the confirmation, Konstantin. I will review the gdb 7.4.1 code now. Regards, John