From owner-freebsd-arm@FreeBSD.ORG Mon Jun 15 11:06:50 2009 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6DA2106566C for ; Mon, 15 Jun 2009 11:06:50 +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 D41478FC1F for ; Mon, 15 Jun 2009 11:06:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5FB6oQi076838 for ; Mon, 15 Jun 2009 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5FB6oW2076834 for freebsd-arm@FreeBSD.org; Mon, 15 Jun 2009 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 15 Jun 2009 11:06:50 GMT Message-Id: <200906151106.n5FB6oW2076834@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 11:06:51 -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 arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Jun 15 21:04:19 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A3BD106564A for ; Mon, 15 Jun 2009 21:04:19 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id B82B38FC1C for ; Mon, 15 Jun 2009 21:04:18 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id n5FL4Hjw013526; Mon, 15 Jun 2009 16:04:17 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1245099858; bh=Y+80R4ul/D/tDRdzIa29nwZwqIGwvq+SF6ExyGz2fUQ=; h=Date:From:Message-Id:To:Subject:In-Reply-To; b=eR0YQqassdpWQk29UsyPAZd7s+NUJOO1LWKs+j3kYSJUDMngk9TOtAAJHam2euNLS YH222kqYoftxeKNd6isIn9LscZ2/T7rQ6jcL/4cdYlHi9hKG4U3/wIti3NGz3zh4r7 1eVblnH7NtsBUCQy+q5BEtdTxsAO8dxPRd1jq514= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id n5FL4HYR013525; Mon, 15 Jun 2009 16:04:17 -0500 (CDT) (envelope-from tinguely) Date: Mon, 15 Jun 2009 16:04:17 -0500 (CDT) From: Mark Tinguely Message-Id: <200906152104.n5FL4HYR013525@casselton.net> To: freebsd-arm@freebsd.org, vassilis.laganakos@yahoo.com In-Reply-To: <77926.36276.qm@web59405.mail.ac4.yahoo.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Mon, 15 Jun 2009 16:04:18 -0500 (CDT) Cc: Subject: Re: ARMv7 - EABI - Cross Compiler X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 21:04:19 -0000 In case any of the Cortex/v7 projects or anyone else is interested, I have gcc-4.5 cross compiling the current GUMSTIX kernel on a i386 FreeBSD 6.4 computer (QEMU runs better under FreeBSD 6.4) - I have not tried the libs yet to a "build world". The kernel sources need some FreeBSD (format and at least one built-in define) extensions to compile that are not in the standard gcc. Besides the extensions that I copied over the code to put the binaries in the standard, reasonable places /usr/cross/libexec/cc1, for example). Gcc 4.5 -O option found a few inline and structure warnings, that required either the removal of the -O option or -Werror option for these files. I chose to remove the -Werror. The warnings are: wanted to add parenthesis around the &: ddb/db_ps.c -O detects inline optimizations in the files: devfs_vnops.c pseudofs_vnops.c kern_descrip.c kern_jail.c sys_pipe.c tty.c uipc_mbuf.c vfs_default.c vfs_lookup.c vfs_mount.c vfs_syscalls.c ffs_snapshot.c trap.c pmap.c variably modified in the definition of a structure (and some inline opt): ufs_dirhash.c ufs_inode.c ufs_lookup.c ufs_vfsops.c ufs_vnops.c I made changes to the gcc-4.5-20090528 directory and the build directory. I will look at the libraries too. --Mark Tinguely. From owner-freebsd-arm@FreeBSD.ORG Mon Jun 15 23:59:18 2009 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6A18106564A; Mon, 15 Jun 2009 23:59:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7253A8FC0C; Mon, 15 Jun 2009 23:59:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n5FNxGff012933; Mon, 15 Jun 2009 19:59:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n5FNxGrS067038; Mon, 15 Jun 2009 19:59:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 277527302F; Mon, 15 Jun 2009 19:59:16 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090615235916.277527302F@freebsd-current.sentex.ca> Date: Mon, 15 Jun 2009 19:59:16 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 23:59:19 -0000 TB --- 2009-06-15 23:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-15 23:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-06-15 23:40:00 - cleaning the object tree TB --- 2009-06-15 23:40:42 - cvsupping the source tree TB --- 2009-06-15 23:40:42 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-06-15 23:40:53 - building world TB --- 2009-06-15 23:40:53 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-15 23:40:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-15 23:40:53 - TARGET=arm TB --- 2009-06-15 23:40:53 - TARGET_ARCH=arm TB --- 2009-06-15 23:40:53 - TZ=UTC TB --- 2009-06-15 23:40:53 - __MAKE_CONF=/dev/null TB --- 2009-06-15 23:40:53 - cd /src TB --- 2009-06-15 23:40:53 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 15 23:40:55 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ===> kerberos5/lib/libroken (obj,depend,all,install) rm -f .depend mkdep -f .depend -a -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/base64.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/bswap.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/concat.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/copyhostent.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/dumpdata.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ecalloc.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/emalloc.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/environment.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/eread.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/erealloc.c /src/kerberos5/lib/libroken/../../../cryp to/heimdal/lib/roken/esetenv.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/estrdup.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ewrite.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/get_default_username.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/get_window_size.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getaddrinfo_hostspec.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getarg.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/getnameinfo_verified.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/hex.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/hostent_find_fqdn.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/issuid.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/k_getpwnam.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/k_getpwuid.c /src/kerberos5/lib/libroken/../../../c rypto/heimdal/lib/roken/mini_inetd.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/ndbm_wrap.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/net_read.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/net_write.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_bytes.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_time.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/parse_units.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/resolve.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/roken_gethostby.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/rtbl.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/simple_exec.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/snprintf.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/socket.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/s trcollect.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strlwr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strndup.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strnlen.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strpool.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strsep_copy.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/strupr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/timeval.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/tm2time.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/unvis.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/verify.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/vis.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/warnerr.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/write_pid.c cc -O -pipe -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99 -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/base64.c cc -O -pipe -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99 -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/bswap.c cc -O -pipe -I/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libroken/../../include -std=gnu99 -c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c /src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/closefrom.c:50: error: conflicting types for 'closefrom' /obj/arm/src/tmp/usr/include/unistd.h:329: error: previous declaration of 'closefrom' was here *** Error code 1 Stop in /src/kerberos5/lib/libroken. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-15 23:59:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-15 23:59:16 - ERROR: failed to build world TB --- 2009-06-15 23:59:16 - 831.69 user 98.77 system 1155.47 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Jun 16 10:01:46 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF490106566B; Tue, 16 Jun 2009 10:01:46 +0000 (UTC) (envelope-from venkiece2005@gmail.com) Received: from mail-gx0-f207.google.com (mail-gx0-f207.google.com [209.85.217.207]) by mx1.freebsd.org (Postfix) with ESMTP id 9A5708FC20; Tue, 16 Jun 2009 10:01:46 +0000 (UTC) (envelope-from venkiece2005@gmail.com) Received: by gxk3 with SMTP id 3so6816387gxk.19 for ; Tue, 16 Jun 2009 03:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=scLu95xR/Q1lhFNSxU3JsroV2l2GkFg510kiws1Bw0M=; b=Hek50uJ4Cq8VGvsyl7sMI8MfkBBoxIhhw2qm+jYXuYiY4Mnx9Sb7C5fELtSmwn9MvL NujpkGyOlJbljrtHyq3up+h/yzCmo1kzTfVwJcca39Ak7Ms7HSX+YXeM7aczUjxq96Bp 8yZb5sUkYJ3FZEVR9tL9vB7x3pYZ/BcPw1QKk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=ceV/FN4SyEwn0YZw9xg6AauB2A0Zk/9ic3IFFRzuZ+yxL9tbfjfdgnC03A6bRdpCxI ObO2pJrv8Y7+bbe1vcLKUTjLGoyQjsMwxkFWbLvUpaG3Rji5bqKG5igcMoGdlWyO/Mm1 Qbj9JNnbRdofmDt1LLGw08r/N+XwHZTqPHRL8= MIME-Version: 1.0 Received: by 10.151.119.3 with SMTP id w3mr15306939ybm.149.1245144576692; Tue, 16 Jun 2009 02:29:36 -0700 (PDT) Date: Tue, 16 Jun 2009 14:59:36 +0530 Message-ID: <6d53329e0906160229j2fdba518h84b13652153a32f6@mail.gmail.com> From: venki kaps To: freebsd-arm@freebsd.org, netbsd-users@netbsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: [libc] dlclose gives "invalid shared object handle" without pthread combination. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 10:01:47 -0000 Hi, I am using the NetBSD implementation of rtld(src/libexec/ld.elf_so/) for ARM/MIPS. I have C++ static constructor/destructor issue with my rtld. Problem Report: "ld.elf_so does not execute .init/.fini functions in order" and [libc] dlclose gives "invalid shared object handle" when called through the fini function of another module. The similar NetBSD/freeBSD issues are found from the following References: [1] http://gnats.netbsd.org/37347 [2] http://updraft3.jp.freebsd.org/cgi/query-pr.cgi?pr=kern/42956 The above issues are already commited in NetBSD-5-0-RELEASE. I have ported NetBSD-5-0-RELEASE rtld and tested Ref[1] provided static constructor/destructor test and did not find any issues with shared pthread combination but noticed [libc] dlclose gives "invalid shared object handle" without pthread combination. The static constructor/destructor test results: It should be : -------------- $ ./foobar foo_ctor bar_ctor tar_ctor main_ctor dep1_ctor dep2_ctor dll_ctor dll_dtor dep2_dtor dep1_dtor main_dtor tar_dtor bar_dtor foo_dtor While currently I get: ---------------------- with pthreads: $ ./foobar foo_ctor bar_ctor tar_ctor main_ctor dep1_ctor dep2_ctor dll_ctor dll_dtor dep2_dtor dep1_dtor main_dtor tar_dtor bar_dtor foo_dtor without pthreads: $ ./foobar foo_ctor bar_ctor tar_ctor main_ctor dep1_ctor dep2_ctor dll_ctor dll_dtor dep2_dtor dep1_dtor main_dtor tar_dtor bar_dtor foo_dtor Invalid shared object handle 0xbdbed400 This gives a "invalid shared object handle" message because the refcount field (obj->dl_refcount) for the handle is zero. I have little bit confused about dlclose destructor with/without pthreads. I have some queries: 1) Is it required any changes apart from the NetBSD-5-0-RELEASE/{Ref[1],[2]}? 2) Are any changes required in thread-stub? Could anyone provide any inputs to the my issue? Thanks in advance. Thanks & Regards, Venkappa From owner-freebsd-arm@FreeBSD.ORG Wed Jun 17 00:34:26 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57CDD106564A; Wed, 17 Jun 2009 00:34:26 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f173.google.com (mail-qy0-f173.google.com [209.85.221.173]) by mx1.freebsd.org (Postfix) with ESMTP id E1F928FC24; Wed, 17 Jun 2009 00:34:25 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by qyk3 with SMTP id 3so6284815qyk.3 for ; Tue, 16 Jun 2009 17:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=kitMmyazbIZU3ynb3GuP2oKdxmgt1Meodyd1OFCnX1M=; b=COyxB9ct+Ze7Gj+WAhrDhPuidFJqfCrL1kU54ZCfW779EhjRF6UvT+CEXPPjeBtpWF 0D40YpQhTWmnpe4HtqorCTIyNaobnu1mq9FXkmzBTlhsJPeLlFBCYx98Lx0M9GDwJnI6 nrXuRVzQPZPEHdJDkvv8EOr/F6cJqYCM8ou+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=Giis/5KOrpqBo8wsamv8AWmGRHxJbC6tLSXEcQ6eG4E5ru+BSMVdbOCZDQgZZN20sX 32DNqEGOScmWCVaJL9UMbUxc7QyEzXIq2MZVtKekhRLeSiDaQlfBpNx9PyJczvdsiDOW kGrH+3DMEWsdHMCq9GJxqu39gadqOIkQIYeZg= Received: by 10.224.29.2 with SMTP id o2mr9087890qac.102.1245197286024; Tue, 16 Jun 2009 17:08:06 -0700 (PDT) Received: from kan.dnsalias.net (c-98-217-224-113.hsd1.ma.comcast.net [98.217.224.113]) by mx.google.com with ESMTPS id 6sm223875qwd.32.2009.06.16.17.08.04 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 17:08:05 -0700 (PDT) Date: Tue, 16 Jun 2009 20:07:56 -0400 From: Alexander Kabaev To: venki kaps Message-ID: <20090616200756.70206fda@kan.dnsalias.net> In-Reply-To: <6d53329e0906160229j2fdba518h84b13652153a32f6@mail.gmail.com> References: <6d53329e0906160229j2fdba518h84b13652153a32f6@mail.gmail.com> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/rwovTwY3y=_ftDqWww523R9"; protocol="application/pgp-signature" Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org, netbsd-users@netbsd.org Subject: Re: [libc] dlclose gives "invalid shared object handle" without pthread combination. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 00:34:26 -0000 --Sig_/rwovTwY3y=_ftDqWww523R9 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi, I do not think we on FreeBSD support NetBSD rtld with our pthread libraries, unless you already implemented all the necessary glue. The interface between threading library and rtld is rather intimate and tricky to get right. You provide no code to look at nor explicitly mention what OS and what version you are running your test on (FreeBSD?), I think you are on your own. Furthermore, your claim on 'correct' constructor/destructor is wrong given the sample code provided by NetBSD PR. Some more comments are inline. On Tue, 16 Jun 2009 14:59:36 +0530 venki kaps wrote: > Hi, >=20 > I am using the NetBSD implementation of rtld(src/libexec/ld.elf_so/) > for ARM/MIPS. >=20 > I have C++ static constructor/destructor issue with my rtld. >=20 > Problem Report: > "ld.elf_so does not execute .init/.fini functions in order" and [libc] > dlclose gives > "invalid shared object handle" when called through the fini function > of another module. >=20 > The similar NetBSD/freeBSD issues are found from the following > References: [1] http://gnats.netbsd.org/37347 > [2] http://updraft3.jp.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/42956 >=20 > The above issues are already commited in NetBSD-5-0-RELEASE. >=20 > I have ported NetBSD-5-0-RELEASE rtld and tested Ref[1] provided > static constructor/destructor test and did not find any issues > with shared pthread combination but noticed [libc] dlclose gives > "invalid shared object handle" without pthread combination. >=20 > The static constructor/destructor test results: >=20 > It should be : > -------------- >=20 > $ ./foobar > foo_ctor > bar_ctor > tar_ctor > main_ctor > dep1_ctor > dep2_ctor > dll_ctor > dll_dtor > dep2_dtor > dep1_dtor > main_dtor > tar_dtor > bar_dtor > foo_dtor Given the test in Ref[1], both constructor and destructor orders are wrong above. libdep1 depends on libdep2, so dep2_ctor should be invoked before dep1_ctor and consequently dep2_dtor should be invoked after dep1_dtor. =20 > While currently I get: > ---------------------- >=20 > with pthreads: >=20 > $ ./foobar > foo_ctor > bar_ctor > tar_ctor > main_ctor > dep1_ctor > dep2_ctor > dll_ctor > dll_dtor > dep2_dtor > dep1_dtor > main_dtor > tar_dtor > bar_dtor > foo_dtor >=20 > without pthreads: >=20 > $ ./foobar > foo_ctor > bar_ctor > tar_ctor > main_ctor > dep1_ctor > dep2_ctor > dll_ctor > dll_dtor > dep2_dtor > dep1_dtor > main_dtor > tar_dtor > bar_dtor > foo_dtor > Invalid shared object handle 0xbdbed400 Again, given the sample code from NetBSD PR cannot possibly print this message because it never even calls dlerr(). You must be looking at some other code and unless you provide it, understanding your problem and fixing it is next to impossible. Said that, thanks for pointing the FreeBSD PR to me. I will commit the fix for the problem described here shortly. =20 > This gives a "invalid shared object handle" message > because the refcount field (obj->dl_refcount) for the handle is zero. >=20 > I have little bit confused about dlclose destructor > with/without pthreads. >=20 > I have some queries: > 1) Is it required any changes apart from the > NetBSD-5-0-RELEASE/{Ref[1],[2]}? 2) Are any changes required in > thread-stub? >=20 > Could anyone provide any inputs to the my issue? >=20 > Thanks in advance. >=20 > Thanks & Regards, > Venkappa --=20 Alexander Kabaev --Sig_/rwovTwY3y=_ftDqWww523R9 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQFKODPhQ6z1jMm+XZYRAuCjAKC94cJ7t9l68OMZoigdjbyLNp2t5QCg4Xzh gpe/B6QrwPZFZU9lEKejMtg= =vhtp -----END PGP SIGNATURE----- --Sig_/rwovTwY3y=_ftDqWww523R9-- From owner-freebsd-arm@FreeBSD.ORG Wed Jun 17 18:10:31 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2D261065674 for ; Wed, 17 Jun 2009 18:10:31 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 71DE98FC15 for ; Wed, 17 Jun 2009 18:10:31 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n5HIAU02080305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Jun 2009 11:10:30 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A393196.20703@freebsd.org> Date: Wed, 17 Jun 2009 11:10:30 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: freebsd-arm@freebsd.org Content-Type: multipart/mixed; boundary="------------090804070809080009040409" X-DCC-Misty-Metrics: ebb.errno.com; whitelist Subject: HEADS UP: xscale users X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 18:10:32 -0000 This is a multi-part message in MIME format. --------------090804070809080009040409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Let me know if you see any regressions w/ this change on your xscale boards. Sam --------------090804070809080009040409 Content-Type: message/rfc822; name="svn commit: r194378 - head/sys/arm/xscale/ixp425.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="svn commit: r194378 - head/sys/arm/xscale/ixp425.eml" Return-Path: Received: from ebb.errno.com ([unix socket]) (authenticated user=sam bits=0) by ebb.errno.com (Cyrus v2.2.2-BETA) with LMTP; Wed, 17 Jun 2009 10:58:11 -0700 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n5HHwBdB080203 for ; Wed, 17 Jun 2009 10:58:11 -0700 (PDT) (envelope-from owner-src-committers@FreeBSD.org) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 502211A4E21 for ; Wed, 17 Jun 2009 17:58:02 +0000 (UTC) (envelope-from owner-src-committers@FreeBSD.org) Received: by hub.freebsd.org (Postfix) id A004C1065719; Wed, 17 Jun 2009 17:57:58 +0000 (UTC) Delivered-To: sam@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 538) id 30E811065676; Wed, 17 Jun 2009 17:57:58 +0000 (UTC) Delivered-To: src-committers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C436C106566C; Wed, 17 Jun 2009 17:57:52 +0000 (UTC) (envelope-from sam@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id B21DC8FC08; Wed, 17 Jun 2009 17:57:52 +0000 (UTC) (envelope-from sam@FreeBSD.org) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.3/8.14.3) with ESMTP id n5HHvqIQ083419; Wed, 17 Jun 2009 17:57:52 GMT (envelope-from sam@svn.freebsd.org) Received: (from sam@localhost) by svn.freebsd.org (8.14.3/8.14.3/Submit) id n5HHvqu0083417; Wed, 17 Jun 2009 17:57:52 GMT (envelope-from sam@svn.freebsd.org) Message-Id: <200906171757.n5HHvqu0083417@svn.freebsd.org> From: Sam Leffler Date: Wed, 17 Jun 2009 17:57:52 +0000 (UTC) To: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: svn commit: r194378 - head/sys/arm/xscale/ixp425 X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: owner-src-committers@FreeBSD.org Precedence: bulk X-Loop: FreeBSD.ORG X-DCC-Misty-Metrics: ebb.errno.com; whitelist Author: sam Date: Wed Jun 17 17:57:52 2009 New Revision: 194378 URL: http://svn.freebsd.org/changeset/base/194378 Log: Add workaround to get IXP435 NPE-A working: reseting NPE-A after NPE-C causes both to become inoperative; this apparently was done by the original IAL code as a workaround for IMEM parity errors which we've not seen so just disable the reset. Note this problem does not occur on IXP425 boards. The linux driver does fuse-resets on each NPE but in the order NPE-A < NPE-B < NPE-C (when probing for which NPE's are present/operational); we may want to switch to a similar scheme but for now disable the resets until we see an issue. Modified: head/sys/arm/xscale/ixp425/ixp425_npe.c Modified: head/sys/arm/xscale/ixp425/ixp425_npe.c ============================================================================== --- head/sys/arm/xscale/ixp425/ixp425_npe.c Wed Jun 17 17:31:45 2009 (r194377) +++ head/sys/arm/xscale/ixp425/ixp425_npe.c Wed Jun 17 17:57:52 2009 (r194378) @@ -804,20 +804,34 @@ static const uint32_t ixNpeDlCtxtRegRese IX_NPEDL_CTXT_REG_RESET_CINDEX, }; -#define IX_NPEDL_RESET_NPE_PARITY 0x0800 #define IX_NPEDL_PARITY_BIT_MASK 0x3F00FFFF #define IX_NPEDL_CONFIG_CTRL_REG_MASK 0x3F3FFFFF +#if 0 +/* + * Reset the NPE and its coprocessor using the + * fuse bits in the feature control register. + */ +static void +npe_reset(int npeid) +{ + uint32_t mask = EXP_FCTRL_NPEA << npeid; + uint32_t v; + + v = ixp4xx_read_feature_bits(); + ixp4xx_write_feature_bits(v &~ mask); + /* un-fuse and un-reset the NPE & coprocessor */ + ixp4xx_write_feature_bits(v | mask); +} +#endif + static int npe_cpu_reset(struct ixpnpe_softc *sc) { #define N(a) (sizeof(a) / sizeof(a[0])) - struct ixp425_softc *sa = - device_get_softc(device_get_parent(sc->sc_dev)); uint32_t ctxtReg; /* identifies Context Store reg (0-3) */ uint32_t regAddr; uint32_t regVal; - uint32_t resetNpeParity; uint32_t ixNpeConfigCtrlRegVal; int i, error = 0; @@ -935,33 +949,15 @@ npe_cpu_reset(struct ixpnpe_softc *sc) /* Reset the Watch-count register */ npe_reg_write(sc, IX_NPEDL_REG_OFFSET_WC, 0); - +#if 0 /* * WR IXA00055043 - Remove IMEM Parity Introduced by NPE Reset Operation + * XXX Removed because it breaks IXP435 operation; e.g. on Gateworks + * XXX 2358 boards reseting NPE-A after NPE-C is running causes both + * XXX npe's to stop working */ - - /* - * Reset the NPE and its coprocessor - to reset internal - * states and remove parity error. Note this makes no - * sense based on the documentation. The feature control - * register always reads back as 0 on the ixp425 and further - * the bit definition of NPEA/NPEB is off by 1 according to - * the Intel documention--so we're blindly following the - * Intel code w/o any real understanding. - */ - regVal = EXP_BUS_READ_4(sa, EXP_FCTRL_OFFSET); - DPRINTFn(2, sc->sc_dev, "%s: FCTRL 0x%x\n", __func__, regVal); - resetNpeParity = - IX_NPEDL_RESET_NPE_PARITY << (1 + device_get_unit(sc->sc_dev)); - DPRINTFn(2, sc->sc_dev, "%s: FCTRL fuse parity, write 0x%x\n", - __func__, regVal | resetNpeParity); - EXP_BUS_WRITE_4(sa, EXP_FCTRL_OFFSET, regVal | resetNpeParity); - - /* un-fuse and un-reset the NPE & coprocessor */ - DPRINTFn(2, sc->sc_dev, "%s: FCTRL unfuse parity, write 0x%x\n", - __func__, regVal & resetNpeParity); - EXP_BUS_WRITE_4(sa, EXP_FCTRL_OFFSET, regVal &~ resetNpeParity); - + npe_reset(sc->sc_npeid); +#endif /* * Call NpeMgr function to stop the NPE again after the Feature Control * has unfused and Un-Reset the NPE and its associated Coprocessors. --------------090804070809080009040409-- From owner-freebsd-arm@FreeBSD.ORG Wed Jun 17 23:23:59 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 767B0106566B for ; Wed, 17 Jun 2009 23:23:59 +0000 (UTC) (envelope-from vassilis.laganakos@yahoo.com) Received: from n7a.bullet.mail.ac4.yahoo.com (n7a.bullet.mail.ac4.yahoo.com [76.13.13.70]) by mx1.freebsd.org (Postfix) with SMTP id 14E0B8FC12 for ; Wed, 17 Jun 2009 23:23:58 +0000 (UTC) (envelope-from vassilis.laganakos@yahoo.com) Received: from [76.13.13.25] by n7.bullet.mail.ac4.yahoo.com with NNFMP; 17 Jun 2009 23:23:58 -0000 Received: from [76.13.10.173] by t4.bullet.mail.ac4.yahoo.com with NNFMP; 17 Jun 2009 23:23:58 -0000 Received: from [127.0.0.1] by omp114.mail.ac4.yahoo.com with NNFMP; 17 Jun 2009 23:23:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 647213.30519.bm@omp114.mail.ac4.yahoo.com Received: (qmail 7925 invoked by uid 60001); 17 Jun 2009 23:23:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245281038; bh=qIwjjG4MYxqi2J8OkKzSlfrvtNjsTQFMJo5FW0WIJ6U=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=vkLGTsG4m7YBzmRWHsyyIcToIOA5vLKGjxYYJ4/japD4JA+WIecVWgBs8aiReaCMSncJj+MTWKULyFKm7v5xb00Ca0EHVtYlokxmi47yW94geYtXsfjFM1mVuyH4E0tIHdZLIChDnq07kb/bDrQFoAAq23eReNJmNRmIPadPkFI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=uNWbe9/yetu4piB2PYF7XuLXYRRUbJus1d6pzFg7mFRkuMXJaLQQAoMpxqsrkE51JBcDh96gz6xlgpcMQcZ12MSjqdHnQavcubTcq+35aKm96urL38r+mrZKuW1A4dBvSgQ9uutIgSQQwR+pdYd1IcQVjhE7u/u58liRBT/DLuU=; Message-ID: <523661.6738.qm@web59407.mail.ac4.yahoo.com> X-YMail-OSG: 4wlJCkYVM1mZAHvYfwbP4xnt4ktwy67jRypPZq5kL0TAWctPwyc.2uHW_rUz2jaHASBi59mSITtverUTVISi45TXrZC.p4irHUqWvyKdBU7wco0Udu_DMZEt9Lg65GyQMbSR.WKuB1Sdu3e8fIkuIgznVQCk6gE5aPHQrHGVLoUjmATjdpu3L6bTqfo4QX8TzgRZDd37Zo0l4V2syMe5068Ut1wRs5_vBGPb4ROW.vtfuShKI63u Received: from [82.6.108.148] by web59407.mail.ac4.yahoo.com via HTTP; Wed, 17 Jun 2009 16:23:58 PDT X-Mailer: YahooMailRC/1357.18 YahooMailWebService/0.7.289.15 References: <200906152104.n5FL4HYR013525@casselton.net> Date: Wed, 17 Jun 2009 16:23:58 -0700 (PDT) From: Vassilis Laganakos To: Mark Tinguely , freebsd-arm@freebsd.org In-Reply-To: <200906152104.n5FL4HYR013525@casselton.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: ARMv7 - EABI - Cross Compiler X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 23:23:59 -0000 > In case any of the Cortex/v7 projects or anyone else is interested, I have > gcc-4.5 cross compiling the current GUMSTIX kernel on a i386 FreeBSD 6.4 > computer (QEMU runs better under FreeBSD 6.4) - I have not tried the libs > yet to a "build world". > That's nice Mark, good job :o) > The kernel sources need some FreeBSD (format and at least one built-in define) > extensions to compile that are not in the standard gcc. Besides the extensions > that I copied over the code to put the binaries in the standard, reasonable > places /usr/cross/libexec/cc1, for example). > > Gcc 4.5 -O option found a few inline and structure warnings, that required > either the removal of the -O option or -Werror option for these files. > I chose to remove the -Werror. The warnings are: > > wanted to add parenthesis around the &: > ddb/db_ps.c > > -O detects inline optimizations in the files: > devfs_vnops.c pseudofs_vnops.c kern_descrip.c kern_jail.c sys_pipe.c > tty.c uipc_mbuf.c vfs_default.c vfs_lookup.c vfs_mount.c vfs_syscalls.c > ffs_snapshot.c trap.c pmap.c > > variably modified in the definition of a structure (and some inline opt): > ufs_dirhash.c ufs_inode.c ufs_lookup.c ufs_vfsops.c ufs_vnops.c > I don't know what are the changes from previous versions of GCC with the trunk. Maybe the release notes have more info on this.... > I made changes to the gcc-4.5-20090528 directory and the build directory. > I will look at the libraries too. > Cool! Kind regards, Vassilis L. From owner-freebsd-arm@FreeBSD.ORG Thu Jun 18 03:05:54 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA8A61065670 for ; Thu, 18 Jun 2009 03:05:54 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3B3358FC14 for ; Thu, 18 Jun 2009 03:05:54 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id n5I35rXh045137; Wed, 17 Jun 2009 22:05:53 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1245294353; bh=9WFrnshv1s3J+STejwCCEZxCFtxwDUvBddGZElUjq/Q=; h=Date:From:Message-Id:To:Subject:In-Reply-To; b=nnaxBN3rlYn+XrpzKQ/FlsG4+5zfH6Gar9qV+JksqBFF1x2tAxKfxsbyvLatfPw7F 5Mhp7RmCcJ/Zud/Aw1uyTqFiu6FxB5yoByoAOpR58NhlXRxcztHB0s76ocbylvcrb6 mncTr1UUiUmu5UTjFhzNBQ4i9nbM33fTMrkoIsuA= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id n5I35qci045136; Wed, 17 Jun 2009 22:05:52 -0500 (CDT) (envelope-from tinguely) Date: Wed, 17 Jun 2009 22:05:52 -0500 (CDT) From: Mark Tinguely Message-Id: <200906180305.n5I35qci045136@casselton.net> To: freebsd-arm@freebsd.org, tinguely@casselton.net, vassilis.laganakos@yahoo.com In-Reply-To: <523661.6738.qm@web59407.mail.ac4.yahoo.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Wed, 17 Jun 2009 22:05:53 -0500 (CDT) Cc: Subject: Re: ARMv7 - EABI - Cross Compiler X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 03:05:54 -0000 > I don't know what are the changes from previous versions of GCC with the trunk. > Maybe the release notes have more info on this.... FreeBSD compiler has a variable defined into it that the kernel sources expect to find, it has extended format commands, and it modifies gcc/gcc.c to look for the support programs in normal places. > > I made changes to the gcc-4.5-20090528 directory and the build directory. > > I will look at the libraries too. > > > Cool! I am still using modified GNU make file. Static libraries can cross compile an application to ARM but I gave up on configure/gmake on libmudflap. My library compile process became a hacking in the configure files. I was just walking around the problems as they popped up. Had I read and understood all the configure options, maybe it would have gone smoother. The "-Werror" complaints and "xgcc -E" as a pre-processor command are the two biggest problem in the library compilation process. Once we have a cross compiler that can make a kernel, it seems a waste of time to keep going with the configure/gmake route. Your idea of moving the sources over to the head/contrib/gcc and editing the BSD make files in head/gnu/usr.bin/cc is the way to go because making the compiler from sources is part of the cross build world. I diff-ed the sources from the GNU original (4.2.1 if memory serves me right) sources and filled in the missing pieces into the GCC 4.5 files. Some things have already been put into GCC 4.5, some areas seemed re-written. I was mostly interested in getting the FreeBSD extensions in. I can give you diff of my sources against GCC 4.5 original code or tar up both the source and build directory. The changes would be simular for GCC 4.4. There is nothing special about GCC 4.5, I just took the most recent source that is available. Also, I just blindly copied the freebsd* header files from head source into GCC 4.5. The real way of doing this is to edit up the existing GCC 4.5 header files and add the new items. I did that with a couple that are used in the ARM build. The sources in the gcc support library files are not changed; it would just take some BSD make file editing to get them to compile under the head directory. --Mark. From owner-freebsd-arm@FreeBSD.ORG Thu Jun 18 06:08:44 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1C7F106564A; Thu, 18 Jun 2009 06:08:44 +0000 (UTC) (envelope-from venkiece2005@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 9A27D8FC17; Thu, 18 Jun 2009 06:08:44 +0000 (UTC) (envelope-from venkiece2005@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so378296ywe.13 for ; Wed, 17 Jun 2009 23:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=s8zhDn8rrvCuPHM2e9iqSeXA7gDNAOa1dh+EIT/uHJw=; b=FSa3K6PyTFfrRSTr0ZIHx3Rkh0AMfCQKPUf+SGRmL/Sqb7L8fHW5wxRaxZ6j8l/lMR 8pqTRa7xTTWzNlZJktI4qgmudSQ43LTYhe0r4klMUZghJD6wHrR9oPbLIzkkL5j2ieqz DHabx7XivIZViPEwABCUnHR5m5mWqrOkEMhpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=svxN2eU5ANiiqmgp8g/vLFtYMlsRP2ZkobBVl4czWPu/H+YGJ7aFnKpGx7Vnr2ejCK /wqyljps/meM+wh/p3XOrwcy/ynVTtMENRfQB3TJu0M4Kn0PqEiTc7gQGcSd6CGtugx2 NCGl37dTMqwEhAKrKy6FUZQnjGGTb/WD4AKRA= MIME-Version: 1.0 Received: by 10.151.119.2 with SMTP id w2mr2803496ybm.200.1245305323438; Wed, 17 Jun 2009 23:08:43 -0700 (PDT) In-Reply-To: <20090616200756.70206fda@kan.dnsalias.net> References: <6d53329e0906160229j2fdba518h84b13652153a32f6@mail.gmail.com> <20090616200756.70206fda@kan.dnsalias.net> Date: Thu, 18 Jun 2009 11:38:43 +0530 Message-ID: <6d53329e0906172308j28c7f404y49f759fea4842a29@mail.gmail.com> From: venki kaps To: Alexander Kabaev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org, netbsd-users@netbsd.org Subject: Re: [libc] dlclose gives "invalid shared object handle" without pthread combination. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 06:08:45 -0000 Hi, I have been porting NetBSD source in the Linux environment with our own pthread library. system environment: Compiler: arm-linux-gcc-4.3.3 OS: Linux Kernel: 2.6.29 Yes, it never even calls dlerr() in dlcose but NetBSD __dlclose(void *handle) source sequence, int dlclose(void *handle) { Obj_Entry *root = _rtld_dlcheck(handle); if (root == NULL) return -1; _rtld_debug.r_state = RT_DELETE; _rtld_debug_state(); --root->dl_refcount; _rtld_unload_object(root, true); _rtld_debug.r_state = RT_CONSISTENT; _rtld_debug_state(); return 0; } static Obj_Entry * _rtld_dlcheck(void *handle) { Obj_Entry *obj; for (obj = _rtld_objlist; obj != NULL; obj = obj->next) if (obj == (Obj_Entry *) handle) break; xprintf("obj->dl_refcount is %d\n",obj->dl_refcount); if (obj == NULL || obj->dl_refcount == 0) { xwarnx("Invalid shared object handle %p", handle); return NULL; } return obj; } I have printed xprintf("obj->dl_refcount is %d\n",obj->dl_refcount); obj->dl_refcount is getting zero(0). So due to "obj->dl_refcount == 0" the error "invalid shared object handle" is showing. i do not know why this error is coming even though all the constructor/destructor sequences are completed. is it rtld_exit->fini->static C++ destructor->dlcose sequence problem? Thanks & Regards, Venkappa On Wed, Jun 17, 2009 at 5:37 AM, Alexander Kabaev wrote: > Hi, > > I do not think we on FreeBSD support NetBSD rtld with our pthread > libraries, unless you already implemented all the necessary glue. > The interface between threading library and rtld is rather intimate and > tricky to get right. > > You provide no code to look at nor explicitly mention what OS and > what version you are running your test on (FreeBSD?), I think you are > on your own. Furthermore, your claim on 'correct' > constructor/destructor is wrong given the sample code provided by > NetBSD PR. > > Some more comments are inline. > > On Tue, 16 Jun 2009 14:59:36 +0530 > venki kaps wrote: > >> Hi, >> >> I am using the NetBSD implementation of rtld(src/libexec/ld.elf_so/) >> for ARM/MIPS. >> >> I have C++ static constructor/destructor issue with my rtld. >> >> Problem Report: >> "ld.elf_so does not execute .init/.fini functions in order" and [libc] >> dlclose gives >> "invalid shared object handle" when called through the fini function >> of another module. >> >> The similar NetBSD/freeBSD issues are found from the following >> References: [1] http://gnats.netbsd.org/37347 >> [2] http://updraft3.jp.freebsd.org/cgi/query-pr.cgi?pr=kern/42956 >> >> The above issues are already commited in NetBSD-5-0-RELEASE. >> >> I have ported NetBSD-5-0-RELEASE rtld and tested Ref[1] provided >> static constructor/destructor test and did not find any issues >> with shared pthread combination but noticed [libc] dlclose gives >> "invalid shared object handle" without pthread combination. >> >> The static constructor/destructor test results: >> >> It should be : >> -------------- >> >> $ ./foobar >> foo_ctor >> bar_ctor >> tar_ctor >> main_ctor >> dep1_ctor >> dep2_ctor >> dll_ctor >> dll_dtor >> dep2_dtor >> dep1_dtor >> main_dtor >> tar_dtor >> bar_dtor >> foo_dtor > > Given the test in Ref[1], both constructor and destructor orders are > wrong above. libdep1 depends on libdep2, so dep2_ctor should be invoked > before dep1_ctor and consequently dep2_dtor should be invoked after > dep1_dtor. > >> While currently I get: >> ---------------------- >> >> with pthreads: >> >> $ ./foobar >> foo_ctor >> bar_ctor >> tar_ctor >> main_ctor >> dep1_ctor >> dep2_ctor >> dll_ctor >> dll_dtor >> dep2_dtor >> dep1_dtor >> main_dtor >> tar_dtor >> bar_dtor >> foo_dtor >> >> without pthreads: >> >> $ ./foobar >> foo_ctor >> bar_ctor >> tar_ctor >> main_ctor >> dep1_ctor >> dep2_ctor >> dll_ctor >> dll_dtor >> dep2_dtor >> dep1_dtor >> main_dtor >> tar_dtor >> bar_dtor >> foo_dtor >> Invalid shared object handle 0xbdbed400 > > Again, given the sample code from NetBSD PR cannot possibly print this > message because it never even calls dlerr(). You must be looking at > some other code and unless you provide it, understanding your problem > and fixing it is next to impossible. > > Said that, thanks for pointing the FreeBSD PR to me. I will commit the > fix for the problem described here shortly. > >> This gives a "invalid shared object handle" message >> because the refcount field (obj->dl_refcount) for the handle is zero. >> >> I have little bit confused about dlclose destructor >> with/without pthreads. >> >> I have some queries: >> 1) Is it required any changes apart from the >> NetBSD-5-0-RELEASE/{Ref[1],[2]}? 2) Are any changes required in >> thread-stub? >> >> Could anyone provide any inputs to the my issue? >> >> Thanks in advance. >> >> Thanks & Regards, >> Venkappa > > -- > Alexander Kabaev > From owner-freebsd-arm@FreeBSD.ORG Sat Jun 20 02:25:40 2009 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 501341065670; Sat, 20 Jun 2009 02:25:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id F02718FC12; Sat, 20 Jun 2009 02:25:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n5K2PbL2016492; Fri, 19 Jun 2009 22:25:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n5K2PbEB028998; Fri, 19 Jun 2009 22:25:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id ED32F7302F; Fri, 19 Jun 2009 22:25:36 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620022536.ED32F7302F@freebsd-current.sentex.ca> Date: Fri, 19 Jun 2009 22:25:36 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2009 02:25:40 -0000 TB --- 2009-06-20 01:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 01:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-06-20 01:20:00 - cleaning the object tree TB --- 2009-06-20 01:20:34 - cvsupping the source tree TB --- 2009-06-20 01:20:34 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-06-20 01:20:42 - building world TB --- 2009-06-20 01:20:42 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 01:20:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 01:20:42 - TARGET=arm TB --- 2009-06-20 01:20:42 - TARGET_ARCH=arm TB --- 2009-06-20 01:20:42 - TZ=UTC TB --- 2009-06-20 01:20:42 - __MAKE_CONF=/dev/null TB --- 2009-06-20 01:20:42 - cd /src TB --- 2009-06-20 01:20:42 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 01:20:45 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/ptimes.c cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o newsyslog newsyslog.o ptimes.o gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz ===> usr.sbin/nfscbd (all) cc -O -pipe -std=gnu99 -c /src/usr.sbin/nfscbd/nfscbd.c In file included from /src/usr.sbin/nfscbd/nfscbd.c:50: /obj/arm/src/tmp/usr/include/fs/nfs/nfs.h:413: error: 'RPCAUTH_UNIXGIDS' undeclared here (not in a function) *** Error code 1 Stop in /src/usr.sbin/nfscbd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 02:25:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 02:25:36 - ERROR: failed to build world TB --- 2009-06-20 02:25:36 - 3025.02 user 368.67 system 3936.20 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Jun 20 09:12:51 2009 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17B121065675; Sat, 20 Jun 2009 09:12:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id B92D18FC2A; Sat, 20 Jun 2009 09:12:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n5K9CmD0003419; Sat, 20 Jun 2009 05:12:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n5K9CmxW015886; Sat, 20 Jun 2009 05:12:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 58CBD7302F; Sat, 20 Jun 2009 05:12:48 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090620091248.58CBD7302F@freebsd-current.sentex.ca> Date: Sat, 20 Jun 2009 05:12:48 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2009 09:12:51 -0000 TB --- 2009-06-20 08:00:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-20 08:00:01 - starting HEAD tinderbox run for arm/arm TB --- 2009-06-20 08:00:01 - cleaning the object tree TB --- 2009-06-20 08:00:34 - cvsupping the source tree TB --- 2009-06-20 08:00:34 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-06-20 08:00:44 - building world TB --- 2009-06-20 08:00:44 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-20 08:00:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-20 08:00:44 - TARGET=arm TB --- 2009-06-20 08:00:44 - TARGET_ARCH=arm TB --- 2009-06-20 08:00:44 - TZ=UTC TB --- 2009-06-20 08:00:44 - __MAKE_CONF=/dev/null TB --- 2009-06-20 08:00:44 - cd /src TB --- 2009-06-20 08:00:44 - /usr/bin/make -B buildworld >>> World build started on Sat Jun 20 08:00:46 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/newsyslog/ptimes.c cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o newsyslog newsyslog.o ptimes.o gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz ===> usr.sbin/nfscbd (all) cc -O -pipe -std=gnu99 -c /src/usr.sbin/nfscbd/nfscbd.c In file included from /src/usr.sbin/nfscbd/nfscbd.c:50: /obj/arm/src/tmp/usr/include/fs/nfs/nfs.h:413: error: 'RPCAUTH_UNIXGIDS' undeclared here (not in a function) *** Error code 1 Stop in /src/usr.sbin/nfscbd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-20 09:12:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-20 09:12:48 - ERROR: failed to build world TB --- 2009-06-20 09:12:48 - 3030.41 user 373.41 system 4367.23 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full