From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 27 00:13:51 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C95621065670; Sun, 27 Jun 2010 00:13:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6DEF08FC19; Sun, 27 Jun 2010 00:13:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o5R09ISc064733; Sat, 26 Jun 2010 18:09:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 26 Jun 2010 18:09:27 -0600 (MDT) Message-Id: <20100626.180927.999284355998302680.imp@bsdimp.com> To: yanefbsd@gmail.com From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org, des@freebsd.org Subject: Re: [PATCH] Build error with buildworld and -j1 on a memory backed /usr/obj X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 00:13:51 -0000 In message: Garrett Cooper writes: : The build for r209530 failed with a clean workspace and a clean : /usr/obj/scratch. I was building with a memory-disk backed /usr/obj. : Here's the error: : : ===> usr.bin/ar (depend) : lex -t /scratch/freebsd/current/usr.bin/ar/acplex.l > acplex.c : yacc -d /scratch/freebsd/current/usr.bin/ar/acpyacc.y : cp y.tab.c acpyacc.c : rm -f .depend : mkdep -f .depend -a -I. -I/scratch/freebsd/current/usr.bin/ar : /scratch/freebsd/current/usr.bin/ar/ar.c acplex.c acpyacc.c : /scratch/freebsd/current/usr.bin/ar/read.c : /scratch/freebsd/current/usr.bin/ar/util.c : /scratch/freebsd/current/usr.bin/ar/write.c : /scratch/freebsd/current/usr.bin/ar/ar.c:66:21: error: archive.h: No : such file or directory : /scratch/freebsd/current/usr.bin/ar/acpyacc.y:35:21: error: archive.h: : No such file or directory : /scratch/freebsd/current/usr.bin/ar/acpyacc.y:36:27: error: : archive_entry.h: No such file or directory : /scratch/freebsd/current/usr.bin/ar/read.c:33:21: error: archive.h: No : such file or directory : /scratch/freebsd/current/usr.bin/ar/read.c:34:27: error: : archive_entry.h: No such file or directory : /scratch/freebsd/current/usr.bin/ar/write.c:34:21: error: archive.h: : No such file or directory : /scratch/freebsd/current/usr.bin/ar/write.c:35:27: error: : archive_entry.h: No such file or directory : mkdep: compile failed : *** Error code 1 : : Stop in /scratch/freebsd/current/usr.bin/ar. : *** Error code 1 : : Stop in /scratch/freebsd/current/usr.bin. : *** Error code 1 : : Stop in /scratch/freebsd/current. : *** Error code 1 : : Stop in /scratch/freebsd/current. : *** Error code 1 : : Stop in /scratch/freebsd/current. : : I think this is due to dependency issues with libarchive. I had : some changes in my p4 workspace to address the libarchive dependency : for libpkg (for work that's incoming in the next couple of months) : that Warner helped me out with, and once I applied the change things : worked. The patch is attached. This patch is contaminated with other patches. Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 28 08:13:55 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2974E1065673 for ; Mon, 28 Jun 2010 08:13:55 +0000 (UTC) (envelope-from prvs=17889efc15=brian@Awfulhak.org) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id E53E98FC0A for ; Mon, 28 Jun 2010 08:13:54 +0000 (UTC) Received: from pd6ml2no-ssvc.prod.shaw.ca ([10.0.153.163]) by pd6mo1no-svcs.prod.shaw.ca with ESMTP; 28 Jun 2010 02:03:29 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=q8OS1GolVHwA:10 a=VphdPIyG4kEA:10 a=kj9zAlcOel0A:10 a=MJPcHhXccCG8eBs0us8XwA==:17 a=6pXGUcZwAAAA:8 a=MMwg4So0AAAA:8 a=6I5d2MoRAAAA:8 a=lDLiW3-ZgSQD5bl98rEA:9 a=m7LQynEc-RelkHUV0KkA:7 a=IHKqxhP10nwF3PZVza-bV3D8DioA:4 a=CjuIK1q_8ugA:10 a=GQmsRKdFs8kA:10 a=WJ3hkfHDukgA:10 a=SV7veod9ZcQA:10 Received: from unknown (HELO store.lan.Awfulhak.org) ([70.79.162.198]) by pd6ml2no-dmz.prod.shaw.ca with ESMTP; 28 Jun 2010 02:03:29 -0600 Received: from store.lan.Awfulhak.org (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 6047EC433AD_C285751B; Mon, 28 Jun 2010 08:03:29 +0000 (GMT) Received: from gw.Awfulhak.org (gw.lan.Awfulhak.org [172.16.0.1]) by store.lan.Awfulhak.org (Sophos Email Appliance) with ESMTP id 2CE40C460F9_C28574DF; Mon, 28 Jun 2010 08:03:25 +0000 (GMT) Received: from dev.lan.Awfulhak.org (brian@dev.lan.Awfulhak.org [172.16.0.5]) by gw.Awfulhak.org (8.14.4/8.14.4) with ESMTP id o5S83OBG040723; Mon, 28 Jun 2010 01:03:24 -0700 (PDT) (envelope-from brian@Awfulhak.org) Date: Mon, 28 Jun 2010 01:03:23 -0700 From: Brian Somers To: Patrick Mahan Message-ID: <20100628010323.665cb13c@dev.lan.Awfulhak.org> In-Reply-To: <4C24A7B4.5050301@mahan.org> References: <4C21A743.6040306@mahan.org> <86hbkujdto.fsf@ds4.des.no> <4C24A7B4.5050301@mahan.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 28 Jun 2010 11:01:02 +0000 Cc: Dag-Erling =?UTF-8?B?U23DuHJncmF2?= , freebsd-hackers@freebsd.org Subject: Re: Help with some makefile hackery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 08:13:55 -0000 On Fri, 25 Jun 2010 05:57:24 -0700 Patrick Mahan wrote: > src-kernel: src-kernel-tools > cd src; ./amd64-kernel.sh 2>&1 | tee build_amd64_kernel.log I've had the same issue teeing make output for coverage measurements. A better way to write this might be src-kernel: src-kernel-tools rm -f src-kernel-done { cd src; ./amd64-kernel.sh 2>&1 && touch src-kernel-done; } | tee build_amd64_kernel.log rm src-kernel-done You really want to catch all failures, including tee failures. -- Brian Somers Don't _EVER_ lose your sense of humour ! From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 28 14:49:12 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92D851065670; Mon, 28 Jun 2010 14:49:12 +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 2B7B88FC1C; Mon, 28 Jun 2010 14:49: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 o5SEn19w049074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Jun 2010 17:49:01 +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.4/8.14.4) with ESMTP id o5SEn1YB073388; Mon, 28 Jun 2010 17:49:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o5SEmxOn073387; Mon, 28 Jun 2010 17:48:59 +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: Mon, 28 Jun 2010 17:48:59 +0300 From: Kostik Belousov To: Jeremie Le Hen Message-ID: <20100628144858.GA13238@deviant.kiev.zoral.com.ua> References: <20090509113459.GD56667@e.0x20.net> <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> <20090724115649.GV68469@hoeg.nl> <20090724130928.GJ54986@felucia.tataz.chchile.org> <20090724134953.GW68469@hoeg.nl> <20090724212916.GQ55190@deviant.kiev.zoral.com.ua> <20100623210959.GA21260@felucia.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Cu2X4S6QpqS+1MBM" Content-Disposition: inline In-Reply-To: <20100623210959.GA21260@felucia.tataz.chchile.org> 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.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, 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 Hackers , marius@freebsd.org, nwhitehorn@freebsd.org Subject: Re: Avoiding sysctl at program startup using ELF aux vector (was: concurrent sysctl implementation) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 14:49:12 -0000 --Cu2X4S6QpqS+1MBM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 23, 2010 at 11:09:59PM +0200, Jeremie Le Hen wrote: > Hi Kostik, >=20 > This patch seems to have faded out from memory. Is it possible to go > forward and commit it? I refreshed the patch. Hopefully, nobody will object, and I commit it shortly. >=20 > Thanks, > Regards. >=20 > On Sat, Jul 25, 2009 at 12:29:16AM +0300, Kostik Belousov wrote: > > Below is the prototype that seems to work for me both with patched and > > old rtld on i386. Patch also contains bits for amd64 that I did not > > tested yet. All other arches are not buildable for now. > >=20 > > Patch completely eliminates sysctl syscalls from the rtld and libc > > startup. Without the patch, a single run of /bin/ls did 6 sysctls, > > with the patch, no sysctls is queried at all. > >=20 Comparing with the originally posted patch, I added support for all architectures, tested amd64 and ia32 on amd64, and converted getpagesizes(3) that added two more startup sysctls. Would be nice to get a testing for at least some !x86 architectures before the commit, I added some people who helped me in past, to the Cc:. diff --git a/lib/libc/gen/__getosreldate.c b/lib/libc/gen/__getosreldate.c index 7e26845..1bed6d0 100644 --- a/lib/libc/gen/__getosreldate.c +++ b/lib/libc/gen/__getosreldate.c @@ -29,6 +29,8 @@ __FBSDID("$FreeBSD$"); =20 #include #include +#include +#include =20 int __getosreldate(void); =20 @@ -51,7 +53,15 @@ __getosreldate(void) =20 if (osreldate !=3D 0) return (osreldate); -=09 + + if (_rtld_aux_info !=3D NULL) + error =3D _rtld_aux_info(AT_OSRELDATE, &osreldate, + sizeof(osreldate)); + else + error =3D ENOSYS; + if (error =3D=3D 0 && osreldate !=3D 0) + return (osreldate); + oid[0] =3D CTL_KERN; oid[1] =3D KERN_OSRELDATE; osrel =3D 0; diff --git a/lib/libc/gen/getpagesize.c b/lib/libc/gen/getpagesize.c index d796b9d..b8f0ec1 100644 --- a/lib/libc/gen/getpagesize.c +++ b/lib/libc/gen/getpagesize.c @@ -36,6 +36,8 @@ __FBSDID("$FreeBSD$"); #include #include =20 +#include +#include #include =20 /* @@ -52,13 +54,23 @@ getpagesize() int mib[2];=20 static int value; size_t size; + int error; + + if (value !=3D 0) + return (value); + + if (_rtld_aux_info !=3D NULL) + error =3D _rtld_aux_info(AT_PAGESZ, &value, sizeof(value)); + else + error =3D ENOSYS; + if (error =3D=3D 0 && value !=3D 0) + return (value); + + mib[0] =3D CTL_HW; + mib[1] =3D HW_PAGESIZE; + size =3D sizeof value; + if (sysctl(mib, 2, &value, &size, NULL, 0) =3D=3D -1) + return (-1); =20 - if (!value) { - mib[0] =3D CTL_HW; - mib[1] =3D HW_PAGESIZE; - size =3D sizeof value; - if (sysctl(mib, 2, &value, &size, NULL, 0) =3D=3D -1) - return (-1); - } return (value); } diff --git a/lib/libc/gen/getpagesizes.c b/lib/libc/gen/getpagesizes.c index b0de939..bfeeef8 100644 --- a/lib/libc/gen/getpagesizes.c +++ b/lib/libc/gen/getpagesizes.c @@ -32,6 +32,7 @@ __FBSDID("$FreeBSD$"); #include =20 #include +#include =20 /* * Retrieves page size information from the system. Specifically, returns= the @@ -51,7 +52,7 @@ getpagesizes(size_t pagesize[], int nelem) static u_long ps[MAXPAGESIZES]; static int nops; size_t size; - int i;=20 + int error, i; =20 if (nelem < 0 || (nelem > 0 && pagesize =3D=3D NULL)) { errno =3D EINVAL; @@ -59,9 +60,16 @@ getpagesizes(size_t pagesize[], int nelem) } /* Cache the result of the sysctl(2). */ if (nops =3D=3D 0) { - size =3D sizeof(ps); - if (sysctlbyname("hw.pagesizes", ps, &size, NULL, 0) =3D=3D -1) - return (-1); + if (_rtld_aux_info !=3D NULL) + error =3D _rtld_aux_info(AT_PAGESIZES, ps, sizeof(ps)); + else + error =3D ENOSYS; + if (error !=3D 0 || ps[0] =3D=3D 0) { + size =3D sizeof(ps); + if (sysctlbyname("hw.pagesizes", ps, &size, NULL, 0) + =3D=3D -1) + return (-1); + } /* Count the number of page sizes that are supported. */ nops =3D size / sizeof(ps[0]); while (nops > 0 && ps[nops - 1] =3D=3D 0) diff --git a/lib/libc/stdlib/malloc.c b/lib/libc/stdlib/malloc.c index 295a168..41be6d8 100644 --- a/lib/libc/stdlib/malloc.c +++ b/lib/libc/stdlib/malloc.c @@ -180,6 +180,7 @@ __FBSDID("$FreeBSD$"); =20 #include #include +#include #include #include #include @@ -5348,14 +5349,23 @@ small_size2bin_init_hard(void) static unsigned malloc_ncpus(void) { + int mib[2]; unsigned ret; - size_t retlen =3D sizeof(ret); - int mib[] =3D {CTL_HW, HW_NCPU}; + int error; + size_t len; =20 - if (sysctl(mib, sizeof(mib) / sizeof(int), &ret, &retlen, - (void *)0, 0) =3D=3D -1) { - /* Error. */ - ret =3D 1; + if (_rtld_aux_info !=3D NULL) + error =3D _rtld_aux_info(AT_NCPUS, &ret, sizeof(ret)); + else + error =3D ENOSYS; + if (error !=3D 0 || ret =3D=3D 0) { + mib[0] =3D CTL_HW; + mib[1] =3D HW_NCPU; + len =3D sizeof(ret); + if (sysctl(mib, 2, &ret, &len, (void *)NULL, 0) =3D=3D -1) { + /* Error. */ + ret =3D 1; + } } =20 return (ret); diff --git a/lib/libc/sys/stack_protector.c b/lib/libc/sys/stack_protector.c index 14c20eb..e868d3b 100644 --- a/lib/libc/sys/stack_protector.c +++ b/lib/libc/sys/stack_protector.c @@ -34,6 +34,8 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include +#include #include #include #include @@ -54,9 +56,17 @@ __guard_setup(void) { int mib[2]; size_t len; + int error; =20 if (__stack_chk_guard[0] !=3D 0) return; + if (_rtld_aux_info !=3D NULL) + error =3D _rtld_aux_info(AT_CANARY, __stack_chk_guard, + sizeof(__stack_chk_guard)); + else + error =3D ENOSYS; + if (error =3D=3D 0 && __stack_chk_guard[0] !=3D 0) + return; =20 mib[0] =3D CTL_KERN; mib[1] =3D KERN_ARND; diff --git a/libexec/rtld-elf/Symbol.map b/libexec/rtld-elf/Symbol.map index ce1e3e5..f45f955 100644 --- a/libexec/rtld-elf/Symbol.map +++ b/libexec/rtld-elf/Symbol.map @@ -24,4 +24,5 @@ FBSDprivate_1.0 { _rtld_free_tls; _rtld_atfork_pre; _rtld_atfork_post; + _rtld_aux_info; }; diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c index 8082656..6c5914c 100644 --- a/libexec/rtld-elf/rtld.c +++ b/libexec/rtld-elf/rtld.c @@ -40,6 +40,7 @@ #include #include #include +#include #include #include #include @@ -84,6 +85,9 @@ typedef struct Struct_DoneList { */ static const char *basename(const char *); static void die(void) __dead2; +static void digest_dynamic1(Obj_Entry *, int, const Elf_Dyn **, + const Elf_Dyn **); +static void digest_dynamic2(Obj_Entry *, const Elf_Dyn *, const Elf_Dyn *); static void digest_dynamic(Obj_Entry *, int); static Obj_Entry *digest_phdr(const Elf_Phdr *, int, caddr_t, const char *= ); static Obj_Entry *dlcheck(void *); @@ -97,7 +101,7 @@ static char *find_library(const char *, const Obj_Entry = *); static const char *gethints(void); static void init_dag(Obj_Entry *); static void init_dag1(Obj_Entry *, Obj_Entry *, DoneList *); -static void init_rtld(caddr_t); +static void init_rtld(caddr_t, Elf_Auxinfo **); static void initlist_add_neededs(Needed_Entry *, Objlist *); static void initlist_add_objects(Obj_Entry *, Obj_Entry **, Objlist *); static bool is_exported(const Elf_Sym *); @@ -188,6 +192,9 @@ extern Elf_Dyn _DYNAMIC; #define RTLD_IS_DYNAMIC() (&_DYNAMIC !=3D NULL) #endif =20 +static int pagesize, osreldate, canary_len, ncpus, pagesizes_len; +static char *canary, *pagesizes; + /* * These are the functions the dynamic linker exports to application * programs. They are the only symbols the dynamic linker is willing @@ -214,6 +221,7 @@ static func_ptr_type exports[] =3D { (func_ptr_type) &dl_iterate_phdr, (func_ptr_type) &_rtld_atfork_pre, (func_ptr_type) &_rtld_atfork_post, + (func_ptr_type) &_rtld_aux_info, NULL }; =20 @@ -350,7 +358,7 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_proc, Obj_Entry= **objp) =20 /* Initialize and relocate ourselves. */ assert(aux_info[AT_BASE] !=3D NULL); - init_rtld((caddr_t) aux_info[AT_BASE]->a_un.a_ptr); + init_rtld((caddr_t) aux_info[AT_BASE]->a_un.a_ptr, aux_info); =20 __progname =3D obj_rtld.path; argv0 =3D argv[0] !=3D NULL ? argv[0] : "(null)"; @@ -737,14 +745,16 @@ die(void) * information in its Obj_Entry structure. */ static void -digest_dynamic(Obj_Entry *obj, int early) +digest_dynamic1(Obj_Entry *obj, int early, const Elf_Dyn **dyn_rpath, + const Elf_Dyn **dyn_soname) { const Elf_Dyn *dynp; Needed_Entry **needed_tail =3D &obj->needed; - const Elf_Dyn *dyn_rpath =3D NULL; - const Elf_Dyn *dyn_soname =3D NULL; int plttype =3D DT_REL; =20 + *dyn_rpath =3D NULL; + *dyn_soname =3D NULL; + obj->bind_now =3D false; for (dynp =3D obj->dynamic; dynp->d_tag !=3D DT_NULL; dynp++) { switch (dynp->d_tag) { @@ -868,11 +878,11 @@ digest_dynamic(Obj_Entry *obj, int early) * We have to wait until later to process this, because we * might not have gotten the address of the string table yet. */ - dyn_rpath =3D dynp; + *dyn_rpath =3D dynp; break; =20 case DT_SONAME: - dyn_soname =3D dynp; + *dyn_soname =3D dynp; break; =20 case DT_INIT: @@ -961,6 +971,12 @@ digest_dynamic(Obj_Entry *obj, int early) obj->pltrelasize =3D obj->pltrelsize; obj->pltrelsize =3D 0; } +} + +static void +digest_dynamic2(Obj_Entry *obj, const Elf_Dyn *dyn_rpath, + const Elf_Dyn *dyn_soname) +{ =20 if (obj->z_origin && obj->origin_path =3D=3D NULL) { obj->origin_path =3D xmalloc(PATH_MAX); @@ -978,6 +994,16 @@ digest_dynamic(Obj_Entry *obj, int early) object_add_name(obj, obj->strtab + dyn_soname->d_un.d_val); } =20 +static void +digest_dynamic(Obj_Entry *obj, int early) +{ + const Elf_Dyn *dyn_rpath; + const Elf_Dyn *dyn_soname; + + digest_dynamic1(obj, early, &dyn_rpath, &dyn_soname); + digest_dynamic2(obj, dyn_rpath, dyn_soname); +} + /* * Process a shared object's program header. This is used only for the * main program, when the kernel has already loaded the main program @@ -1304,9 +1330,11 @@ init_dag1(Obj_Entry *root, Obj_Entry *obj, DoneList = *dlp) * this function is to relocate the dynamic linker. */ static void -init_rtld(caddr_t mapbase) +init_rtld(caddr_t mapbase, Elf_Auxinfo **aux_info) { Obj_Entry objtmp; /* Temporary rtld object */ + const Elf_Dyn *dyn_rpath; + const Elf_Dyn *dyn_soname; =20 /* * Conjure up an Obj_Entry structure for the dynamic linker. @@ -1323,7 +1351,7 @@ init_rtld(caddr_t mapbase) #endif if (RTLD_IS_DYNAMIC()) { objtmp.dynamic =3D rtld_dynamic(&objtmp); - digest_dynamic(&objtmp, 1); + digest_dynamic1(&objtmp, 1, &dyn_rpath, &dyn_soname); assert(objtmp.needed =3D=3D NULL); #if !defined(__mips__) /* MIPS and SH{3,5} have a bogus DT_TEXTREL. */ @@ -1344,6 +1372,23 @@ init_rtld(caddr_t mapbase) /* Now that non-local variables can be accesses, copy out obj_rtld. */ memcpy(&obj_rtld, &objtmp, sizeof(obj_rtld)); =20 + if (aux_info[AT_PAGESZ] !=3D NULL) + pagesize =3D aux_info[AT_PAGESZ]->a_un.a_val; + if (aux_info[AT_OSRELDATE] !=3D NULL) + osreldate =3D aux_info[AT_OSRELDATE]->a_un.a_val; + if (aux_info[AT_CANARY] !=3D NULL && aux_info[AT_CANARYLEN] !=3D NULL)= { + canary =3D aux_info[AT_CANARY]->a_un.a_ptr; + canary_len =3D aux_info[AT_CANARYLEN]->a_un.a_val; + } + if (aux_info[AT_PAGESIZES] !=3D NULL && aux_info[AT_PAGESIZESLEN] !=3D= NULL) { + pagesizes =3D aux_info[AT_PAGESIZES]->a_un.a_ptr; + pagesizes_len =3D aux_info[AT_PAGESIZESLEN]->a_un.a_val; + } + if (aux_info[AT_NCPUS] !=3D NULL) + ncpus =3D aux_info[AT_NCPUS]->a_un.a_val; + + digest_dynamic2(&obj_rtld, dyn_rpath, dyn_soname); + /* Replace the path with a dynamically allocated copy. */ obj_rtld.path =3D xstrdup(PATH_RTLD); =20 @@ -3630,3 +3675,118 @@ fetch_ventry(const Obj_Entry *obj, unsigned long sy= mnum) } return NULL; } + +static int +__getosreldate(void) +{ + static int osreldate; + size_t len; + int oid[2]; + int error, osrel; + + oid[0] =3D CTL_KERN; + oid[1] =3D KERN_OSRELDATE; + osrel =3D 0; + len =3D sizeof(osrel); + error =3D sysctl(oid, 2, &osrel, &len, NULL, 0); + if (error =3D=3D 0 && osrel > 0 && len =3D=3D sizeof(osrel)) + osreldate =3D osrel; + return (osreldate); +} + +static int +__getpagesize(void) +{ + int mib[2]; + static int value; + size_t size; + + mib[0] =3D CTL_HW; + mib[1] =3D HW_PAGESIZE; + size =3D sizeof value; + if (sysctl(mib, 2, &value, &size, NULL, 0) =3D=3D -1) + return (-1); + + return (value); +} + +static int +__getncpus(void) +{ + int mib[2]; + size_t len; + int n; + + mib[0] =3D CTL_HW; + mib[1] =3D HW_NCPU; + len =3D sizeof(ncpus); + if (sysctl(mib, 2, &n, &len, (void *) 0, 0) =3D=3D -1) + n =3D 1; + return (n); +} + +int +_rtld_aux_info(int aux, void *buf, int buflen) +{ + int res; + + switch (aux) { + case AT_CANARY: + if (canary !=3D NULL && canary_len >=3D buflen) { + memcpy(buf, canary, buflen); + memset(canary, 0, canary_len); + canary =3D NULL; + res =3D 0; + } else + res =3D ENOENT; + break; + case AT_PAGESIZES: + if (pagesizes !=3D NULL && pagesizes_len >=3D buflen) { + memcpy(buf, pagesizes, buflen); + res =3D 0; + } else + res =3D ENOENT; + break; + + case AT_PAGESZ: + if (buflen =3D=3D sizeof(int)) { + if (pagesize =3D=3D 0) + pagesize =3D __getpagesize(); + if (pagesize !=3D 0) { + *(int *)buf =3D pagesize; + res =3D 0; + } else + res =3D ENOENT; + } else + res =3D EINVAL; + break; + case AT_OSRELDATE: + if (buflen =3D=3D sizeof(int)) { + if (osreldate =3D=3D 0) + osreldate =3D __getosreldate(); + if (osreldate !=3D 0) { + *(int *)buf =3D osreldate; + res =3D 0; + } else + res =3D ENOENT; + } else + res =3D EINVAL; + break; + case AT_NCPUS: + if (buflen =3D=3D sizeof(int)) { + if (ncpus =3D=3D 0) + ncpus =3D __getncpus(); + if (ncpus !=3D 0) { + *(int *)buf =3D ncpus; + res =3D 0; + } else + res =3D ENOENT; + } else + res =3D EINVAL; + break; + default: + res =3D ENOENT; + break; + } + return (res); +} diff --git a/sys/amd64/include/elf.h b/sys/amd64/include/elf.h index 678f5d3..1f5c754 100644 --- a/sys/amd64/include/elf.h +++ b/sys/amd64/include/elf.h @@ -88,8 +88,14 @@ __ElfType(Auxinfo); #define AT_GID 13 /* Real gid. */ #define AT_EGID 14 /* Effective gid. */ #define AT_EXECPATH 15 /* Path to the executable. */ - -#define AT_COUNT 16 /* Count of defined aux entry types. */ +#define AT_CANARY 16 /* Canary for SSP */ +#define AT_CANARYLEN 17 /* Length of the canary. */ +#define AT_OSRELDATE 18 /* OSRELDATE. */ +#define AT_NCPUS 19 /* Number of CPUs. */ +#define AT_PAGESIZES 20 /* Pagesizes. */ +#define AT_PAGESIZESLEN 21 /* Number of pagesizes. */ + +#define AT_COUNT 22 /* Count of defined aux entry types. */ =20 /* * Relocation types. diff --git a/sys/arm/include/elf.h b/sys/arm/include/elf.h index 0660ba6..4cb2ae3 100644 --- a/sys/arm/include/elf.h +++ b/sys/arm/include/elf.h @@ -76,8 +76,14 @@ __ElfType(Auxinfo); #define AT_GID 13 /* Real gid. */ #define AT_EGID 14 /* Effective gid. */ #define AT_EXECPATH 15 /* Path to the executable. */ - -#define AT_COUNT 16 /* Count of defined aux entry types. */ +#define AT_CANARY 16 /* Canary for SSP */ +#define AT_CANARYLEN 17 /* Length of the canary. */ +#define AT_OSRELDATE 18 /* OSRELDATE. */ +#define AT_NCPUS 19 /* Number of CPUs. */ +#define AT_PAGESIZES 20 /* Pagesizes. */ +#define AT_PAGESIZESLEN 21 /* Number of pagesizes. */ + +#define AT_COUNT 22 /* Count of defined aux entry types. */ =20 #define R_ARM_COUNT 33 /* Count of defined relocation types. */ =20 diff --git a/sys/compat/freebsd32/freebsd32_misc.c b/sys/compat/freebsd32/f= reebsd32_misc.c index f0fde2b..cc4172c 100644 --- a/sys/compat/freebsd32/freebsd32_misc.c +++ b/sys/compat/freebsd32/freebsd32_misc.c @@ -2524,11 +2524,13 @@ syscall32_helper_unregister(struct syscall_helper_d= ata *sd) register_t * freebsd32_copyout_strings(struct image_params *imgp) { - int argc, envc; + int argc, envc, i; u_int32_t *vectp; char *stringp, *destp; u_int32_t *stack_base; struct freebsd32_ps_strings *arginfo; + char canary[sizeof(long) * 8]; + int32_t pagesizes32[MAXPAGESIZES]; size_t execpath_len; int szsigcode; =20 @@ -2543,8 +2545,10 @@ freebsd32_copyout_strings(struct image_params *imgp) arginfo =3D (struct freebsd32_ps_strings *)FREEBSD32_PS_STRINGS; szsigcode =3D *(imgp->proc->p_sysent->sv_szsigcode); destp =3D (caddr_t)arginfo - szsigcode - SPARE_USRSPACE - - roundup(execpath_len, sizeof(char *)) - - roundup((ARG_MAX - imgp->args->stringspace), sizeof(char *)); + roundup(execpath_len, sizeof(char *)) - + roundup(sizeof(canary), sizeof(char *)) - + roundup(sizeof(pagesizes32), sizeof(char *)) - + roundup((ARG_MAX - imgp->args->stringspace), sizeof(char *)); =20 /* * install sigcode @@ -2563,6 +2567,25 @@ freebsd32_copyout_strings(struct image_params *imgp) } =20 /* + * Prepare the canary for SSP. + */ + arc4rand(canary, sizeof(canary), 0); + imgp->canary =3D (uintptr_t)arginfo - szsigcode - execpath_len - + sizeof(canary); + copyout(canary, (void *)imgp->canary, sizeof(canary)); + imgp->canarylen =3D sizeof(canary); + + /* + * Prepare the pagesizes array. + */ + for (i =3D 0; i < MAXPAGESIZES; i++) + pagesizes32[i] =3D (uint32_t)pagesizes[i]; + imgp->pagesizes =3D (uintptr_t)arginfo - szsigcode - execpath_len - + roundup(sizeof(canary), sizeof(char *)) - sizeof(pagesizes32); + copyout(pagesizes32, (void *)imgp->pagesizes, sizeof(pagesizes32)); + imgp->pagesizeslen =3D sizeof(pagesizes32); + + /* * If we have a valid auxargs ptr, prepare some room * on the stack. */ diff --git a/sys/i386/include/elf.h b/sys/i386/include/elf.h index 37ee279..6490f2a 100644 --- a/sys/i386/include/elf.h +++ b/sys/i386/include/elf.h @@ -90,8 +90,14 @@ __ElfType(Auxinfo); #define AT_GID 13 /* Real gid. */ #define AT_EGID 14 /* Effective gid. */ #define AT_EXECPATH 15 /* Path to the executable. */ - -#define AT_COUNT 16 /* Count of defined aux entry types. */ +#define AT_CANARY 16 /* Canary for SSP. */ +#define AT_CANARYLEN 17 /* Length of the canary. */ +#define AT_OSRELDATE 18 /* OSRELDATE. */ +#define AT_NCPUS 19 /* Number of CPUs. */ +#define AT_PAGESIZES 20 /* Pagesizes. */ +#define AT_PAGESIZESLEN 21 /* Number of pagesizes. */ + +#define AT_COUNT 22 /* Count of defined aux entry types. */ =20 /* * Relocation types. diff --git a/sys/ia64/include/elf.h b/sys/ia64/include/elf.h index 27182db..ab7706b 100644 --- a/sys/ia64/include/elf.h +++ b/sys/ia64/include/elf.h @@ -89,8 +89,14 @@ __ElfType(Auxinfo); #define AT_GID 13 /* Real gid. */ #define AT_EGID 14 /* Effective gid. */ #define AT_EXECPATH 15 /* Path to the executable. */ - -#define AT_COUNT 16 /* Count of defined aux entry types. */ +#define AT_CANARY 16 /* Canary for SSP */ +#define AT_CANARYLEN 17 /* Length of the canary. */ +#define AT_OSRELDATE 18 /* OSRELDATE. */ +#define AT_NCPUS 19 /* Number of CPUs. */ +#define AT_PAGESIZES 20 /* Pagesizes. */ +#define AT_PAGESIZESLEN 21 /* Number of pagesizes. */ + +#define AT_COUNT 22 /* Count of defined aux entry types. */ =20 /* * Values for e_flags. diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index c48e0f5..88c64e9 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -51,6 +51,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -972,6 +973,16 @@ __elfN(freebsd_fixup)(register_t **stack_base, struct = image_params *imgp) AUXARGS_ENTRY(pos, AT_BASE, args->base); if (imgp->execpathp !=3D 0) AUXARGS_ENTRY(pos, AT_EXECPATH, imgp->execpathp); + AUXARGS_ENTRY(pos, AT_OSRELDATE, imgp->proc->p_osrel); + if (imgp->canary !=3D 0) { + AUXARGS_ENTRY(pos, AT_CANARY, imgp->canary); + AUXARGS_ENTRY(pos, AT_CANARYLEN, imgp->canarylen); + } + AUXARGS_ENTRY(pos, AT_NCPUS, mp_ncpus); + if (imgp->pagesizes !=3D 0) { + AUXARGS_ENTRY(pos, AT_PAGESIZES, imgp->pagesizes); + AUXARGS_ENTRY(pos, AT_PAGESIZESLEN, imgp->pagesizeslen); + } AUXARGS_ENTRY(pos, AT_NULL, 0); =20 free(imgp->auxargs, M_TEMP); diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c index 149e6df..1387529 100644 --- a/sys/kern/kern_exec.c +++ b/sys/kern/kern_exec.c @@ -386,6 +386,10 @@ do_execve(td, args, mac_p) imgp->args =3D args; imgp->execpath =3D imgp->freepath =3D NULL; imgp->execpathp =3D 0; + imgp->canary =3D 0; + imgp->canarylen =3D 0; + imgp->pagesizes =3D 0; + imgp->pagesizeslen =3D 0; =20 #ifdef MAC error =3D mac_execve_enter(imgp, mac_p); @@ -1183,8 +1187,10 @@ exec_copyout_strings(imgp) struct ps_strings *arginfo; struct proc *p; size_t execpath_len; - int szsigcode; + int szsigcode, szps; + char canary[sizeof(long) * 8]; =20 + szps =3D sizeof(pagesizes[0]) * MAXPAGESIZES; /* * Calculate string base and vector table pointers. * Also deal with signal trampoline code for this exec type. @@ -1200,6 +1206,8 @@ exec_copyout_strings(imgp) szsigcode =3D *(p->p_sysent->sv_szsigcode); destp =3D (caddr_t)arginfo - szsigcode - SPARE_USRSPACE - roundup(execpath_len, sizeof(char *)) - + roundup(sizeof(canary), sizeof(char *)) - + roundup(szps, sizeof(char *)) - roundup((ARG_MAX - imgp->args->stringspace), sizeof(char *)); =20 /* @@ -1219,6 +1227,23 @@ exec_copyout_strings(imgp) } =20 /* + * Prepare the canary for SSP. + */ + arc4rand(canary, sizeof(canary), 0); + imgp->canary =3D (uintptr_t)arginfo - szsigcode - execpath_len - + sizeof(canary); + copyout(canary, (void *)imgp->canary, sizeof(canary)); + imgp->canarylen =3D sizeof(canary); + + /* + * Prepare the pagesizes array. + */ + imgp->pagesizes =3D (uintptr_t)arginfo - szsigcode - execpath_len - + roundup(sizeof(canary), sizeof(char *)) - szps; + copyout(pagesizes, (void *)imgp->pagesizes, szps); + imgp->pagesizeslen =3D szps; + + /* * If we have a valid auxargs ptr, prepare some room * on the stack. */ @@ -1235,8 +1260,8 @@ exec_copyout_strings(imgp) * for argument of Runtime loader. */ vectp =3D (char **)(destp - (imgp->args->argc + - imgp->args->envc + 2 + imgp->auxarg_size + execpath_len) * - sizeof(char *)); + imgp->args->envc + 2 + imgp->auxarg_size) + * sizeof(char *)); } else { /* * The '+ 2' is for the null pointers at the end of each of diff --git a/sys/mips/include/elf.h b/sys/mips/include/elf.h index 2d6ca3e..2646181 100644 --- a/sys/mips/include/elf.h +++ b/sys/mips/include/elf.h @@ -251,8 +251,14 @@ __ElfType(Auxinfo); #define AT_GID 13 /* Real gid. */ #define AT_EGID 14 /* Effective gid. */ #define AT_EXECPATH 15 /* Path to the executable. */ +#define AT_CANARY 16 /* Canary for SSP */ +#define AT_CANARYLEN 17 /* Length of the canary. */ +#define AT_OSRELDATE 18 /* OSRELDATE. */ +#define AT_NCPUS 19 /* Number of CPUs. */ +#define AT_PAGESIZES 20 /* Pagesizes. */ +#define AT_PAGESIZESLEN 21 /* Number of pagesizes. */ =20 -#define AT_COUNT 16 /* Count of defined aux entry types. */ +#define AT_COUNT 22 /* Count of defined aux entry types. */ =20 #define ET_DYN_LOAD_ADDR 0x0120000 =20 diff --git a/sys/powerpc/include/elf.h b/sys/powerpc/include/elf.h index e01488d..5ea3281 100644 --- a/sys/powerpc/include/elf.h +++ b/sys/powerpc/include/elf.h @@ -78,8 +78,14 @@ __ElfType(Auxinfo); #define AT_ICACHEBSIZE 11 /* Instruction cache block size for the uP. */ #define AT_UCACHEBSIZE 12 /* Cache block size, or `0' if cache not unified= . */ #define AT_EXECPATH 13 /* Path to the executable. */ - -#define AT_COUNT 14 /* Count of defined aux entry types. */ +#define AT_CANARY 14 /* Canary for SSP */ +#define AT_CANARYLEN 15 /* Length of the canary. */ +#define AT_OSRELDATE 16 /* OSRELDATE. */ +#define AT_NCPUS 17 /* Number of CPUs. */ +#define AT_PAGESIZES 18 /* Pagesizes. */ +#define AT_PAGESIZESLEN 19 /* Number of pagesizes. */ + +#define AT_COUNT 20 /* Count of defined aux entry types. */ =20 /* * Relocation types. diff --git a/sys/sparc64/include/elf.h b/sys/sparc64/include/elf.h index 2a66670..0618434 100644 --- a/sys/sparc64/include/elf.h +++ b/sys/sparc64/include/elf.h @@ -84,8 +84,14 @@ __ElfType(Auxinfo); #define AT_GID 13 /* Real gid. */ #define AT_EGID 14 /* Effective gid. */ #define AT_EXECPATH 15 /* Path to the executable. */ +#define AT_CANARY 16 /* Canary for SSP */ +#define AT_CANARYLEN 17 /* Length of the canary. */ +#define AT_OSRELDATE 18 /* OSRELDATE. */ +#define AT_NCPUS 19 /* Number of CPUs. */ +#define AT_PAGESIZES 20 /* Pagesizes. */ +#define AT_PAGESIZESLEN 21 /* Number of pagesizes. */ =20 -#define AT_COUNT 16 /* Count of defined aux entry types. */ +#define AT_COUNT 22 /* Count of defined aux entry types. */ =20 /* Define "machine" characteristics */ #if __ELF_WORD_SIZE =3D=3D 32 diff --git a/sys/sun4v/include/elf.h b/sys/sun4v/include/elf.h index 2a66670..0618434 100644 --- a/sys/sun4v/include/elf.h +++ b/sys/sun4v/include/elf.h @@ -84,8 +84,14 @@ __ElfType(Auxinfo); #define AT_GID 13 /* Real gid. */ #define AT_EGID 14 /* Effective gid. */ #define AT_EXECPATH 15 /* Path to the executable. */ +#define AT_CANARY 16 /* Canary for SSP */ +#define AT_CANARYLEN 17 /* Length of the canary. */ +#define AT_OSRELDATE 18 /* OSRELDATE. */ +#define AT_NCPUS 19 /* Number of CPUs. */ +#define AT_PAGESIZES 20 /* Pagesizes. */ +#define AT_PAGESIZESLEN 21 /* Number of pagesizes. */ =20 -#define AT_COUNT 16 /* Count of defined aux entry types. */ +#define AT_COUNT 22 /* Count of defined aux entry types. */ =20 /* Define "machine" characteristics */ #if __ELF_WORD_SIZE =3D=3D 32 diff --git a/sys/sys/imgact.h b/sys/sys/imgact.h index 1d1e361..3d1a049 100644 --- a/sys/sys/imgact.h +++ b/sys/sys/imgact.h @@ -70,6 +70,10 @@ struct image_params { char *execpath; unsigned long execpathp; char *freepath; + unsigned long canary; + int canarylen; + unsigned long pagesizes; + int pagesizeslen; }; =20 #ifdef _KERNEL diff --git a/sys/sys/link_elf.h b/sys/sys/link_elf.h index 98840a5..30f3d75 100644 --- a/sys/sys/link_elf.h +++ b/sys/sys/link_elf.h @@ -92,6 +92,10 @@ __BEGIN_DECLS =20 typedef int (*__dl_iterate_hdr_callback)(struct dl_phdr_info *, size_t, vo= id *); extern int dl_iterate_phdr(__dl_iterate_hdr_callback, void *); +extern int _rtld_aux_info(int, void *, int); +#ifndef IN_RTLD +#pragma weak _rtld_aux_info +#endif =20 __END_DECLS =20 diff --git a/tools/test/auxinfo/Makefile b/tools/test/auxinfo/Makefile new file mode 100644 index 0000000..d0ba464 --- /dev/null +++ b/tools/test/auxinfo/Makefile @@ -0,0 +1,7 @@ +# $FreeBSD + +PROG=3D auxinfo +NO_MAN=3D +WARNS?=3D 6 + +.include \ No newline at end of file diff --git a/tools/test/auxinfo/auxinfo.c b/tools/test/auxinfo/auxinfo.c new file mode 100644 index 0000000..374bed8 --- /dev/null +++ b/tools/test/auxinfo/auxinfo.c @@ -0,0 +1,58 @@ +/* + * This file is in public domain. + * Written by Konstantin Belousov + * + * $FreeBSD$ + */ + +#include +#include +#include +#include +#include +#include + +static void +test_pagesizes(void) +{ + size_t *ps; + int i, nelem; + + nelem =3D getpagesizes(NULL, 0); + if (nelem =3D=3D -1) + err(1, "getpagesizes(NULL, 0)"); + ps =3D malloc(nelem * sizeof(size_t)); + if (ps =3D=3D NULL) + err(1, "malloc"); + nelem =3D getpagesizes(ps, nelem); + if (nelem =3D=3D -1) + err(1, "getpagesizes"); + printf("Supported page sizes:"); + for (i =3D 0; i < nelem; i++) + printf(" %jd", (intmax_t)ps[i]); + printf("\n"); +} + +static void +test_pagesize(void) +{ + + printf("Pagesize: %d\n", getpagesize()); +} + +static void +test_osreldate(void) +{ + + printf("OSRELDATE: %d\n", getosreldate()); +} + +int +main(int argc __unused, char *argv[] __unused) +{ + + test_pagesizes(); + test_pagesize(); + test_osreldate(); + return (0); +} --Cu2X4S6QpqS+1MBM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwotloACgkQC3+MBN1Mb4hJ6QCaAqBNJoWUXpzc4oXayue3iSMs CL0AoKIdgVvQWeCpSmwIl0rzGCgweFzh =hsGK -----END PGP SIGNATURE----- --Cu2X4S6QpqS+1MBM-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 29 08:39:13 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C78001065672; Tue, 29 Jun 2010 08:39:13 +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 435948FC16; Tue, 29 Jun 2010 08:39:12 +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 o5T8d2cr037992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jun 2010 11:39:02 +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.4/8.14.4) with ESMTP id o5T8d1t9079932; Tue, 29 Jun 2010 11:39:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o5T8d1TQ079931; Tue, 29 Jun 2010 11:39:01 +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: Tue, 29 Jun 2010 11:39:01 +0300 From: Kostik Belousov To: Marius Strobl Message-ID: <20100629083901.GG13238@deviant.kiev.zoral.com.ua> References: <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> <20090724115649.GV68469@hoeg.nl> <20090724130928.GJ54986@felucia.tataz.chchile.org> <20090724134953.GW68469@hoeg.nl> <20090724212916.GQ55190@deviant.kiev.zoral.com.ua> <20100623210959.GA21260@felucia.tataz.chchile.org> <20100628144858.GA13238@deviant.kiev.zoral.com.ua> <20100629082639.GH96870@alchemy.franken.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ACogS/Nlo5ygnE7x" Content-Disposition: inline In-Reply-To: <20100629082639.GH96870@alchemy.franken.de> 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.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, 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 Hackers , Jeremie Le Hen , nwhitehorn@freebsd.org Subject: Re: Avoiding sysctl at program startup using ELF aux vector (was: concurrent sysctl implementation) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 08:39:14 -0000 --ACogS/Nlo5ygnE7x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 29, 2010 at 10:26:39AM +0200, Marius Strobl wrote: > On Mon, Jun 28, 2010 at 05:48:59PM +0300, Kostik Belousov wrote: > > On Wed, Jun 23, 2010 at 11:09:59PM +0200, Jeremie Le Hen wrote: > > > Hi Kostik, > > >=20 > > > This patch seems to have faded out from memory. Is it possible to go > > > forward and commit it? > > I refreshed the patch. Hopefully, nobody will object, and I commit it > > shortly. > >=20 > > >=20 > > > Thanks, > > > Regards. > > >=20 > > > On Sat, Jul 25, 2009 at 12:29:16AM +0300, Kostik Belousov wrote: > > > > Below is the prototype that seems to work for me both with patched = and > > > > old rtld on i386. Patch also contains bits for amd64 that I did not > > > > tested yet. All other arches are not buildable for now. > > > >=20 > > > > Patch completely eliminates sysctl syscalls from the rtld and libc > > > > startup. Without the patch, a single run of /bin/ls did 6 sysctls, > > > > with the patch, no sysctls is queried at all. > > > >=20 > > Comparing with the originally posted patch, I added support for all > > architectures, tested amd64 and ia32 on amd64, and converted getpagesiz= es(3) > > that added two more startup sysctls. > >=20 > > Would be nice to get a testing for at least some !x86 architectures > > before the commit, I added some people who helped me in past, to the Cc= :. > >=20 >=20 > Doesn't look good on sparc64: > <...> > NFS ROOT: 192.168.1.40:/usr/data/nfsroot/sparc64 > dc1: link state changed to UP > pid 24 (ifconfig), uid 0: exited on signal 11 > Segmentation fault > Interface IP-Address Broadcast > pid 29 (rcorder), uid 0: exited on signal 11 > Segmentation fault > pid 30 (grep), uid 0: exited on signal 11 > Segmentation fault > pid 31 (rcorder), uid 0: exited on signal 11 > Segmentation fault > =20 > pid 32 (date), uid 0: exited on signal 11 > Segmentation fault > Jun 29 12:20:50 getty[36]: open /dev/ttyv3: No such file or directory > <...> >=20 > Unfortunately, I currently lack the time to debug this. Thank you. --ACogS/Nlo5ygnE7x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwpsSUACgkQC3+MBN1Mb4hWeQCgwo6XcikdbmdZVzhlBOx0DeT4 vxkAn2ZUPdIlTmGwoUVAOMsuPN5YgeSi =HtZR -----END PGP SIGNATURE----- --ACogS/Nlo5ygnE7x-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 29 08:46:13 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99F0E106566C for ; Tue, 29 Jun 2010 08:46:13 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 08FD68FC08 for ; Tue, 29 Jun 2010 08:46:12 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o5T8Qe2A007821; Tue, 29 Jun 2010 10:26:40 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o5T8Qd7e007820; Tue, 29 Jun 2010 10:26:39 +0200 (CEST) (envelope-from marius) Date: Tue, 29 Jun 2010 10:26:39 +0200 From: Marius Strobl To: Kostik Belousov Message-ID: <20100629082639.GH96870@alchemy.franken.de> References: <20090509121313.GA58540@hoeg.nl> <20090724073451.GH54986@felucia.tataz.chchile.org> <20090724081842.GF55190@deviant.kiev.zoral.com.ua> <20090724115404.GI54986@felucia.tataz.chchile.org> <20090724115649.GV68469@hoeg.nl> <20090724130928.GJ54986@felucia.tataz.chchile.org> <20090724134953.GW68469@hoeg.nl> <20090724212916.GQ55190@deviant.kiev.zoral.com.ua> <20100623210959.GA21260@felucia.tataz.chchile.org> <20100628144858.GA13238@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100628144858.GA13238@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Hackers , Jeremie Le Hen , nwhitehorn@freebsd.org Subject: Re: Avoiding sysctl at program startup using ELF aux vector (was: concurrent sysctl implementation) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 08:46:13 -0000 On Mon, Jun 28, 2010 at 05:48:59PM +0300, Kostik Belousov wrote: > On Wed, Jun 23, 2010 at 11:09:59PM +0200, Jeremie Le Hen wrote: > > Hi Kostik, > > > > This patch seems to have faded out from memory. Is it possible to go > > forward and commit it? > I refreshed the patch. Hopefully, nobody will object, and I commit it > shortly. > > > > > Thanks, > > Regards. > > > > On Sat, Jul 25, 2009 at 12:29:16AM +0300, Kostik Belousov wrote: > > > Below is the prototype that seems to work for me both with patched and > > > old rtld on i386. Patch also contains bits for amd64 that I did not > > > tested yet. All other arches are not buildable for now. > > > > > > Patch completely eliminates sysctl syscalls from the rtld and libc > > > startup. Without the patch, a single run of /bin/ls did 6 sysctls, > > > with the patch, no sysctls is queried at all. > > > > Comparing with the originally posted patch, I added support for all > architectures, tested amd64 and ia32 on amd64, and converted getpagesizes(3) > that added two more startup sysctls. > > Would be nice to get a testing for at least some !x86 architectures > before the commit, I added some people who helped me in past, to the Cc:. > Doesn't look good on sparc64: <...> NFS ROOT: 192.168.1.40:/usr/data/nfsroot/sparc64 dc1: link state changed to UP pid 24 (ifconfig), uid 0: exited on signal 11 Segmentation fault Interface IP-Address Broadcast pid 29 (rcorder), uid 0: exited on signal 11 Segmentation fault pid 30 (grep), uid 0: exited on signal 11 Segmentation fault pid 31 (rcorder), uid 0: exited on signal 11 Segmentation fault pid 32 (date), uid 0: exited on signal 11 Segmentation fault Jun 29 12:20:50 getty[36]: open /dev/ttyv3: No such file or directory <...> Unfortunately, I currently lack the time to debug this. Marius From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 29 22:07:51 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A3971065670 for ; Tue, 29 Jun 2010 22:07:51 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id E9C868FC1A for ; Tue, 29 Jun 2010 22:07:50 +0000 (UTC) Received: by qyk12 with SMTP id 12so39936qyk.13 for ; Tue, 29 Jun 2010 15:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=4wuT+/XJ+31tdQMBE6NnGUlAdN/yh8PwxtwodKN+/ns=; b=fQj7BG1GAWjcFnHBLW+WHuh6gLRpLto2VivqQoVoah5clFYncWea3RDkdFnhBaVo/T hpX+W+q5WDa+3PA+gUbZK8JPBFt2f50R724sHKtW3l5vZ4+5V9FgmvPFGmZu1BWY8ALp ULXOmOFN3I9d3hysUsxDbfqwYYdYKx7jSnIEI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=scj2hqBdzIOMaGP7Cd3wz1vQlbquXRnpwr8O7ITfPZVtBJdAax8rae8gNj72+9ulqh vYzSxLjSCcxQCu7r4nRvUoBEmKU7d7Bd2kV44M+f/1StWAyUJDfkD/8r3PDmqGt5CaBl 5oFwH51hJoHDThe32E7/FhMWpj4sSoAFw18Co= MIME-Version: 1.0 Received: by 10.224.78.157 with SMTP id l29mr5344060qak.214.1277849254703; Tue, 29 Jun 2010 15:07:34 -0700 (PDT) Received: by 10.229.221.83 with HTTP; Tue, 29 Jun 2010 15:07:33 -0700 (PDT) Date: Tue, 29 Jun 2010 15:07:33 -0700 Message-ID: From: Garrett Cooper To: FreeBSD-Hackers Content-Type: multipart/mixed; boundary=00c09f9c9762e95631048a327659 Subject: Set default pxeboot vfs.root.mountfrom to nfs? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 22:07:51 -0000 --00c09f9c9762e95631048a327659 Content-Type: text/plain; charset=ISO-8859-1 Hi Hackers, I realize this is a trivial patch, but it's a minor item that I found kind of fascinating (and not thoroughly documented elsewhere because many examples are booting mfsroots instead of directly booting off nfs roots), but I'm proposing that pxeboot default to vfs.root.mountfrom="nfs" to reduce the need for special case loader.conf files just for pxe booting (and thus, enable out-of-the-box netbooting ^o^!!!). Thoughts? Thanks! -Garrett --00c09f9c9762e95631048a327659 Content-Type: application/octet-stream; name="pxeboot-default-to-nfs.diff" Content-Disposition: attachment; filename="pxeboot-default-to-nfs.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gb104zyr0 SW5kZXg6IGJvb3QvaTM4Ni9saWJpMzg2L3B4ZS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGJvb3QvaTM4Ni9s aWJpMzg2L3B4ZS5jCShyZXZpc2lvbiAyMDk1NjMpCisrKyBib290L2kzODYvbGliaTM4Ni9weGUu Ywkod29ya2luZyBjb3B5KQpAQCAtMzA4LDYgKzMwOCw3IEBACiAJCX0KIAkJc2V0ZW52KCJib290 Lm5mc3Jvb3Quc2VydmVyIiwgaW5ldF9udG9hKHJvb3RpcCksIDEpOwogCQlzZXRlbnYoImJvb3Qu bmZzcm9vdC5wYXRoIiwgcm9vdHBhdGgsIDEpOworCQlzZXRlbnYoInZmcy5yb290Lm1vdW50ZnJv bSIsICJuZnMiLCAwKTsKIAkJc2V0ZW52KCJkaGNwLmhvc3QtbmFtZSIsIGhvc3RuYW1lLCAxKTsK IAl9CiAgICAgfQo= --00c09f9c9762e95631048a327659-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 29 23:54:22 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FAE21065673 for ; Tue, 29 Jun 2010 23:54:22 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3B0F68FC18 for ; Tue, 29 Jun 2010 23:54:21 +0000 (UTC) Received: by vws13 with SMTP id 13so303773vws.13 for ; Tue, 29 Jun 2010 16:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=DXNYmGXo7iLFwl4w3xZb1aEYDz7RYisYjfDmWRa35sw=; b=rKNwEQBy1X6XS/NDnxyAh/B5QESRHi3cqPQtHPQEN7RJz8i2CGGKx8wq0PN92+EGnj 07ov+7b4V/lpCTyiW1zg8LaG7cEaOxNth4PKtVhbkogpwU0B/hu8CfOefLc1WzyW3GGB wVg/cxH243Oe+vhOWupp8ou88eyCPdaef6Mk0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=PE3QAV3HifV+OURPu3onEp1QaFjYUFeYY8MFwRLZatnb2GLFt/ut6VrDy4ozb9zj13 kpiTfKm/bPBdYAX0WV0kHDogXIkWGy2FgEeYvNakWunIqHTSk4K1E1o+cN2/f+88nDCw HB4E4bXqUsxWm7Al5hf1KjNetvSIPKnQUWWIY= MIME-Version: 1.0 Received: by 10.224.27.215 with SMTP id j23mr5326387qac.224.1277855651141; Tue, 29 Jun 2010 16:54:11 -0700 (PDT) Received: by 10.229.41.203 with HTTP; Tue, 29 Jun 2010 16:54:11 -0700 (PDT) Date: Tue, 29 Jun 2010 18:54:11 -0500 Message-ID: From: "Sam Fourman Jr." To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 23:54:22 -0000 Hello FreeBSD hackers. Last Tuesday blizzard release World of Warcraft 3.3.5, and with this patch World of warcraft stopped working in FreeBSD 8.1 amd64, it crashes right after login. details here: http://bugs.winehq.org/show_bug.cgi?id=23323 in the above thread a wine developer stated the problem is this: WoW uses opcode 0xf1 (icebp) and expects to see a single step exception, probably as a way to detect hardware debuggers. With the kernel change icebp is no longer raising a SIGTRAP since it doesn't set any dr6 bits, so WoW doesn't get its exception. Linux fixed this with this kernel patch https://bugzilla.kernel.org/show_bug.cgi?id=16315 I have been playing World of Warcraft on FreeBSD amd64 since December of 2009 using the beta Nvidia 64bit drivers and this wine how-to http://wiki.freebsd.org/Wine#head-6963d527c173e57b1567e881305b544d33435b6d I can verify that on PCBSD 8.1 RC1 32bit World of warcraft works post 3.3.5 so far as I can tell it is only broken on amd64. Would someone be able to comment on weather a patch is indeed needed on FreeBSD amd64? Thank you -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 06:26:16 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09EDB106564A for ; Wed, 30 Jun 2010 06:26:16 +0000 (UTC) (envelope-from andrey.zonov@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8B3D18FC0A for ; Wed, 30 Jun 2010 06:26:15 +0000 (UTC) Received: by bwz12 with SMTP id 12so220478bwz.13 for ; Tue, 29 Jun 2010 23:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=BWQlX2wI7NLSHTbMsd8fO4w60KbM37pywFJOVd0Yq/k=; b=qfuzei8M3GIdzYJRzfrwhAhZPf8tsnHeT8tel+fq1dDGiG6XsBEzKhuJBg0rITQ0KO 1mcBHdTV3k8yVfCrxoftdcYJcnTc2lQdXEVJdllFGTOexPvAwWQJHjvP8fXQdYU7blnk LbbAJL02DVpTYCTu1V/2mfP7RV16KPQi6QA2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=AlPB9YxcdK064ZXF7oon5XftoIXONGIY565BxeBgKzYwBsRzC4/+x56S2SwRnSMhz6 +lUjWddLDXW7FTyldklYGDFu7RceAXWuaT/Ly8NR7KQKcf3fapKogt9v+i7iayKzLGX8 5vk6osJL+1petJFqbp465BTreFS6O11D7Caws= Received: by 10.204.123.3 with SMTP id n3mr1483848bkr.21.1277879170510; Tue, 29 Jun 2010 23:26:10 -0700 (PDT) Received: from [10.254.254.77] (ppp79-139-207-225.pppoe.spdop.ru [79.139.207.225]) by mx.google.com with ESMTPS id by5sm6011626bkb.20.2010.06.29.23.26.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 29 Jun 2010 23:26:09 -0700 (PDT) Message-ID: <4C2AE37C.5060000@gmail.com> Date: Wed, 30 Jun 2010 10:26:04 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: How change process flags from userland? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 06:26:16 -0000 Hi, I want to set P_PROTECTED flag for some daemons after it start, without patching application and kernel. It possible? -- Andrey Zonov From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 07:30:35 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2216B106566C for ; Wed, 30 Jun 2010 07:30:35 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward1.mail.yandex.net (forward1.mail.yandex.net [77.88.46.6]) by mx1.freebsd.org (Postfix) with ESMTP id C19BC8FC13 for ; Wed, 30 Jun 2010 07:30:34 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward1.mail.yandex.net (Yandex) with ESMTP id EBBB269E99B4; Wed, 30 Jun 2010 11:30:32 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1277883032; bh=6qZ1Zq2VkiEDp573zvp+V+YPAi1Xhz0VPtN06t+0aiM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=i+oPsZMuTYSjBrfztXgpzn5WBDp2LYzV+/g79sLme+nuTzvnfJLjqFFkCr+u+uTyD 0pyJqR5wyUvv86lIswjNAGs2i7LlKOtqaV42XeL70a0cyCZT/VoHo1a2Zo+SL41P46 CdwCa/xEL99kjPOxgY1LWN8iNKLWem7XlJVtcZ+U= Received: from btr.properlan.net (www.heavennet.ru [77.72.136.193]) by smtp4.mail.yandex.net (Yandex) with ESMTPSA id AE6F01280B0; Wed, 30 Jun 2010 11:30:32 +0400 (MSD) Message-ID: <4C2AF285.1090506@yandex.ru> Date: Wed, 30 Jun 2010 11:30:13 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100611 Thunderbird/3.0.4 MIME-Version: 1.0 To: Andrey Zonov References: <4C2AE37C.5060000@gmail.com> In-Reply-To: <4C2AE37C.5060000@gmail.com> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDF12D44C3BAA7B1D02FFFF21" X-Yandex-TimeMark: 1277883032 X-Yandex-Spam: 1 X-Yandex-Front: smtp4.mail.yandex.net Cc: freebsd-hackers@freebsd.org Subject: Re: How change process flags from userland? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 07:30:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDF12D44C3BAA7B1D02FFFF21 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 30.06.2010 10:26, Andrey Zonov wrote: > Hi, >=20 > I want to set P_PROTECTED flag for some daemons after it start, without= > patching application and kernel. > It possible? >=20 Did you try sysutils/scprotect? --=20 WBR, Andrey V. Elsukov --------------enigDF12D44C3BAA7B1D02FFFF21 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJMKvKKAAoJEAHF6gQQyKF6MeAH/jmC0n9hxmDIagr0J0DxDVlw tgREMRwdmk7/S1znM4kq+qd2Gtje7o4OuOmrmo4bDd705O7NpWPA+oL5et5iblKT Ke/apCeirMIUuQ3pE8cQDx6jtPu6WNx2sNTK0B+43g/0ly5CmswvKmJwoy4BRmmr 9sG6Inx1pgDeYxmwfpIkwrxKZ3m5MjAN6Ss0g+yF7pCQwRuJYBTziDEaH1NnekBw eq6oJqdQXd5XDB/an0Oghq2109kqZCe7x5KW7Qj+9tE1IVvtYQD7jmpOyJJMnjno QGYnmnW5H/ivblQsCsA3eOrcqW7pzl1a4Y0h/U8DToAQ+YJPVxjiiNpL+Zyt9JA= =zZN7 -----END PGP SIGNATURE----- --------------enigDF12D44C3BAA7B1D02FFFF21-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 07:33:17 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C30BF106564A for ; Wed, 30 Jun 2010 07:33:17 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6A38FC08 for ; Wed, 30 Jun 2010 07:33:16 +0000 (UTC) Received: by wyb34 with SMTP id 34so603712wyb.13 for ; Wed, 30 Jun 2010 00:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=PY76K+WpMcy8MmRI7yvZe98S34BL9lkbk4zZuP4wxyU=; b=lUG0Id9jdd1oy6/jOz39D7WYK6vmByqSqJpzHkA2AoMulyLmAspJ1GMnZ6b0I+uxTJ WThfHhG4YfQhDaH+ZcXjWsaKXJ/RFU5CgAkmJo94mdynIGHtaNQRmGRXd0WV4zlD5pjQ 5ZKJV/Z0BW9FtMS1xG8ks547ieTK1Z//27IKQ= 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; b=I8T7Fd/VfH9DkEDL94Z/SdzEv91xAMuGLDVLLKvqwKm9Q2W7l/JeQP+wzChmgTrlw5 nY2JhtfWeHrc8WOTT34nuDQ+qeBdIPDA6ziNcdS+qFPaaqSycXtuAVmL+6mHXIWQSANi pv5ulOADIVPXtNxsmc7a3iwTiPjEFa178RGGM= MIME-Version: 1.0 Received: by 10.216.85.211 with SMTP id u61mr10840747wee.103.1277883190210; Wed, 30 Jun 2010 00:33:10 -0700 (PDT) Received: by 10.216.37.68 with HTTP; Wed, 30 Jun 2010 00:33:10 -0700 (PDT) In-Reply-To: <4C2AE37C.5060000@gmail.com> References: <4C2AE37C.5060000@gmail.com> Date: Wed, 30 Jun 2010 11:33:10 +0400 Message-ID: From: pluknet To: Andrey Zonov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: How change process flags from userland? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 07:33:17 -0000 On 30 June 2010 10:26, Andrey Zonov wrote: > Hi, > > I want to set P_PROTECTED flag for some daemons after it start, without > patching application and kernel. > It possible? > May be madvise(NULL, 0, MADV_PROTECT) will fit your needs? (see howto example in usr.sbin/cron). Note, this behav isn't portable. -- wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 07:35:55 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AF29106564A for ; Wed, 30 Jun 2010 07:35:55 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 343588FC1B for ; Wed, 30 Jun 2010 07:35:54 +0000 (UTC) Received: by wyb34 with SMTP id 34so606757wyb.13 for ; Wed, 30 Jun 2010 00:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=kmneIXTOWZIgJPkMfFPet/QIca5nwy38FR9r68RdV2E=; b=NZURBnEUj2wyRj1lqKl7aTCE/y9Fxs8TVL9YxBGqTX7zoxFgEUnLDoh7vkzmE78l/v JR32eVIuE12wTUiR9dkc/ntU5jrkc8StgIwAOQMsNVcpOEE7vccwsHQIcuAafG5kCjUK PR1i8Ysj5wAhY7pLHCGDk+f1ReSd0gXhEZ+NU= 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; b=JIBLH0EkUsO0pP7tXbtnu4EnB7q5vvXW00dD4MYYJHpfK0X3y3V875ljBO6klo6tCI 5MXgPmWnI+F/yAW3AQrBQ2PvdMrp38w+VPeg8W9frReNVxxmQZ4N25BlZgZdSJLcWmON I/GjJy8R0D2lChk/Q2CaLjbXbR4u978YtOS6A= MIME-Version: 1.0 Received: by 10.216.85.71 with SMTP id t49mr10868337wee.19.1277883354127; Wed, 30 Jun 2010 00:35:54 -0700 (PDT) Received: by 10.216.37.68 with HTTP; Wed, 30 Jun 2010 00:35:54 -0700 (PDT) In-Reply-To: References: <4C2AE37C.5060000@gmail.com> Date: Wed, 30 Jun 2010 11:35:54 +0400 Message-ID: From: pluknet To: Andrey Zonov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: How change process flags from userland? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 07:35:55 -0000 On 30 June 2010 11:33, pluknet wrote: > On 30 June 2010 10:26, Andrey Zonov wrote: >> Hi, >> >> I want to set P_PROTECTED flag for some daemons after it start, without >> patching application and kernel. >> It possible? >> > > May be madvise(NULL, 0, MADV_PROTECT) will fit your needs? > (see howto example in usr.sbin/cron). > Note, this behav isn't portable. > Ahem, please ignore my post. -- wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 07:42:18 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A6121065674 for ; Wed, 30 Jun 2010 07:42:18 +0000 (UTC) (envelope-from dhruvakm@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2808B8FC19 for ; Wed, 30 Jun 2010 07:42:17 +0000 (UTC) Received: by qyk32 with SMTP id 32so88618qyk.13 for ; Wed, 30 Jun 2010 00:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=44kzpV5IMIH8UltYNaK7disrwdbRMlJGi/Xj5JJaNxU=; b=Lp0efTfyfVkpt5nBvK7KurwtYH69M46vLsxXkJymo4Tphd/Aj+Pe3xz5aBP1VgRL1F G5nmhiv8y7N72znzd6w4nSQkcwlET1N+lj1ybmgolm1eKQzXL9KNfEoNO0jAp3VPXU4g 0sIh3sfNGV+TxH8v85IuT3BMVeW7bw4hVq4ZY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=CBYqd0jATBHlV5ATrhSLL6kUXSGvGLTzIBu7xqDX8O2nYhR8saKe9uyshZVU1FrCUl Am1W4uFIz1nxbHeVRsLgMeLs4bu2FsC4fjbGg+6Z6/xffMYCHX+k1Ka6lvB30n7Kxm0o q/IVstioMxcVYqUOffYpIUohsdUHOgFfv/5TU= MIME-Version: 1.0 Received: by 10.224.79.226 with SMTP id q34mr5830205qak.83.1277882355803; Wed, 30 Jun 2010 00:19:15 -0700 (PDT) Received: by 10.229.184.75 with HTTP; Wed, 30 Jun 2010 00:19:11 -0700 (PDT) Date: Wed, 30 Jun 2010 12:49:12 +0530 Message-ID: From: dhruva To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Subject: mallinfo equivalent on FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 07:42:18 -0000 Hello, I would like to know the memory usage (total virtual memory) inside a process and make decisions accordingly. To be more specific, I am using BerkeleyDB backed set or std::set (C++ STL) depending on my current memory usage as my process will need to run in a resource constrained environment. By the way, this is user mode application. Some things I am considering/tried: 1. GNU/Linux has mallinfo and I had my code working based on the information I get from the call. 2. I tried using getrusage() and it does not give the total virtual memory usage. 3. Another approach is to set the memory soft limit to the watermark I am interested, trap SIGSEGV and increase the watermark to the original value (save it before modifying). The problem here would be to differentiate between different causes for SIGSEGV and handling them differently. In M$ (Windoze), I could have done this using structured exception handling around the call to malloc. The problem in #3 would be to revert once the memory usage has gone below the watermark. Any suggestions would help me progress. with best regards, dhruva From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 09:01:57 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 807C0106566C for ; Wed, 30 Jun 2010 09:01:57 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2D13E8FC18 for ; Wed, 30 Jun 2010 09:01:57 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 27B9DA58D9C; Wed, 30 Jun 2010 17:01:56 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id Iah9DFIJOCfj; Wed, 30 Jun 2010 17:01:49 +0800 (CST) Received: from delta.delphij.net (c-24-4-100-103.hsd1.ca.comcast.net [24.4.100.103]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 1A2F8A58C69; Wed, 30 Jun 2010 17:01:47 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=U5B40nlwyCrvVMfKahRJoBN5/OcUicgtHAoFM1V31VILS/cfbAmSclUTf0LTIJsQy 3rBzCz7uetICryyt0tbNQ== Message-ID: <4C2B07F5.6030801@delphij.net> Date: Wed, 30 Jun 2010 02:01:41 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100629 Thunderbird/3.0.5 ThunderBrowse/3.3 MIME-Version: 1.0 To: FreeBSD-Hackers X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Supermicro BIOS's watchdog feature? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 09:01:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Is there anybody used the Supermicro's BIOS watchdog feature (reboot if no OS activities)? It seems that ICH10R's watchdog is supported by ichwd(4) but Supermicro BIOS needs some special treatments which is beyond what ichwd(4) and watchdogd(8) would do... Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMKwf0AAoJEATO+BI/yjfB+uYH/j9c0VKgq84HUufNztoLvsJ8 zYNaj9xV+mKDSxTEeQsQelqqUkmwfEF/ibF8N6sSUZ9IH1fOVZTxu/NdTQQ4Vf9c VZQB6gusBl3xL4/uYHubLwVLsZVYb6i/CiodFJ5h+5sv4rvQAy9thQARmyw+Lfpx ID3zAxrAkwoCCjABEEppRpEXxzchb/Bvs4g40d+15Rk+aDqEG8HGtsw5QgXN+eZ+ eu/hXg+Z+j9A+RiBYB93kA1+o85e6C7v4hybtnXIXctGHxklt82QiGYMz2x1c1Jp ZVbHfVqM+Kqdl7Cn2S3TCiBXR+zkaB9mwcDHXqu9iBgPxv5nrwZZPfmDhsC9QdM= =TcIK -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 10:50:39 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DA6E106566B for ; Wed, 30 Jun 2010 10:50:39 +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 83A748FC16 for ; Wed, 30 Jun 2010 10:50:38 +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 o5UAoR9K068539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jun 2010 13:50:27 +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.4/8.14.4) with ESMTP id o5UAoR8X061052; Wed, 30 Jun 2010 13:50:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o5UAoR8t061051; Wed, 30 Jun 2010 13:50:27 +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, 30 Jun 2010 13:50:27 +0300 From: Kostik Belousov To: "Sam Fourman Jr." Message-ID: <20100630105027.GJ13238@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WyG/i6Mg9for+jdq" Content-Disposition: inline In-Reply-To: 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.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, 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-hackers@freebsd.org Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 10:50:39 -0000 --WyG/i6Mg9for+jdq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 29, 2010 at 06:54:11PM -0500, Sam Fourman Jr. wrote: > Hello FreeBSD hackers. >=20 > Last Tuesday blizzard release World of Warcraft 3.3.5, and with this patch > World of warcraft stopped working in FreeBSD 8.1 amd64, it crashes > right after login. >=20 > details here: > http://bugs.winehq.org/show_bug.cgi?id=3D23323 >=20 > in the above thread a wine developer stated the problem is this: >=20 > WoW uses opcode 0xf1 (icebp) and expects to see a single step exception, > probably as a way to detect hardware debuggers. With the kernel change ic= ebp is > no longer raising a SIGTRAP since it doesn't set any dr6 bits, so WoW doe= sn't > get its exception. >=20 > Linux fixed this with this kernel patch > https://bugzilla.kernel.org/show_bug.cgi?id=3D16315 >=20 >=20 > I have been playing World of Warcraft on FreeBSD amd64 since December of = 2009 > using the beta Nvidia 64bit drivers and this wine how-to >=20 > http://wiki.freebsd.org/Wine#head-6963d527c173e57b1567e881305b544d33435b6d >=20 > I can verify that on PCBSD 8.1 RC1 32bit World of warcraft works post 3.3= .5 > so far as I can tell it is only broken on amd64. >=20 > Would someone be able to comment on weather a patch is indeed needed > on FreeBSD amd64? Which patch ? icebp generates the SIGTRAP on latest 8-stable, verified by the following trivival assembler program: .text .globl main main: .byte 0xf1 xorl %edi,%edi call exit --WyG/i6Mg9for+jdq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwrIXIACgkQC3+MBN1Mb4gUHQCg2scrt9MHBfB4keWean5Dw/al WL4AmwTpWUSSTpl1qZ9jq2J6VXokhrOi =MPTd -----END PGP SIGNATURE----- --WyG/i6Mg9for+jdq-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 13:57:25 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9174106564A for ; Wed, 30 Jun 2010 13:57:25 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id C66B08FC13 for ; Wed, 30 Jun 2010 13:57:25 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o5UDvE4Q030263 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 30 Jun 2010 06:57:25 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4C2B4D35.8060903@feral.com> Date: Wed, 30 Jun 2010 06:57:09 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4C2B07F5.6030801@delphij.net> In-Reply-To: <4C2B07F5.6030801@delphij.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Wed, 30 Jun 2010 06:57:25 -0700 (PDT) Subject: Re: Supermicro BIOS's watchdog feature? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 13:57:26 -0000 On 6/30/2010 2:01 AM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > Is there anybody used the Supermicro's BIOS watchdog feature (reboot if > no OS activities)? > > It seems that ICH10R's watchdog is supported by ichwd(4) but Supermicro > BIOS needs some special treatments which is beyond what ichwd(4) and > watchdogd(8) would do... > > You're talking about the TCO stuff, which is actually present in ICH5 (I think) onward. Hmm. We use this at Panasas for at least one class of machines and it seems to work fine for those SuperMicro BIOS'. What do mean "special" treatment? From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 15:43:42 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E36C2106566B for ; Wed, 30 Jun 2010 15:43:42 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9AF478FC14 for ; Wed, 30 Jun 2010 15:43:42 +0000 (UTC) Received: by gwj16 with SMTP id 16so561352gwj.13 for ; Wed, 30 Jun 2010 08:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YfzHbb7k3gdONxOSSPqCYz/55GKx1pIP+Y3KNIorklg=; b=F70TfS62F+pOOh/F1Z2hjmbKGRHYKiMlxWQpYy2jnMDPCzHelejSxEnWLlgwl9wx9a m7ERLS99mpOXzR/Ofp0psHS8/3dzyVSlNTcrWUMq+wV0SKevV1FURqN1cp0CIuBhKnAh lrF47naLVYKA1I3gknGs+qm0KGrzCNzpzqNnY= 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=iTLbucruLk9ufj58c5LRJT28sCUyV/RnV+/X7hO45JNjQCXk2DOMS/Fb/+PMNPDCC0 pRZZva/7e/kLA+NhOTX739QGXOjBK/HC/4sYr3K6pJbSzwCb2BhgaxhEh46VlZjUKBFo R+skLA1eocS4hNltpjKP4MgotvbLj+7bHK2t0= MIME-Version: 1.0 Received: by 10.229.250.78 with SMTP id mn14mr5157436qcb.16.1277912613584; Wed, 30 Jun 2010 08:43:33 -0700 (PDT) Received: by 10.229.41.203 with HTTP; Wed, 30 Jun 2010 08:43:33 -0700 (PDT) In-Reply-To: <20100630105027.GJ13238@deviant.kiev.zoral.com.ua> References: <20100630105027.GJ13238@deviant.kiev.zoral.com.ua> Date: Wed, 30 Jun 2010 10:43:33 -0500 Message-ID: From: "Sam Fourman Jr." To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 15:43:43 -0000 > Which patch ? icebp generates the SIGTRAP on latest 8-stable, verified > by the following trivival assembler program: > =A0 =A0 =A0 =A0.text > =A0 =A0 =A0 =A0.globl =A0main > main: > =A0 =A0 =A0 =A0.byte =A0 0xf1 > =A0 =A0 =A0 =A0xorl =A0 =A0%edi,%edi > =A0 =A0 =A0 =A0call =A0 =A0exit > Thank you for your reply, I did not know enough assembly to test this I just assumed since it stopped working at the same time as it did on linux that it must be the same bug. I have updated the wine bug, with your information here: http://bugs.winehq.org/show_bug.cgi?id=3D23323#c118 Does anyone have any ideas as to what could be causing this? or is there anything else I can do to get more useful info to debug this? --=20 Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 16:26:23 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62B89106564A for ; Wed, 30 Jun 2010 16:26:23 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 19C978FC1C for ; Wed, 30 Jun 2010 16:26:22 +0000 (UTC) Received: by gwj16 with SMTP id 16so612380gwj.13 for ; Wed, 30 Jun 2010 09:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Kw/VcnlGggI3Hou2BNF5HYxMFZPQbIHBwvMuL/weLQc=; b=oE6pAF5boAp1dgRHBkFk9jOCD98a00A9vPD142RhQOFLRgRh2RvxAGXGY/M3WHx895 chLMEou7+QtNvlicuNNVUFXROrFUM4To71l4kFRS0CFfbKoa0S3eCiG/eq/9kOY/geOg Ap1JNFtsVsaR3yRpGIXoUWthUC5L2VqN4h+ow= 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=kZfNDwhUzLRMqvubHrVdyfyhnE2az5QoqHHf9nqwmBVVzYG1C+oLslvbsVebog9Xei +iWV2n1Y+tAVf/oSnU0DztAg6DnC86O8rUrfHy4rsg7QWwr9R+UVp9Xr7CvhW3kshhHO EGk3L7P+1hywH1opNO6lppLXK49oohNMTVWvg= MIME-Version: 1.0 Received: by 10.229.233.14 with SMTP id jw14mr5237504qcb.180.1277915178794; Wed, 30 Jun 2010 09:26:18 -0700 (PDT) Received: by 10.229.221.83 with HTTP; Wed, 30 Jun 2010 09:26:17 -0700 (PDT) In-Reply-To: References: <20100630105027.GJ13238@deviant.kiev.zoral.com.ua> Date: Wed, 30 Jun 2010 09:26:17 -0700 Message-ID: From: Garrett Cooper To: "Sam Fourman Jr." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 16:26:23 -0000 On Wed, Jun 30, 2010 at 8:43 AM, Sam Fourman Jr. wrote= : >> Which patch ? icebp generates the SIGTRAP on latest 8-stable, verified >> by the following trivival assembler program: >> =A0 =A0 =A0 =A0.text >> =A0 =A0 =A0 =A0.globl =A0main >> main: >> =A0 =A0 =A0 =A0.byte =A0 0xf1 >> =A0 =A0 =A0 =A0xorl =A0 =A0%edi,%edi >> =A0 =A0 =A0 =A0call =A0 =A0exit >> > > Thank you for your reply, I did not know enough assembly to test this > I just assumed since it stopped working at the same time as it did on > linux that it must be the same bug. > I have updated the wine bug, with your information here: > > http://bugs.winehq.org/show_bug.cgi?id=3D23323#c118 > > Does anyone have any ideas as to what could be causing this? > or is there anything else I can do to get more useful info to debug this? Noting how things typically go, WoW crashing is most likely a symptom of another underlying issue that needs to be triaged that might exist within Wine. I'd check with the wine list to see if there is anyone can establish a process for diagnosing the problem so that the issue can be properly characterized and resolved. HTH, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 17:01:27 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14994106566C for ; Wed, 30 Jun 2010 17:01:27 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id C96EC8FC23 for ; Wed, 30 Jun 2010 17:01:26 +0000 (UTC) Received: by gxk7 with SMTP id 7so694563gxk.13 for ; Wed, 30 Jun 2010 10:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=B7k33WTLstFl+5yrkWpQU0RnFPmOO5jP12l273zoSpI=; b=AVCYrjG5fXMipn+0r0ZAoB7B/2ibA6+vjrdWFPqnSeyFLaAof94gyREJZwqKDwCmrA 7Jzln42B7MjvyWfXzG+KO8617GYo4r5hm+U2ri9yIqBfgbFT/zx797VkCMGvcsniREzz b+7J4GGb1npCnpK4oqI0mEdPi41QUSo1InrCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Twly8b9s1dgKSr2HOK2o7Cmm67UdnM95s8aR7q+46B8IXx1qoZx9GN0BdI46V5B8NT G4YN1Pxsr8W+SBFf5FTeO82u7mCT6ba144PPWh7OLeSlOm8kf+SXavxmyvGfPUcXr73m psnFAifEy14usdOi118fsohhMU9Lhz6gXbjp0= MIME-Version: 1.0 Received: by 10.229.245.68 with SMTP id lt4mr5208499qcb.71.1277917282007; Wed, 30 Jun 2010 10:01:22 -0700 (PDT) Received: by 10.229.221.83 with HTTP; Wed, 30 Jun 2010 10:01:21 -0700 (PDT) Date: Wed, 30 Jun 2010 10:01:21 -0700 Message-ID: From: Garrett Cooper To: FreeBSD-Hackers Content-Type: text/plain; charset=ISO-8859-1 Subject: Non-POSIX compliant pmake with secondary expansion? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 17:01:27 -0000 Hi guys, I currently set: .POSIX= In a Makefile thinking that it would enable only POSIX functionality, and was fidgeting around with the Makefile trying to get it to work. In short, I used secondary expansion, it worked, then compared the output from gmake and it failed (because they have the .SECONDEXPANSION keyword). POSIX doesn't mention secondary expansion, so obviously it's not a POSIX feature. So I was wondering if secondary expansion is enabled by default with .POSIX instead of being disabled like it should on pmake? Thanks, -Garrett $ cat test_Makefile .POSIX= TARGETS= all: $$(TARGETS) TARGETS+= idontexist idontexist: @echo $@ $ make -f test_Makefile all idontexist $ gmake -f test_Makefile gmake: *** No rule to make target `$(TARGETS)', needed by `all'. Stop. $ uname -a FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r206173M: Mon Apr 26 22:45:06 PDT 2010 root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA.ata amd64 From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 18:23:29 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37BA41065677 for ; Wed, 30 Jun 2010 18:23:29 +0000 (UTC) (envelope-from andrey.zonov@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B4EF78FC1D for ; Wed, 30 Jun 2010 18:23:28 +0000 (UTC) Received: by bwz12 with SMTP id 12so634399bwz.13 for ; Wed, 30 Jun 2010 11:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=syK9YLz2F01T/ZNylOmvPZjlpgpYN16Nz7+OJT+HTuE=; b=vAuPhcEZonP8Rbs35wiveiwMh+8nd4aTWE/UQfkfH47o+dd8bGckoNMFEIYplTrUfp Ggnh5jD8lO3dmzLSG8G66zez6qaxsT869J4sABdNrxS+UjHr9Na/b+YNLgkFBjL4dKm/ cwL621bE7+a0hyxnikFFyUjFQadHYDTqGQCn0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=MnRJmK6ToYaVZoeqi6pkzQ1t8AyMoHHv9vzwGG8O9JpsL/BZE23SFmn3juYMuuMa5M wDRzNtBQPMn4/j2eW+2QM9T+ixwdq4xXyTNE+0rrPR2hS0ottAkMx8D0X1GEhwRHMdz0 HWM2uo94m7P0nG8/1L0B/3xpxwRA6Q2nqo+vk= Received: by 10.204.83.103 with SMTP id e39mr6489854bkl.107.1277922199538; Wed, 30 Jun 2010 11:23:19 -0700 (PDT) Received: from [10.254.254.77] (ppp79-139-207-225.pppoe.spdop.ru [79.139.207.225]) by mx.google.com with ESMTPS id bk5sm8395895bkb.22.2010.06.30.11.23.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 30 Jun 2010 11:23:18 -0700 (PDT) Message-ID: <4C2B8B95.4010908@gmail.com> Date: Wed, 30 Jun 2010 22:23:17 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <4C2AE37C.5060000@gmail.com> <4C2AF285.1090506@yandex.ru> In-Reply-To: <4C2AF285.1090506@yandex.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: How change process flags from userland? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 18:23:29 -0000 Yes, but I want change process flags without kernel hacking/loading modules or modification applications. Andrey V. Elsukov ÐÉÛÅÔ: > On 30.06.2010 10:26, Andrey Zonov wrote: > >> Hi, >> >> I want to set P_PROTECTED flag for some daemons after it start, without >> patching application and kernel. >> It possible? >> >> > > Did you try sysutils/scprotect? > > -- Andrey Zonov From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 21:22:09 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96E3F1065700 for ; Wed, 30 Jun 2010 21:22:09 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4EE638FC22 for ; Wed, 30 Jun 2010 21:22:08 +0000 (UTC) Received: by gwj16 with SMTP id 16so869078gwj.13 for ; Wed, 30 Jun 2010 14:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rAXnIRHYe+uErhS5RxenjS7J9pwe+ZrkWSVl0JfjHME=; b=QuMRr0b6c44gCzRYllqdaN7io2mRO1UNUvjY88MR/0SJXT6TKVSRj9FWbTeErWCVPu FXItP1kIG3fvT9nNsZyubZSOt39Bt26+LTg1TTV3CyVe+pYmdSFVNXEjw8YpXvCBCiD2 fR/oHlW1tYDqzlqQRBnrttijKOnGbswfBQB9E= 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=N2pslCWwJBDLmMc15pUp8Qdli5AusONOoIs01xnWLTWevHrxv62DpoUNqk7Bq+gMRG TITAUwZEGnTY2OwMf7QlDy2PRKOn9f63Sos0nc8CX4S4kSWOp2YI+zG/gh/flSNgOrtv lxdV+ftdtgU+dAWJl94MpOKKHg8Qie8k3HtPw= MIME-Version: 1.0 Received: by 10.229.221.72 with SMTP id ib8mr5511330qcb.0.1277932922264; Wed, 30 Jun 2010 14:22:02 -0700 (PDT) Received: by 10.229.41.203 with HTTP; Wed, 30 Jun 2010 14:22:02 -0700 (PDT) In-Reply-To: References: <20100630105027.GJ13238@deviant.kiev.zoral.com.ua> Date: Wed, 30 Jun 2010 16:22:02 -0500 Message-ID: From: "Sam Fourman Jr." To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 21:22:09 -0000 On Wed, Jun 30, 2010 at 11:26 AM, Garrett Cooper wrote= : > On Wed, Jun 30, 2010 at 8:43 AM, Sam Fourman Jr. wro= te: >>> Which patch ? icebp generates the SIGTRAP on latest 8-stable, verified >>> by the following trivival assembler program: >>> =A0 =A0 =A0 =A0.text >>> =A0 =A0 =A0 =A0.globl =A0main >>> main: >>> =A0 =A0 =A0 =A0.byte =A0 0xf1 >>> =A0 =A0 =A0 =A0xorl =A0 =A0%edi,%edi >>> =A0 =A0 =A0 =A0call =A0 =A0exit >>> >> Here is the C program that the linux people used as a test case. *************************************************************** #include #include void trap_handler(int sig) { printf("trapped\n"); } /* * icebp * ret */ char icebp_func[] =3D "\xf1\xc3"; typedef void (*icebp_call)(void); int main(int argc, char **argv) { icebp_call func =3D (icebp_call)icebp_func; signal(SIGTRAP, trap_handler); func(); return 0; } *************************************************************** My question is why doe the above code not print trapped on amd64? FreeBSD 8.1 i386 this code prints "Trapped" as intended FreeBSD 8.1 amd64 this code prints "Segmentation fault: 11" FreeBSD 8.1 amd64 chrooted to 32bit prints "Segmentation fault" I did verify that from Linux amd64 this works and prints "Trapped" uname -a Linux workstation 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 08:03:28 UTC 2010 x86_64 GNU/Linux Thank you much for everyones help Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 21:42:54 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A869106566C for ; Wed, 30 Jun 2010 21:42:54 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B03718FC36 for ; Wed, 30 Jun 2010 21:42:53 +0000 (UTC) Received: by vws6 with SMTP id 6so467599vws.13 for ; Wed, 30 Jun 2010 14:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=o6EZVDBdfJNqSKhJW6HYbHhAcH06iE1Qu3Ia++N7pTg=; b=ho9rCqWV//t6AYcbmR0jQF6WFEx7ObfFkxx+mKlBBSXyExi4DdGIyENn6e79w0Eiac /T0+f/vJLKtyo6I6uugB3B0NTW7af9Ds854ERIVnzYU7oZ3wRFzFogHvby7CgkOTfLZB TInNJF0mkhM2BcjGng0nF0tEKzGS8iHn+X7Rc= 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=abLsY1D7GfPjbz0eXOS5ZmtErRZNdbs7xx3gv+Lwm/tmpoVC3+BsMppRdSjKNI0jhX oYhf3VqugqqV86rDPztjOvw+5dIyIDuw8M4kczTnOjhAi2Ja7Z8BcaG77lnRnRTu8zoL PX1rEWPLxu0VAIkWwk0RkYMgCUsRHejvQLqN8= MIME-Version: 1.0 Received: by 10.229.96.209 with SMTP id i17mr5492676qcn.293.1277934167236; Wed, 30 Jun 2010 14:42:47 -0700 (PDT) Received: by 10.229.221.83 with HTTP; Wed, 30 Jun 2010 14:42:47 -0700 (PDT) In-Reply-To: References: <20100630105027.GJ13238@deviant.kiev.zoral.com.ua> Date: Wed, 30 Jun 2010 14:42:47 -0700 Message-ID: From: Garrett Cooper To: "Sam Fourman Jr." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 21:42:54 -0000 On Wed, Jun 30, 2010 at 2:22 PM, Sam Fourman Jr. wrote= : > On Wed, Jun 30, 2010 at 11:26 AM, Garrett Cooper wro= te: >> On Wed, Jun 30, 2010 at 8:43 AM, Sam Fourman Jr. wr= ote: >>>> Which patch ? icebp generates the SIGTRAP on latest 8-stable, verified >>>> by the following trivival assembler program: >>>> =A0 =A0 =A0 =A0.text >>>> =A0 =A0 =A0 =A0.globl =A0main >>>> main: >>>> =A0 =A0 =A0 =A0.byte =A0 0xf1 >>>> =A0 =A0 =A0 =A0xorl =A0 =A0%edi,%edi >>>> =A0 =A0 =A0 =A0call =A0 =A0exit >>>> >>> > > Here is the C program that the linux people used as a test case. > > *************************************************************** > #include > #include > > > > void trap_handler(int sig) > { > =A0 =A0 =A0 =A0printf("trapped\n"); > } > > > /* > =A0* icebp > =A0* ret > =A0*/ > char icebp_func[] =3D "\xf1\xc3"; > typedef void (*icebp_call)(void); > > int main(int argc, char **argv) > { > =A0 =A0 =A0 =A0icebp_call func =3D (icebp_call)icebp_func; > > =A0 =A0 =A0 =A0signal(SIGTRAP, trap_handler); > > =A0 =A0 =A0 =A0func(); > > =A0 =A0 =A0 =A0return 0; > } > > *************************************************************** > > My question is why doe the above code not print trapped on amd64? > > FreeBSD 8.1 i386 this code prints "Trapped" as intended > FreeBSD 8.1 amd64 this code prints "Segmentation fault: 11" > FreeBSD 8.1 amd64 chrooted to 32bit prints "Segmentation fault" > > I did verify that from Linux amd64 this works and prints "Trapped" > uname -a > Linux workstation 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 08:03:28 > UTC 2010 x86_64 GNU/Linux Hmmm... I've seen similar whackiness with Linux and signals, but that's a different thing entirely (it was rt signals vs non-rt signals). Here's a modified version of the testcase (wanted to make sure that things were sane): $ cat test_sigtrap.c #include #include #include int trapped =3D 0; void trap_handler(int sig) { trapped =3D 1; } /* * icebp * ret */ char icebp_func[] =3D "\xf1\xc3"; typedef void (*icebp_call)(void); int main(int argc, char **argv) { icebp_call func =3D (icebp_call)icebp_func; if (signal(SIGTRAP, trap_handler) =3D=3D SIG_ERR) err(1, "signal"); func(); if (trapped) printf("Admiral Ackbar: it's a trap!\n"); return 0; } Ran it and it segfaulted on CURRENT: $ sudo truss ./test_sigtrap __sysctl(0x7fffffffe590,0x2,0x7fffffffe5ac,0x7fffffffe5a0,0x0,0x0) =3D 0 (0= x0) mmap(0x0,672,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) =3D 34365169664 (0x80052= e000) munmap(0x80052e000,672) =3D 0 (0x0) __sysctl(0x7fffffffe600,0x2,0x800638848,0x7fffffffe5f8,0x0,0x0) =3D 0 (0x0) mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =3D 34365169664 (0x80052e000) issetugid(0x80052f015,0x8005294e4,0x800644f50,0x800644f20,0x5b31,0x0) =3D 0= (0x0) open("/etc/libmap.conf",O_RDONLY,0666) ERR#2 'No such file or directory' open("/var/run/ld-elf.so.hints",O_RDONLY,057) =3D 2 (0x2) read(2,"Ehnt\^A\0\0\0\M^@\0\0\0}\0\0\0\0"...,128) =3D 128 (0x80) lseek(2,0x80,SEEK_SET) =3D 128 (0x80) read(2,"/lib:/usr/lib:/usr/lib/compat:/u"...,125) =3D 125 (0x7d) close(2) =3D 0 (0x0) access("/lib/libc.so.7",0) =3D 0 (0x0) open("/lib/libc.so.7",O_RDONLY,030703440) =3D 2 (0x2) fstat(2,{ mode=3D-r--r--r-- ,inode=3D353312,size=3D1192760,blksize=3D16384 = }) =3D 0 (0x0) pread(0x2,0x800637700,0x1000,0x0,0x101010101010101,0x8080808080808080) =3D 4096 (0x1000) mmap(0x0,2318336,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) =3D 34366312448 (0x800645000) mmap(0x800645000,1028096,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCO= RE,2,0x0) =3D 34366312448 (0x800645000) mmap(0x80083f000,135168,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,2,0xfa00= 0) =3D 34368385024 (0x80083f000) mprotect(0x800860000,110592,PROT_READ|PROT_WRITE) =3D 0 (0x0) close(2) =3D 0 (0x0) sysarch(0x81,0x7fffffffe680,0x800533088,0x0,0xffffffffffcea590,0x8080808080= 808080) =3D 0 (0x0) mmap(0x0,176,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) =3D 34365202432 (0x80053= 6000) munmap(0x800536000,176) =3D 0 (0x0) mmap(0x0,44064,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) =3D 34365202432 (0x800= 536000) munmap(0x800536000,44064) =3D 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM= |SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXF= SZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) __sysctl(0x7fffffffe620,0x2,0x800866d20,0x7fffffffe618,0x0,0x0) =3D 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM= |SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXF= SZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) sigaction(SIGTRAP,{ 0x4005f0 SA_RESTART ss_t },{ SIG_DFL 0x0 ss_t }) =3D 0 = (0x0) SIGNAL 11 (SIGSEGV) process exit, rval =3D 0 Also, is there perhaps a sideeffect dealing with the size of a char on FreeBSD vs Linux? That's a pretty badass way to load assembler instructions on the stack :). Thanks! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 21:51:33 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BED8106566B for ; Wed, 30 Jun 2010 21:51:33 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 4EDA48FC1A for ; Wed, 30 Jun 2010 21:51:33 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 519A11FFC34; Wed, 30 Jun 2010 21:51:32 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id CBCB5844F3; Wed, 30 Jun 2010 23:49:20 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Matthew Jacob References: <4C2B07F5.6030801@delphij.net> <4C2B4D35.8060903@feral.com> Date: Wed, 30 Jun 2010 23:49:20 +0200 In-Reply-To: <4C2B4D35.8060903@feral.com> (Matthew Jacob's message of "Wed, 30 Jun 2010 06:57:09 -0700") Message-ID: <86lj9wmbrz.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Supermicro BIOS's watchdog feature? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 21:51:33 -0000 Matthew Jacob writes: > Xin LI writes: > > It seems that ICH10R's watchdog is supported by ichwd(4) but > > Supermicro BIOS needs some special treatments which is beyond what > > ichwd(4) and watchdogd(8) would do... > What do mean "special" treatment? The watchdog timer can be disabled in hardware (by pulling the speaker pin high during boot, IIRC). Even if it is enabled, it can be caught and ignored by the SMM firmware. Some BIOSes have options to enable or disable the watchdog timer, which I assume means that they flip a bit that tells the firmware to either catch it or pass it through. Unfortunately, although it is possible for the ichwd driver to detect programatically (by checking an MSR) if the watchdog timer is disabled in hardware, it is not possible to determine whether it is disabled in firmware. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 21:52:53 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3A67106566B for ; Wed, 30 Jun 2010 21:52:52 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (outv.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id D56B98FC2A for ; Wed, 30 Jun 2010 21:52:52 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o5ULqq1m010708; Wed, 30 Jun 2010 14:52:52 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id D31172D6015; Wed, 30 Jun 2010 14:52:50 -0700 (PDT) Message-ID: <4C2BBCC9.7000605@elischer.org> Date: Wed, 30 Jun 2010 14:53:13 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Andrey Zonov References: <4C2AE37C.5060000@gmail.com> <4C2AF285.1090506@yandex.ru> <4C2B8B95.4010908@gmail.com> In-Reply-To: <4C2B8B95.4010908@gmail.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-hackers@freebsd.org, "Andrey V. Elsukov" Subject: Re: How change process flags from userland? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 21:52:53 -0000 On 6/30/10 11:23 AM, Andrey Zonov wrote: > Yes, but I want change process flags without kernel hacking/loading > modules or modification applications. you are going to have to do one of those. The only alternative is that if you have root you can modify a processe's flags using gdb and /dev/kmem. you could use a program to do it specially if you have root, but if that's not what you want then you will need to add a syscall to do what you want as far as I can see. > > Andrey V. Elsukov ÐÉÛÅÔ: >> On 30.06.2010 10:26, Andrey Zonov wrote: >>> Hi, >>> >>> I want to set P_PROTECTED flag for some daemons after it start, without >>> patching application and kernel. >>> It possible? >>> >> >> Did you try sysutils/scprotect? >> > From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 22:03:53 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 799D11065675 for ; Wed, 30 Jun 2010 22:03:53 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 237B38FC1C for ; Wed, 30 Jun 2010 22:03:53 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id E75F3A59010; Thu, 1 Jul 2010 06:03:51 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id eycsu9u5+i0X; Thu, 1 Jul 2010 06:03:45 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id EAA10A58986; Thu, 1 Jul 2010 06:03:43 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=w6qx6NfjmP6Uez690Cdfwbsz+8hQpxKkTFjKaJHH9xIgIYh+/y5JbbVoPJ3rItWj+ gcdpX82oJW6+5VjkLpK2Q== Message-ID: <4C2BBF3C.4070503@delphij.net> Date: Wed, 30 Jun 2010 15:03:40 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100629 Thunderbird/3.0.5 ThunderBrowse/3.3 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4C2B07F5.6030801@delphij.net> <4C2B4D35.8060903@feral.com> <86lj9wmbrz.fsf@ds4.des.no> In-Reply-To: <86lj9wmbrz.fsf@ds4.des.no> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, Matthew Jacob Subject: Re: Supermicro BIOS's watchdog feature? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 22:03:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/06/30 14:49, Dag-Erling Smørgrav wrote: > Matthew Jacob writes: >> Xin LI writes: >>> It seems that ICH10R's watchdog is supported by ichwd(4) but >>> Supermicro BIOS needs some special treatments which is beyond what >>> ichwd(4) and watchdogd(8) would do... >> What do mean "special" treatment? > > The watchdog timer can be disabled in hardware (by pulling the speaker > pin high during boot, IIRC). Even if it is enabled, it can be caught > and ignored by the SMM firmware. Some BIOSes have options to enable or > disable the watchdog timer, which I assume means that they flip a bit > that tells the firmware to either catch it or pass it through. > > Unfortunately, although it is possible for the ichwd driver to detect > programatically (by checking an MSR) if the watchdog timer is disabled > in hardware, it is not possible to determine whether it is disabled in > firmware. Hmm... Sorry I think I didn't described the behavior accurately. Currently if I enable the "Watch Dog" option in BIOS, the system reboots after ~5 mins regardless whether I have ichwd(4) and watchdogd(8) loaded. Looking at the boot -v output, ichwd would disable the watchdog and watchdogd would enable it, pat it as expected, but this won't stop the system from rebooting by the watchdog. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMK788AAoJEATO+BI/yjfBPHkH/jWIZEX9/tmL50AgXzkfEEXU zNn+d2CAGA/+6wUt73aizKq1dk0eIz5ze9V+RR59cjJH4ftXLg2Tn34Ed2OYNTZZ JxFP7go4RIO1P5a3WIM6A8MVykUCIv+JhfXR3yG8Fy0h9DbmL2zwLPlqYPLBAXOK y+2DKYXqmA94qetPmrrm8b4WDRD9a7dwH26E+D8AslPJcABynjrdv0Ou8MLKC3g7 K+3YcgaCP2dowyy0gJzfNi2WTJyPmEtLsmFGzw14enP5tpDNU0t6yR4rkPbHkQSM 6BRF7gwZiAQoa4Az/S72RvjVR+OXehJGNNJLM6YRTH4fB2QiZ3YdmJ3WyeUE/TU= =EA7X -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 22:04:27 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1120A1065788 for ; Wed, 30 Jun 2010 22:04:27 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B65C88FC15 for ; Wed, 30 Jun 2010 22:04:26 +0000 (UTC) Received: by vws6 with SMTP id 6so494159vws.13 for ; Wed, 30 Jun 2010 15:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ZSmIc0Y5bADGGChA/9bOrIZ1w3xF4aX35vzOqkcIriw=; b=AItP1qHlVylcmEqi4YKoVAzj0wFubjO6Zz/9uPTrtt4LlnhuYvr3FORt3psxC3fNXM AoRjQ2aGlqd97k6j1MKJU+DcmTKwVuFdikTREaG06mtcQJYpT5TpR4JombhzeGG1Ec55 TWWCLqqsiNY8pv8cYOpQchBi9BVTps2WsIkko= 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; b=Kf+qg3l8++oMNMcIX4w2uD4pjl5YynCyqE4NT8ud8imzXsp9Tsho18tXt1X2djtiUI K7Aq3Ge+MC8XrApG8EKe26VfGA6FR4ZwZBCtZ4jl1/z/x+fq9tPnoA9dbVuaLl9baqLe 2uv8V+B3EeLWo3hrYkCbqZNmVoymPcwqmPomc= MIME-Version: 1.0 Received: by 10.229.187.213 with SMTP id cx21mr5546539qcb.120.1277935460137; Wed, 30 Jun 2010 15:04:20 -0700 (PDT) Received: by 10.229.41.203 with HTTP; Wed, 30 Jun 2010 15:04:20 -0700 (PDT) In-Reply-To: References: <20100630105027.GJ13238@deviant.kiev.zoral.com.ua> Date: Wed, 30 Jun 2010 17:04:20 -0500 Message-ID: From: "Sam Fourman Jr." To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 22:04:27 -0000 > Also, is there perhaps a sideeffect dealing with the size of a char on > FreeBSD vs Linux? > > That's a pretty badass way to load assembler instructions on the stack :). > > Thanks! > -Garrett Garrett, So is this in-fact a FreeBSD kernel bug on amd64? if so, how hard would it be to patch it so it worked? becasue I bet if we fix this World of Warcraft will work again in wine. -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 22:22:08 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B740106564A for ; Wed, 30 Jun 2010 22:22:08 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C162A8FC13 for ; Wed, 30 Jun 2010 22:22:07 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id B3C281FFC33; Wed, 30 Jun 2010 22:22:06 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 314AC844E4; Thu, 1 Jul 2010 00:19:55 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: d@delphij.net References: <4C2B07F5.6030801@delphij.net> <4C2B4D35.8060903@feral.com> <86lj9wmbrz.fsf@ds4.des.no> <4C2BBF3C.4070503@delphij.net> Date: Thu, 01 Jul 2010 00:19:54 +0200 In-Reply-To: <4C2BBF3C.4070503@delphij.net> (Xin LI's message of "Wed, 30 Jun 2010 15:03:40 -0700") Message-ID: <86hbkkmad1.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Matthew Jacob Subject: Re: Supermicro BIOS's watchdog feature? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 22:22:08 -0000 Xin LI writes: > Hmm... Sorry I think I didn't described the behavior accurately. > Currently if I enable the "Watch Dog" option in BIOS, the system > reboots after ~5 mins regardless whether I have ichwd(4) and > watchdogd(8) loaded. Perhaps the motherboard has additional watchdog hardware? If you disable the watchdog in BIOS, does ichwd still work? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 22:27:28 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1891E106564A for ; Wed, 30 Jun 2010 22:27:28 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id C2A958FC17 for ; Wed, 30 Jun 2010 22:27:27 +0000 (UTC) Received: by qwg5 with SMTP id 5so558648qwg.13 for ; Wed, 30 Jun 2010 15:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=oVgPI6Jza3FQsNpTpkD8GGKFaEBwBFNJtEBxtxmf2c4=; b=j3Aq+5bwo0mU7QlOFz+zQtHL3CtXFkNVBagR7ZhTeIPTXrZnAzWAOm27p2Oyh+tqIi rBPt5FxFj+255CC4T5c05LNBdfADyyaZzgEaD3C6QTu3YcLkaKEflA38ieu/f48ZypYR 5Ezo5SZVZCrU5uTJgrSxjWPgz8iu+Qpp1ITbk= 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; b=CJeTMZQ/v1VmO2jWrZZ2auT7HH1hCSyqqnYPLmE4GRxZuZh5A2ixbnJGGlbxZTm9YR EtD5CEwB2XUFZzp6Km94KFUVCsUNMJJp3DofvyIklnnMA21gl02lpALQbISm2skXaQLi vMvNZGjYEX/HngNrEDNHzyVxXxTZRy7Bf7DjY= MIME-Version: 1.0 Received: by 10.224.113.91 with SMTP id z27mr6577512qap.142.1277936842567; Wed, 30 Jun 2010 15:27:22 -0700 (PDT) Received: by 10.229.41.203 with HTTP; Wed, 30 Jun 2010 15:27:22 -0700 (PDT) In-Reply-To: References: <20100630105027.GJ13238@deviant.kiev.zoral.com.ua> Date: Wed, 30 Jun 2010 17:27:22 -0500 Message-ID: From: "Sam Fourman Jr." To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 22:27:28 -0000 > Also, is there perhaps a sideeffect dealing with the size of a char on > FreeBSD vs Linux? > > That's a pretty badass way to load assembler instructions on the stack :). > > Thanks! > -Garrett For what it is worth I ran the test code on one of my NetBSD amd64 Xen Dom0 servers it generated "trapped" as expected # gcc test.c -o test # ./test trapped # uname -a NetBSD 5.99.27 NetBSD 5.99.27 (XEN3_DOM0) #0: Tue Apr 20 21:04:16 CDT 2010 root@:/usr/objdir/sys/arch/amd64/compile/XEN3_DOM0 amd64 -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 23:03:36 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 364ED1065674 for ; Wed, 30 Jun 2010 23:03:36 +0000 (UTC) (envelope-from uffe@uffe.org) Received: from mail.starion.dk (mx0.starion.dk [83.95.112.88]) by mx1.freebsd.org (Postfix) with SMTP id B5CC38FC19 for ; Wed, 30 Jun 2010 23:03:35 +0000 (UTC) Received: (qmail 18488 invoked by uid 528); 30 Jun 2010 23:03:55 -0000 Received: from 10.7.7.247 ([10.7.7.247]) by mail.starion.dk ([192.168.0.100]) with ESMTP via TCP; 30 Jun 2010 23:03:55 -0000 References: <20100630105027.GJ13238@deviant.kiev.zoral.com.ua> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Uffe Jakobsen To: freebsd-hackers@freebsd.org Date: Thu, 01 Jul 2010 01:03:33 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 23:03:36 -0000 Garrett writes: >> Also, is there perhaps a sideeffect dealing with the size of a char on >> FreeBSD vs Linux? >> >> That's a pretty badass way to load assembler instructions on the stack :). >> I may be totally wrong here - but could it be NX/XD/XN protection ? /Uffe From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 23:24:05 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC6461065673 for ; Wed, 30 Jun 2010 23:24:05 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7D7E38FC16 for ; Wed, 30 Jun 2010 23:24:05 +0000 (UTC) Received: by vws6 with SMTP id 6so590760vws.13 for ; Wed, 30 Jun 2010 16:23:57 -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=7MxOz/Var6Xph7Y8b3qhbrCD7iT7REMBI90uDLqfskE=; b=n+Y2RfUMI3ejc7hsGE8G+9fKoEc8NWdHQ2UyJUd4F+HWVyQm85LUszRWVbPktLacrD rpl3icBDXM+opnhF5t+QmMhsyOJCiVFxwKH2vn5b7Emd9RR6bh/rpltLUalGO8tWRtQz a9vm8YBFQllUcnMwKSdPkLlYHLADtdg7+/es8= 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=DnJ9yxdbZiJ5DkRQO2jJnHoAiPUybTkbWz3sk7DTaXtrAz4kYxn5GqwB0F2OEblooP O7jWpMEl5jWy/d7JZhZOvyrKf0G5RB58XwXX6gP6csTExXbfMhkzLoAOtdKUY15eHWu7 6GJPWvodZiyoVP2oJvl+rSGnkldykf1ZtK4RI= Received: by 10.229.96.209 with SMTP id i17mr5561952qcn.293.1277940237553; Wed, 30 Jun 2010 16:23:57 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id t34sm47873907qcp.42.2010.06.30.16.23.56 (version=SSLv3 cipher=RC4-MD5); Wed, 30 Jun 2010 16:23:56 -0700 (PDT) Date: Wed, 30 Jun 2010 19:23:50 -0400 From: Alexander Kabaev To: Garrett Cooper Message-ID: <20100630192350.105e8303@kan.dnsalias.net> In-Reply-To: References: <20100630105027.GJ13238@deviant.kiev.zoral.com.ua> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/gPDZ6W8c_eB4jEADn4G1kSm"; protocol="application/pgp-signature" Cc: "Sam Fourman Jr." , Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 23:24:05 -0000 --Sig_/gPDZ6W8c_eB4jEADn4G1kSm Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On Wed, 30 Jun 2010 14:42:47 -0700 Garrett Cooper wrote: > On Wed, Jun 30, 2010 at 2:22 PM, Sam Fourman Jr. > wrote: > > On Wed, Jun 30, 2010 at 11:26 AM, Garrett Cooper > > wrote: > >> On Wed, Jun 30, 2010 at 8:43 AM, Sam Fourman Jr. > >> wrote: > >>>> Which patch ? icebp generates the SIGTRAP on latest 8-stable, > >>>> verified by the following trivival assembler program: > >>>> =9A =9A =9A =9A.text > >>>> =9A =9A =9A =9A.globl =9Amain > >>>> main: > >>>> =9A =9A =9A =9A.byte =9A 0xf1 > >>>> =9A =9A =9A =9Axorl =9A =9A%edi,%edi > >>>> =9A =9A =9A =9Acall =9A =9Aexit > >>>> > >>> > > > > Here is the C program that the linux people used as a test case. > > > > *************************************************************** > > #include > > #include > > > > > > > > void trap_handler(int sig) > > { > > =9A =9A =9A =9Aprintf("trapped\n"); > > } > > > > > > /* > > =9A* icebp > > =9A* ret > > =9A*/ > > char icebp_func[] =3D "\xf1\xc3"; > > typedef void (*icebp_call)(void); > > > > int main(int argc, char **argv) > > { > > =9A =9A =9A =9Aicebp_call func =3D (icebp_call)icebp_func; > > > > =9A =9A =9A =9Asignal(SIGTRAP, trap_handler); > > > > =9A =9A =9A =9Afunc(); > > > > =9A =9A =9A =9Areturn 0; > > } > > > > *************************************************************** > > > > My question is why doe the above code not print trapped on amd64? > > > > FreeBSD 8.1 i386 this code prints "Trapped" as intended > > FreeBSD 8.1 amd64 this code prints "Segmentation fault: 11" > > FreeBSD 8.1 amd64 chrooted to 32bit prints "Segmentation fault" > > > > I did verify that from Linux amd64 this works and prints "Trapped" > > uname -a > > Linux workstation 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 > > 08:03:28 UTC 2010 x86_64 GNU/Linux >=20 > Hmmm... I've seen similar whackiness with Linux and signals, but > that's a different thing entirely (it was rt signals vs non-rt > signals). >=20 > Here's a modified version of the testcase (wanted to make sure that > things were sane): >=20 > $ cat test_sigtrap.c > #include > #include > #include >=20 > int trapped =3D 0; >=20 > void trap_handler(int sig) > { > trapped =3D 1; > } >=20 >=20 > /* > * icebp > * ret > */ > char icebp_func[] =3D "\xf1\xc3"; > typedef void (*icebp_call)(void); >=20 > int main(int argc, char **argv) > { > icebp_call func =3D (icebp_call)icebp_func; >=20 > if (signal(SIGTRAP, trap_handler) =3D=3D SIG_ERR) > err(1, "signal"); >=20 > func(); >=20 > if (trapped) > printf("Admiral Ackbar: it's a trap!\n"); >=20 > return 0; > } >=20 > Ran it and it segfaulted on CURRENT: >=20 Now make icebp_func const and observe the program start working. The test case is broken as written, because icebp_func array is writable, so in ends up in a non-const part of .bss, which is not marked as executable and rightfully causes SIGSEGV when jumped to.=20 --=20 Alexander Kabaev --Sig_/gPDZ6W8c_eB4jEADn4G1kSm Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iD8DBQFMK9ILQ6z1jMm+XZYRAkTVAJ9p5UCJ3eXjCUcLR6qiLy2ilZ5JxgCgiPI6 691v+Jos2VTst3WIQcvHLu8= =vGhJ -----END PGP SIGNATURE----- --Sig_/gPDZ6W8c_eB4jEADn4G1kSm-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 23:35:16 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A0FA106566C for ; Wed, 30 Jun 2010 23:35:16 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1254A8FC17 for ; Wed, 30 Jun 2010 23:35:16 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 6BEC9A58203; Thu, 1 Jul 2010 07:35:14 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id LUerZTxI9WZb; Thu, 1 Jul 2010 07:35:05 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 1E1DEA57FDC; Thu, 1 Jul 2010 07:34:52 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=B2xr286gBl+JMc9/L6WOGiDJtwVOaBY2cpe74gH1/x8aakC57UPrmcfRIHqrTLZMa aFp07w3k0vhQmdgKhi99A== Message-ID: <4C2BD498.3090704@delphij.net> Date: Wed, 30 Jun 2010 16:34:48 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100629 Thunderbird/3.0.5 ThunderBrowse/3.3 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4C2B07F5.6030801@delphij.net> <4C2B4D35.8060903@feral.com> <86lj9wmbrz.fsf@ds4.des.no> <4C2BBF3C.4070503@delphij.net> <86hbkkmad1.fsf@ds4.des.no> In-Reply-To: <86hbkkmad1.fsf@ds4.des.no> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Matthew Jacob , d@delphij.net, freebsd-hackers@freebsd.org Subject: Re: Supermicro BIOS's watchdog feature? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 23:35:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/06/30 15:19, Dag-Erling Smørgrav wrote: > Xin LI writes: >> Hmm... Sorry I think I didn't described the behavior accurately. >> Currently if I enable the "Watch Dog" option in BIOS, the system >> reboots after ~5 mins regardless whether I have ichwd(4) and >> watchdogd(8) loaded. > > Perhaps the motherboard has additional watchdog hardware? If you > disable the watchdog in BIOS, does ichwd still work? If I kill -9 watchdogd the system do reset itself so I think ichwd(4) really works even if BIOS setting is 'Disabled' (but I'm not sure if this method is right? Looking at the code I think the answer is probably "Yes" though) Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMK9SYAAoJEATO+BI/yjfBUYIH/jPJX3kEZt7o9sia7+H21SBX xtuRZ+bz7q0dPKmdpHVPuWZNUB7mauFgtlZdUcu7gx1bKLb8XrOO7FuUmh6n8QXy MwzeCVnZCW8EbSthkOaJf7KnQjC6QebcRtSJr9buldYv7U5AW7YpzDyOwk7AhjOc YBK12GSkmz/b9FtURh6NECtzY3v5W8cquHGHhLMVFe1t7/gKF2KVOHE8MEKjGG8a dlG6JE4SJtFT7Y3utHZqHoDZkuI3SBdXY31PYFoUY31LSJ5cSkzA/3eYbB7l1WL6 BjhLAb1qeBwYyF3nzWYPtv/dtWs0dlxEtUGu2XFXr/vejCQ2VNdkGJN1FGkAjY4= =fvdq -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 23:44:17 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 973AE106566B for ; Wed, 30 Jun 2010 23:44:17 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4035B8FC18 for ; Wed, 30 Jun 2010 23:44:16 +0000 (UTC) Received: by vws6 with SMTP id 6so614599vws.13 for ; Wed, 30 Jun 2010 16:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ZVfkSi2XCzQperHisfGGztBM+HvbN74MkUDvf3oRpcA=; b=r42j7E0uVWN44b74m+MK/jodCJ4cnwy0XcQyS6XKZiQBr5HY/WcGrl4jo4tZ0UawWP UcdYx/RF4RpawrW4pvdyF1kjCfVad3Ny5QbxyyTnYS85C8U6mg7fbi23dKxewDQLOAKA fr8QAA7yWEmlVN/yS97nSnZ++WViOahH+nItQ= 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; b=TsTv/y3rufbebj+kUm/hnJ6PDV35W3vgcr2rSsFDaFrClHDJ4jOgDFWl3eXZTrj47E e825cLfa6V1dnzv01QoEpjcRSItHVT+RStReDK38y1bWBvFiDWSQbY0OLI3z/oeJkyTq B3mf8F7LVQlQfpZcddRx99WPyesE0erCc+o5E= MIME-Version: 1.0 Received: by 10.229.246.135 with SMTP id ly7mr5701588qcb.269.1277941449705; Wed, 30 Jun 2010 16:44:09 -0700 (PDT) Received: by 10.229.221.83 with HTTP; Wed, 30 Jun 2010 16:44:09 -0700 (PDT) In-Reply-To: References: <20100630105027.GJ13238@deviant.kiev.zoral.com.ua> Date: Wed, 30 Jun 2010 16:44:09 -0700 Message-ID: From: Garrett Cooper To: Uffe Jakobsen Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 23:44:17 -0000 On Wed, Jun 30, 2010 at 4:03 PM, Uffe Jakobsen wrote: > > Garrett writes: >>> >>> Also, is there perhaps a sideeffect dealing with the size of a char on >>> FreeBSD vs Linux? >>> >>> That's a pretty badass way to load assembler instructions on the stack >>> :). >>> > > I may be totally wrong here - but could it be NX/XD/XN protection ? Hmm... good catch. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 30 23:45:24 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0785106566C for ; Wed, 30 Jun 2010 23:45:24 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 603698FC24 for ; Wed, 30 Jun 2010 23:45:24 +0000 (UTC) Received: by vws6 with SMTP id 6so615910vws.13 for ; Wed, 30 Jun 2010 16:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9CvyZrWGM9oHoCXsk5CFxEW35St/SKkMu2rJOJjPwwQ=; b=HfgGNa5RLbfSszcnDBHPflNVShtpDxG+DqcmTv6OyBvPozUU0hC33f24qDtzec4e8z hKGXnXknuWqYa3aFCU2e1YfKpsmkDNGE5bUVDD+rMaEgzYxNDmmpmwHnzzFfoHJ47xp8 bENo6suCezULHpoT/A+PsSs2bvOX072VVocAU= 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=wFvKYCi1y5LDDzcdx/aTvl2crTMBvZPLmU6F92ODcRJpH/tPsrYnow6ZXOtOghWoFY WsGjK88r9BC+xKfF4GsFj6Ir//8HroGYh46Yn5KfOuOEredqgfQcoEJKPrzjVeVhalnM 4gNRWOl51lKBVy3gX8dgHFFIo0G3LGsI47mjE= MIME-Version: 1.0 Received: by 10.229.215.145 with SMTP id he17mr5557656qcb.95.1277941519039; Wed, 30 Jun 2010 16:45:19 -0700 (PDT) Received: by 10.229.221.83 with HTTP; Wed, 30 Jun 2010 16:45:18 -0700 (PDT) In-Reply-To: <20100630192350.105e8303@kan.dnsalias.net> References: <20100630105027.GJ13238@deviant.kiev.zoral.com.ua> <20100630192350.105e8303@kan.dnsalias.net> Date: Wed, 30 Jun 2010 16:45:18 -0700 Message-ID: From: Garrett Cooper To: Alexander Kabaev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Sam Fourman Jr." , Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 23:45:24 -0000 2010/6/30 Alexander Kabaev : > On Wed, 30 Jun 2010 14:42:47 -0700 > Garrett Cooper wrote: > >> On Wed, Jun 30, 2010 at 2:22 PM, Sam Fourman Jr. >> wrote: >> > On Wed, Jun 30, 2010 at 11:26 AM, Garrett Cooper >> > wrote: >> >> On Wed, Jun 30, 2010 at 8:43 AM, Sam Fourman Jr. >> >> wrote: >> >>>> Which patch ? icebp generates the SIGTRAP on latest 8-stable, >> >>>> verified by the following trivival assembler program: >> >>>> =A0 =A0 =A0 =A0.text >> >>>> =A0 =A0 =A0 =A0.globl =A0main >> >>>> main: >> >>>> =A0 =A0 =A0 =A0.byte =A0 0xf1 >> >>>> =A0 =A0 =A0 =A0xorl =A0 =A0%edi,%edi >> >>>> =A0 =A0 =A0 =A0call =A0 =A0exit >> >>>> >> >>> >> > >> > Here is the C program that the linux people used as a test case. >> > >> > *************************************************************** >> > #include >> > #include >> > >> > >> > >> > void trap_handler(int sig) >> > { >> > =A0 =A0 =A0 =A0printf("trapped\n"); >> > } >> > >> > >> > /* >> > =A0* icebp >> > =A0* ret >> > =A0*/ >> > char icebp_func[] =3D "\xf1\xc3"; >> > typedef void (*icebp_call)(void); >> > >> > int main(int argc, char **argv) >> > { >> > =A0 =A0 =A0 =A0icebp_call func =3D (icebp_call)icebp_func; >> > >> > =A0 =A0 =A0 =A0signal(SIGTRAP, trap_handler); >> > >> > =A0 =A0 =A0 =A0func(); >> > >> > =A0 =A0 =A0 =A0return 0; >> > } >> > >> > *************************************************************** >> > >> > My question is why doe the above code not print trapped on amd64? >> > >> > FreeBSD 8.1 i386 this code prints "Trapped" as intended >> > FreeBSD 8.1 amd64 this code prints "Segmentation fault: 11" >> > FreeBSD 8.1 amd64 chrooted to 32bit prints "Segmentation fault" >> > >> > I did verify that from Linux amd64 this works and prints "Trapped" >> > uname -a >> > Linux workstation 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 >> > 08:03:28 UTC 2010 x86_64 GNU/Linux >> >> Hmmm... I've seen similar whackiness with Linux and signals, but >> that's a different thing entirely (it was rt signals vs non-rt >> signals). >> >> Here's a modified version of the testcase (wanted to make sure that >> things were sane): >> >> $ cat test_sigtrap.c >> #include >> #include >> #include >> >> int trapped =3D 0; >> >> void trap_handler(int sig) >> { >> =A0 =A0 =A0 trapped =3D 1; >> } >> >> >> /* >> =A0* icebp >> =A0* ret >> =A0*/ >> char icebp_func[] =3D "\xf1\xc3"; >> typedef void (*icebp_call)(void); >> >> int main(int argc, char **argv) >> { >> =A0 =A0 =A0 icebp_call func =3D (icebp_call)icebp_func; >> >> =A0 =A0 =A0 if (signal(SIGTRAP, trap_handler) =3D=3D SIG_ERR) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 err(1, "signal"); >> >> =A0 =A0 =A0 func(); >> >> =A0 =A0 =A0 if (trapped) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf("Admiral Ackbar: it's a trap!\n"); >> >> =A0 =A0 =A0 return 0; >> } >> >> Ran it and it segfaulted on CURRENT: >> > > Now make icebp_func const and observe the program start working. The > test case is broken as written, because icebp_func array is writable, > so in ends up in a non-const part of .bss, which is not marked as > executable and rightfully causes SIGSEGV when jumped to. Which means that Linux is broken in this regard because it's loading data as text, not data as data and text as text? Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 1 00:12:22 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72928106564A for ; Thu, 1 Jul 2010 00:12:22 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 14E0A8FC14 for ; Thu, 1 Jul 2010 00:12:21 +0000 (UTC) Received: by vws6 with SMTP id 6so648459vws.13 for ; Wed, 30 Jun 2010 17:12:14 -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=kJq2mXoPgg03Ft72mfb0vVia1OJOrzNaJaRTmygltQQ=; b=XKUlfvY10B3eH5/NR0YeXGnTWRLDNfqLqTjII2da1kPGFLGt9Q4kINOB/aJw2rIwxG b4ctoTgZRL8DZqKbU9mvhglm88Vccrut1/7lw6J2QbRs1wJ1MdQT37ab71PWiVvCzX5H l0UcyVaHM697/9pUA1ly4L3vGjz/Ruif7KNPY= 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=TRhdJ8b6Uq00AjsGIGx+koZ90aX/d/8U9UX+ExhWplH0axqldRiGrMt/dDVwgqEpEu 8gskl6LXHaN4wwq88NmmKieDkj+2WQEODA8zV2niSR0LxNb0cTesq5a+WSENifYxDlPm v4XDy+jIEcNKwiPGOPqK9Crl+geGfdNP74gv8= Received: by 10.229.231.134 with SMTP id jq6mr5675068qcb.34.1277943134619; Wed, 30 Jun 2010 17:12:14 -0700 (PDT) Received: from kan.dnsalias.net (c-24-63-226-98.hsd1.ma.comcast.net [24.63.226.98]) by mx.google.com with ESMTPS id x40sm43905502qce.43.2010.06.30.17.12.13 (version=SSLv3 cipher=RC4-MD5); Wed, 30 Jun 2010 17:12:14 -0700 (PDT) Date: Wed, 30 Jun 2010 20:12:08 -0400 From: Alexander Kabaev To: Garrett Cooper Message-ID: <20100630201208.095139c0@kan.dnsalias.net> In-Reply-To: References: <20100630105027.GJ13238@deviant.kiev.zoral.com.ua> <20100630192350.105e8303@kan.dnsalias.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/q2rfeRI6R=_xu2GVWbcqN9c"; protocol="application/pgp-signature" Cc: "Sam Fourman Jr." , Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 00:12:22 -0000 --Sig_/q2rfeRI6R=_xu2GVWbcqN9c Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 30 Jun 2010 16:45:18 -0700 Garrett Cooper wrote: > > > > Now make icebp_func const and observe the program start working. The > > test case is broken as written, because icebp_func array is > > writable, so in ends up in a non-const part of .bss, which is not > > marked as executable and rightfully causes SIGSEGV when jumped to. >=20 > Which means that Linux is broken in this regard because it's loading > data as text, not data as data and text as text? > Thanks, Nope, I think this is i386 vs. amd64 difference. NX page protection is enforced in long mode, or in 32-bit with PAE, if I remember things correctly. --=20 Alexander Kabaev --Sig_/q2rfeRI6R=_xu2GVWbcqN9c Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iD8DBQFMK91cQ6z1jMm+XZYRAtQ4AJ9ZtXAuvaeH1twnRmZRYUfKpUhEAQCgxd3d dToOaZXrnJ8+kVH/FPC/mC0= =Uob+ -----END PGP SIGNATURE----- --Sig_/q2rfeRI6R=_xu2GVWbcqN9c-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 1 00:26:53 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB8661065673 for ; Thu, 1 Jul 2010 00:26:53 +0000 (UTC) (envelope-from uffe@uffe.org) Received: from mail.starion.dk (mx0.starion.dk [83.95.112.88]) by mx1.freebsd.org (Postfix) with SMTP id 0F5578FC08 for ; Thu, 1 Jul 2010 00:26:52 +0000 (UTC) Received: (qmail 18805 invoked by uid 528); 1 Jul 2010 00:27:13 -0000 Received: from 10.7.7.247 ([10.7.7.247]) by mail.starion.dk ([192.168.0.100]) with ESMTP via TCP; 01 Jul 2010 00:27:13 -0000 References: <20100630105027.GJ13238@deviant.kiev.zoral.com.ua> <20100630192350.105e8303@kan.dnsalias.net> <20100630201208.095139c0@kan.dnsalias.net> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Uffe Jakobsen To: freebsd-hackers@freebsd.org Date: Thu, 01 Jul 2010 02:26:51 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 00:26:54 -0000 Alexander Kabaev writes: > On Wed, 30 Jun 2010 16:45:18 -0700 > Garrett Cooper wrote: >> Which means that Linux is broken in this regard because it's loading >> data as text, not data as data and text as text? >> Thanks, > > Nope, I think this is i386 vs. amd64 difference. NX page protection is > enforced in long mode, or in 32-bit with PAE, if I remember things > correctly. > i386 32bit-mode page table has no NX bit - the PAE page table has... -- /Uffe From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 1 01:07:19 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBE46106566B for ; Thu, 1 Jul 2010 01:07:19 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6B4EA8FC0A for ; Thu, 1 Jul 2010 01:07:19 +0000 (UTC) Received: by vws6 with SMTP id 6so713687vws.13 for ; Wed, 30 Jun 2010 18:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=PfVSHP2+c4uUPI5ctOrlrcd4IZfw3UJ9n8txPwFd7TY=; b=s1Q3WEfW6vcaOMZ3lkrbVB0yqRpJxVJkhbUl7vobZk2ArbaVlDwhYO/eYLradBoA0V W3NinWpPvvJGTY1eyGVitjVbVX/YTMuWndL79El2o7eMb7M2pUITTl1WqdDxk9SI5tDc z/1dQOGNX4xEkxIyYxcY+tguUGgdmgjGbwWdE= 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; b=bYOfHWaqJrqw16BJP+wAzgVlDaG8aGMIqjKYSBBKxJvXfCZ4hPjjpnQh7ie9eSOjgg lRluiwiXEosRAVcW7FU5ieFhbyaucLB86oLx3bvQoj6NCDvtv+P9EtcMEnsaTV/8ajLG XDBIf7wFngl++pu195KuVdnDAy8OYQ7pQ8/Z8= MIME-Version: 1.0 Received: by 10.229.181.73 with SMTP id bx9mr5661013qcb.254.1277946429982; Wed, 30 Jun 2010 18:07:09 -0700 (PDT) Received: by 10.229.41.203 with HTTP; Wed, 30 Jun 2010 18:07:09 -0700 (PDT) In-Reply-To: References: <20100630105027.GJ13238@deviant.kiev.zoral.com.ua> <20100630192350.105e8303@kan.dnsalias.net> <20100630201208.095139c0@kan.dnsalias.net> Date: Wed, 30 Jun 2010 20:07:09 -0500 Message-ID: From: "Sam Fourman Jr." To: Uffe Jakobsen Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 01:07:19 -0000 > i386 32bit-mode page table has no NX bit - the PAE page table has... You are correct, I went in my BIOS, and disabled execute bit. Then when I run the test C code, the get "trapped" just as expected on both 8.1 amd64 and CURRENT amd64 however World of warcraft still segfaults even though execute bit is disabled in BIOS. I guess I am just confused on how linux fixed this with this patch http://bugs.winehq.org/attachment.cgi?id=29155 Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 1 05:19:28 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 675E110658C2 for ; Thu, 1 Jul 2010 05:19:28 +0000 (UTC) (envelope-from andrey.zonov@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id E8CFA8FC30 for ; Thu, 1 Jul 2010 05:19:27 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e12so306216fga.13 for ; Wed, 30 Jun 2010 22:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Ez8skYFuVP1gGxosd1T1ZbGt3D45Y/EPTmYEAM5s9ww=; b=fdfzShlryOX+vo9vIy8pXpI3Ar7Hs1eQ8nuwckUckayn1CIf9d8wFOXhCcM1OrUT69 D4KOStz1im9xYSWfw/OJu4CAbqsezsOnRVrgYBM0Fi5rQb9wzwv3Fm74efcGKl5mS0Di om+PVvCRA0I27HcJDEdpnQK0pqJcWXhCliNJ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=qVXPHFD/tJwG4UbPBRc8p4pKKMce/9wVzQAumEZ31l/S67yU6ok/A8PnAl+RWEQ3vm MHCyewxt6+dRFjOTzdPksjv5wBGdX0PRptM28Tf3w1mw6NSIIXo5cqHNnZ/44sy+5RKM Iw0o8bPL5bWX3zdpq9lNLfyhhs9H1kfFMcAR4= Received: by 10.87.1.7 with SMTP id d7mr14449873fgi.75.1277961561663; Wed, 30 Jun 2010 22:19:21 -0700 (PDT) Received: from [10.254.254.77] (ppp79-139-207-225.pppoe.spdop.ru [79.139.207.225]) by mx.google.com with ESMTPS id y15sm6855681fkd.8.2010.06.30.22.19.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 30 Jun 2010 22:19:20 -0700 (PDT) Message-ID: <4C2C2557.3030304@gmail.com> Date: Thu, 01 Jul 2010 09:19:19 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Julian Elischer References: <4C2AE37C.5060000@gmail.com> <4C2AF285.1090506@yandex.ru> <4C2B8B95.4010908@gmail.com> <4C2BBCC9.7000605@elischer.org> In-Reply-To: <4C2BBCC9.7000605@elischer.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: How change process flags from userland? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 05:19:28 -0000 Can you explain how change flags with /dev/kmem? kvm_write(3) not work for this. Julian Elischer ÐÉÛÅÔ: > On 6/30/10 11:23 AM, Andrey Zonov wrote: >> Yes, but I want change process flags without kernel hacking/loading >> modules or modification applications. > > you are going to have to do one of those. > The only alternative is that if you have root you can modify a > processe's flags > using gdb and /dev/kmem. > you could use a program to do it specially if you have root, > but if that's not what you want then you will need to add a syscall to > do what you want > as far as I can see. > > > > >> >> Andrey V. Elsukov ÐÉÛÅÔ: >>> On 30.06.2010 10:26, Andrey Zonov wrote: >>>> Hi, >>>> >>>> I want to set P_PROTECTED flag for some daemons after it start, >>>> without >>>> patching application and kernel. >>>> It possible? >>>> >>> >>> Did you try sysutils/scprotect? >>> >> > -- Andrey Zonov From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 1 07:15:09 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 978FC106564A for ; Thu, 1 Jul 2010 07:15:09 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5A8818FC0C for ; Thu, 1 Jul 2010 07:15:09 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 556971FFC34; Thu, 1 Jul 2010 07:15:08 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id CCCB584571; Thu, 1 Jul 2010 09:12:56 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: d@delphij.net References: <4C2B07F5.6030801@delphij.net> <4C2B4D35.8060903@feral.com> <86lj9wmbrz.fsf@ds4.des.no> <4C2BBF3C.4070503@delphij.net> <86hbkkmad1.fsf@ds4.des.no> <4C2BD498.3090704@delphij.net> Date: Thu, 01 Jul 2010 09:12:56 +0200 In-Reply-To: <4C2BD498.3090704@delphij.net> (Xin LI's message of "Wed, 30 Jun 2010 16:34:48 -0700") Message-ID: <86d3v7n093.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Matthew Jacob Subject: Re: Supermicro BIOS's watchdog feature? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 07:15:09 -0000 Xin LI writes: > "Dag-Erling Sm=C3=B8rgrav" writes: > > Perhaps the motherboard has additional watchdog hardware? If you > > disable the watchdog in BIOS, does ichwd still work? > If I kill -9 watchdogd the system do reset itself so I think ichwd(4) > really works even if BIOS setting is 'Disabled' (but I'm not sure if > this method is right? Looking at the code I think the answer is > probably "Yes" though) Yes. This confirms my hypothesis, which is that your motherboard has additional watchdog hardware, and that the BIOS setting controls that, not the ichwd watchdog timer. Just disable the watchdog in BIOS and use ichwd instead. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 1 09:12:23 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6725D1065679 for ; Thu, 1 Jul 2010 09:12:23 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay006.isp.belgacom.be (mailrelay006.isp.belgacom.be [195.238.6.172]) by mx1.freebsd.org (Postfix) with ESMTP id 02C388FC0C for ; Thu, 1 Jul 2010 09:12:22 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEGAJP3K0xbsagn/2dsb2JhbACTK4w4cr5bhSUE Received: from 39.168-177-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.177.168.39]) by relay.skynet.be with ESMTP; 01 Jul 2010 11:12:21 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.4/8.14.4) with ESMTP id o619CF0N002764; Thu, 1 Jul 2010 11:12:20 +0200 (CEST) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-hackers@freebsd.org Date: Thu, 1 Jul 2010 11:12:14 +0200 User-Agent: KMail/1.13.3 (FreeBSD/8.1-PRERELEASE; KDE/4.4.4; i386; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007011112.14853.tijl@coosemans.org> Cc: "Sam Fourman Jr." Subject: Re: kernel patch needed for wine? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 09:12:23 -0000 On Thursday 01 July 2010 03:07:09 Sam Fourman Jr. wrote: >> i386 32bit-mode page table has no NX bit - the PAE page table has... > > You are correct, I went in my BIOS, and disabled execute bit. > > Then when I run the test C code, the get "trapped" just as expected > on both 8.1 amd64 and CURRENT amd64 however World of warcraft still > segfaults even though execute bit is disabled in BIOS. > > I guess I am just confused on how linux fixed this with this patch > > http://bugs.winehq.org/attachment.cgi?id=29155 Wine translates signals and their siginfo into windows exceptions. In the test case you posted earlier you should try install the sighandler with sigaction(2) and the SA_SIGINFO flag. Then print the siginfo struct when you receive the signal and compare that to Linux or FreeBSD/i386. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 1 17:20:31 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79994106564A for ; Thu, 1 Jul 2010 17:20:31 +0000 (UTC) (envelope-from bahamasfranks@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 122778FC0C for ; Thu, 1 Jul 2010 17:20:30 +0000 (UTC) Received: by wwb13 with SMTP id 13so2436wwb.31 for ; Thu, 01 Jul 2010 10:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=wbFkLn/yeiTx+RKgfuPaXyvRweEUYQTleODXIF8RJow=; b=vgTwT1EK2P9sg28WL1zWvb5EA+sQP3b2qCQbzyXP1KEnQkd1RSxdtAc7MepaH8NUAH ZL1RI22/Xf6VaA/NZbGuNhfZP/gUZzrJgQ/A7ht+ckxLLkBF9fiE/nB4t6WivdLVE/Ms LQQdLVoxI8/BxsDHB5NffjWuzlb5YezcWcolA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=GnTwL+YbCZwepHrqTconN4sxrwoq/+tWxIukiVwmUfCkUaj+42T8tGyXIGXSK80ac5 b1/zWmW5VXBNDp0Z43innrb4XJDmEQM3uRm2wxFeTPM8a3p/g+x/X547XOwhjCN+rY3M rC2HpmCtr1ltWcQ3/H4LXIWODO/FHUngqY42Q= MIME-Version: 1.0 Received: by 10.227.155.138 with SMTP id s10mr33588wbw.71.1278004825764; Thu, 01 Jul 2010 10:20:25 -0700 (PDT) Received: by 10.231.157.144 with HTTP; Thu, 1 Jul 2010 10:20:25 -0700 (PDT) Date: Thu, 1 Jul 2010 10:20:25 -0700 Message-ID: From: Steve Franks To: freebsd-hackers Content-Type: text/plain; charset=ISO-8859-1 Subject: thoughts on sorting files into sub-folders by access date? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 17:20:31 -0000 Hi y'all, My high-end point&shoot camera likes to glob all my photos in a single folder, and it's glutting up my drive, and makes finding a specific trip unpleasant, with no good place for metadata. My SLR sorts them into folders by date, which I love. I can't find anything close googling, so I d/l a bunch of perl examples. Before I figure this out in python (I'm a hardware developer by trade, so that seems most sensible [libc doesn't seem to have any os-agnostic way of playing with file times, no?])... I thought I'd check if there's some trivially simple way of doing this with bash & find first. And, no, I'm kind of a keyboard jockey, so I'm not even considering importing all my photos into some app for handing my metadata. Text files do that just fine if I can sort them into folders. Best, Steve From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 1 17:49:13 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9740C106564A for ; Thu, 1 Jul 2010 17:49:13 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id 80E438FC08 for ; Thu, 1 Jul 2010 17:49:13 +0000 (UTC) Received: from [127.0.0.1] (cheese.corp.yahoo.com [216.145.50.99]) by mrout2.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o61Hjb5U015427; Thu, 1 Jul 2010 10:45:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:reply-to:to:cc:in-reply-to:references: content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=D28o8O0DmxJEzZoM3nf0zkq76IcTmcq6fyFc594QmtvhobrrdDe6JmaO8i27NoLI From: Sean Bruno To: Garrett Cooper In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Thu, 01 Jul 2010 10:45:37 -0700 Message-ID: <1278006337.2438.90.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: FreeBSD-Hackers Subject: Re: Set default pxeboot vfs.root.mountfrom to nfs? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 17:49:13 -0000 On Tue, 2010-06-29 at 15:07 -0700, Garrett Cooper wrote: > Hi Hackers, > I realize this is a trivial patch, but it's a minor item that I > found kind of fascinating (and not thoroughly documented elsewhere > because many examples are booting mfsroots instead of directly booting > off nfs roots), but I'm proposing that pxeboot default to > vfs.root.mountfrom="nfs" to reduce the need for special case > loader.conf files just for pxe booting (and thus, enable > out-of-the-box netbooting ^o^!!!). > Thoughts? > Thanks! > -Garrett I'll just give this a +1 and move on. sean From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 1 17:55:44 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9D5F106566B for ; Thu, 1 Jul 2010 17:55:44 +0000 (UTC) (envelope-from lidl@pix.net) Received: from rox.fddx.com (rox.fddx.com [IPv6:2001:470:8:202:204:23ff:fea8:aa3f]) by mx1.freebsd.org (Postfix) with ESMTP id 934408FC0A for ; Thu, 1 Jul 2010 17:55:44 +0000 (UTC) Received: from torb.pix.net (verizon.pix.net [71.241.230.58]) by rox.fddx.com (8.13.8+Sun/8.13.8) with ESMTP id o61Htasj027983; Thu, 1 Jul 2010 13:55:43 -0400 (EDT) Message-ID: <4C2CD698.4080607@pix.net> Date: Thu, 01 Jul 2010 13:55:36 -0400 From: Kurt Lidl User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Steve Franks References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at rox.fddx.com X-Virus-Status: Clean Cc: freebsd-hackers Subject: Re: thoughts on sorting files into sub-folders by access date? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 17:55:45 -0000 Steve Franks wrote: > I can't find anything close googling, so I d/l a bunch of perl > examples. Before I figure this out in python (I'm a hardware > developer by trade, so that seems most sensible [libc doesn't seem to > have any os-agnostic way of playing with file times, no?])... man utimes -Kurt From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 1 18:50:51 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05670106566B for ; Thu, 1 Jul 2010 18:50:51 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id AD55E8FC0C for ; Thu, 1 Jul 2010 18:50:50 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 471AB5ACEE for ; Thu, 1 Jul 2010 20:50:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 454A25ACC9 for ; Thu, 1 Jul 2010 20:50:49 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 244765CDD7 for ; Thu, 1 Jul 2010 20:50:49 +0200 (CEST) Received: from wep4035.physik.uni-wuerzburg.de ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.5.1FP3) with ESMTP id 2010070120504784-282794 ; Thu, 1 Jul 2010 20:50:47 +0200 Date: Thu, 1 Jul 2010 20:50:47 +0200 From: Alexey Shuvaev To: FreeBSD-Hackers Message-ID: <20100701185047.GA66059@wep4035.physik.uni-wuerzburg.de> References: <1278006337.2438.90.camel@localhost.localdomain> MIME-Version: 1.0 In-Reply-To: <1278006337.2438.90.camel@localhost.localdomain> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.20 (2009-06-14) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.5.1FP3|May 23, 2010) at 07/01/2010 08:50:48 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.5.1FP3|May 23, 2010) at 07/01/2010 08:50:48 PM, Serialize complete at 07/01/2010 08:50:48 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Set default pxeboot vfs.root.mountfrom to nfs? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:50:51 -0000 On Thu, Jul 01, 2010 at 10:45:37AM -0700, Sean Bruno wrote: > On Tue, 2010-06-29 at 15:07 -0700, Garrett Cooper wrote: > > Hi Hackers, > > I realize this is a trivial patch, but it's a minor item that I > > found kind of fascinating (and not thoroughly documented elsewhere > > because many examples are booting mfsroots instead of directly booting > > off nfs roots), but I'm proposing that pxeboot default to > > vfs.root.mountfrom="nfs" to reduce the need for special case > > loader.conf files just for pxe booting (and thus, enable > > out-of-the-box netbooting ^o^!!!). > > Thoughts? > > Thanks! > > -Garrett > > I'll just give this a +1 and move on. > > sean > I don't quite understand the whole point of this patch. I have no "special" loader.conf files and the diskless test machine boots just fine. I suppose dhcp server sends vital information which is understood by pxeboot. On the dhcp/tftp/nfs server: > cat amd64/boot/loader.conf loader_logo="beastie" snd_hda_load="YES" ahci_load="YES" vboxdrv_load="YES" > cat amd64/conf/base/etc/fstab md /tmp mfs -s=128m,rw 0 0 linprocfs /compat/linux/proc linprocfs rw 0 0 > ls /tftpboot/ pxeboot > tail -20 /usr/local/etc/dhcpd.conf #} subnet X.X.X.0 netmask 255.255.255.0 { } group { next-server HOSTNAME; filename "pxeboot"; option root-path "HOSTNAME:/home/jails/amd64"; host HOST1 { fixed-address Y.Y.Y.Y; hardware ethernet xx:xx:xx:xx:xx:xx; } host HOST2 { fixed-address Z.Z.Z.Z; hardware ethernet yy:yy:yy:yy:yy:yy; } } From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 1 19:32:00 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62483106564A for ; Thu, 1 Jul 2010 19:32:00 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 1CCF08FC14 for ; Thu, 1 Jul 2010 19:31:59 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.3/8.14.3) with ESMTP id o61JVwwM084184; Thu, 1 Jul 2010 13:31:58 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.3/8.14.3/Submit) with ESMTP id o61JVwTN084181; Thu, 1 Jul 2010 13:31:58 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Thu, 1 Jul 2010 13:31:58 -0600 (MDT) From: Warren Block To: Steve Franks In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.5 (wonkity.com [127.0.0.1]); Thu, 01 Jul 2010 13:31:59 -0600 (MDT) Cc: freebsd-hackers Subject: Re: thoughts on sorting files into sub-folders by access date? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 19:32:00 -0000 On Thu, 1 Jul 2010, Steve Franks wrote: > My high-end point&shoot camera likes to glob all my photos in a single > folder, and it's glutting up my drive, and makes finding a specific > trip unpleasant, with no good place for metadata. My SLR sorts them > into folders by date, which I love. > > I can't find anything close googling, so I d/l a bunch of perl > examples. Before I figure this out in python (I'm a hardware > developer by trade, so that seems most sensible [libc doesn't seem to > have any os-agnostic way of playing with file times, no?])... > > I thought I'd check if there's some trivially simple way of doing this > with bash & find first. The EXIF data is a better source for the date. graphics/py-exif, for example. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 1 21:09:03 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D38E11065678 for ; Thu, 1 Jul 2010 21:09:03 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 334EC8FC16 for ; Thu, 1 Jul 2010 21:09:02 +0000 (UTC) Received: by wyb34 with SMTP id 34so1943400wyb.13 for ; Thu, 01 Jul 2010 14:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=a6OYXjYtSwrLuszHAcs8gdARl/dE+KcQwauP3gNiLyE=; b=qVXXoFzBzJo7XkkLLNLjiG4reM9THXX3seKaWfpxUp5lN5HkZTHaWMD62nt5G80vhD J9hjtgFVREqKSuD5gIKDPh4hpujmxyjvwYCT+S2uKCFX/ijnlfpL+C17wA17jRY7u2pc om5XoqvANnWut2c/ss19jFjZiCa5YJb6QHbUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=eIZ+ARbINQu3ShS5E9mtpq8T4uD740BRHD0R0zDArN0eF+4C1nzJ/kUWuvUxa4i58r Kj7AxLXcchoDwsU1JRLrsd7qYRQbpXvPp7gte2MxUyds9MT/Ts+5QIQnmJckJgpqWpq7 cri3UdKAMJJDrkfj5635HnOB7gfjh+hz93iTs= Received: by 10.213.14.15 with SMTP id e15mr37502eba.62.1278018538137; Thu, 01 Jul 2010 14:08:58 -0700 (PDT) Received: from gumby.homeunix.com (bb-87-81-140-128.ukonline.co.uk [87.81.140.128]) by mx.google.com with ESMTPS id v8sm638848eeh.2.2010.07.01.14.08.57 (version=SSLv3 cipher=RC4-MD5); Thu, 01 Jul 2010 14:08:57 -0700 (PDT) Date: Thu, 1 Jul 2010 22:08:55 +0100 From: RW To: freebsd-hackers@freebsd.org Message-ID: <20100701220855.70d74b03@gumby.homeunix.com> In-Reply-To: References: X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: thoughts on sorting files into sub-folders by access date? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 21:09:03 -0000 On Thu, 1 Jul 2010 10:20:25 -0700 Steve Franks wrote: > Hi y'all, > > My high-end point&shoot camera likes to glob all my photos in a single > folder, and it's glutting up my drive, and makes finding a specific > trip unpleasant, with no good place for metadata. My SLR sorts them > into folders by date, which I love. > > ... > I thought I'd check if there's some trivially simple way of doing this > with bash & find first. > If the timestamps are acccurate you could simply loop around the files and do something like this (untested): dir="${targetdir}/`stat -f %Sm -t %Y%m%d ${file}`/" [ -d "${dir}"] || mkdir "${dir}" mv "${file}" "${dir}"] From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 1 23:47:21 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08661106567A for ; Thu, 1 Jul 2010 23:47:21 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by mx1.freebsd.org (Postfix) with ESMTP id C34A68FC0A for ; Thu, 1 Jul 2010 23:47:20 +0000 (UTC) Received: from [127.0.0.1] (cheese.corp.yahoo.com [216.145.50.99]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o61NkgCk078276 for ; Thu, 1 Jul 2010 16:46:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:reply-to:to:content-type:date:message-id: mime-version:x-mailer; b=kp7F2IJgeWhL0E3FpR+7C+bI1ZyIX/vVjX1wJLP4GO8apFKqDUlmZ3JX0Hbk49g3 From: Sean Bruno To: "freebsd-hackers@freebsd.org" Content-Type: multipart/mixed; boundary="=-Wh2r+zOr01orih2mjubK" Date: Thu, 01 Jul 2010 16:46:41 -0700 Message-ID: <1278028001.2438.113.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Subject: [Patch] Kgmon/Gprof On/Off Switch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 23:47:21 -0000 --=-Wh2r+zOr01orih2mjubK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Found this lying around the Yahoo tree this week. Basically it allows you to activate, reset and deactivate profiling with the '-f" flag. Kind of nice to have if you want the ability to turn on profiling for debugging live systems. Applies cleanly to head at the moment. Sean --=-Wh2r+zOr01orih2mjubK Content-Disposition: attachment; filename="kgmon_gprof_dynamic.diff" Content-Type: text/x-patch; name="kgmon_gprof_dynamic.diff"; charset="UTF-8" Content-Transfer-Encoding: 7bit Index: usr.sbin/kgmon/kgmon.8 =================================================================== --- usr.sbin/kgmon/kgmon.8 (revision 209631) +++ usr.sbin/kgmon/kgmon.8 (working copy) @@ -70,6 +70,8 @@ Dump the contents of the profile buffers into a .Pa gmon.out file. +.It Fl f +Free profiling buffer. Also stops profiling. .It Fl r Reset all the profile buffers. If the Index: usr.sbin/kgmon/kgmon.c =================================================================== --- usr.sbin/kgmon/kgmon.c (revision 209631) +++ usr.sbin/kgmon/kgmon.c (working copy) @@ -72,7 +72,7 @@ struct gmonparam gpm; }; -int Bflag, bflag, hflag, kflag, rflag, pflag; +int Bflag, bflag, hflag, kflag, rflag, pflag, fflag; int debug = 0; int getprof(struct kvmvars *); int getprofhz(struct kvmvars *); @@ -82,6 +82,7 @@ void dumpstate(struct kvmvars *kvp); void reset(struct kvmvars *kvp); static void usage(void); +void freebuf(struct kvmvars *kvp); int main(int argc, char **argv) @@ -93,7 +94,7 @@ seteuid(getuid()); kmemf = NULL; system = NULL; - while ((ch = getopt(argc, argv, "M:N:Bbhpr")) != -1) { + while ((ch = getopt(argc, argv, "M:N:Bbfhpr")) != -1) { switch((char)ch) { case 'M': @@ -113,6 +114,10 @@ bflag = 1; break; + case 'f': + fflag = 1; + break; + case 'h': hflag = 1; break; @@ -158,6 +163,10 @@ dumpstate(&kvmvars); if (rflag) reset(&kvmvars); + if (fflag) { + freebuf(&kvmvars); + disp = GMON_PROF_OFF; + } if (accessmode == O_RDWR) setprof(&kvmvars, disp); (void)fprintf(stdout, "kgmon: kernel profiling is %s.\n", @@ -403,36 +412,44 @@ /* * Write out the arc info. */ - if ((froms = (u_short *)malloc(kvp->gpm.fromssize)) == NULL) - errx(8, "cannot allocate froms space"); - if (kflag) { - i = kvm_read(kvp->kd, (u_long)kvp->gpm.froms, (void *)froms, - kvp->gpm.fromssize); - } else { - mib[2] = GPROF_FROMS; - i = kvp->gpm.fromssize; - if (sysctl(mib, 3, froms, &i, NULL, 0) < 0) - i = 0; - } - if (i != kvp->gpm.fromssize) - errx(9, "read froms: read %lu, got %ld: %s", - kvp->gpm.fromssize, (long)i, - kflag ? kvm_geterr(kvp->kd) : strerror(errno)); - if ((tos = (struct tostruct *)malloc(kvp->gpm.tossize)) == NULL) - errx(10, "cannot allocate tos space"); - if (kflag) { - i = kvm_read(kvp->kd, (u_long)kvp->gpm.tos, (void *)tos, - kvp->gpm.tossize); - } else { - mib[2] = GPROF_TOS; - i = kvp->gpm.tossize; - if (sysctl(mib, 3, tos, &i, NULL, 0) < 0) - i = 0; - } - if (i != kvp->gpm.tossize) - errx(11, "read tos: read %lu, got %ld: %s", - kvp->gpm.tossize, (long)i, - kflag ? kvm_geterr(kvp->kd) : strerror(errno)); + if (kvp->gpm.fromssize > 0) { + if ((froms = (u_short *)malloc(kvp->gpm.fromssize)) == NULL) + errx(8, "cannot allocate froms space"); + if (kflag) { + i = kvm_read(kvp->kd, (u_long)kvp->gpm.froms, + (void *)froms, + kvp->gpm.fromssize); + } else { + mib[2] = GPROF_FROMS; + i = kvp->gpm.fromssize; + if (sysctl(mib, 3, froms, &i, NULL, 0) < 0) + i = 0; + } + if (i != kvp->gpm.fromssize) + errx(9, "read froms: read %lu, got %ld: %s", + kvp->gpm.fromssize, (long)i, + kflag ? kvm_geterr(kvp->kd) : strerror(errno)); + } + if (kvp->gpm.tossize > 0) { + if ((tos = (struct tostruct *)malloc(kvp->gpm.tossize)) == + NULL) + errx(10, "cannot allocate tos space"); + if (kflag) { + i = kvm_read(kvp->kd, (u_long)kvp->gpm.tos, + (void *)tos, + kvp->gpm.tossize); + } else { + mib[2] = GPROF_TOS; + i = kvp->gpm.tossize; + if (sysctl(mib, 3, tos, &i, NULL, 0) < 0) + i = 0; + } + if (i != kvp->gpm.tossize) + errx(11, "read tos: read %lu, got %ld: %s", + kvp->gpm.tossize, (long)i, + kflag ? kvm_geterr(kvp->kd) : strerror(errno)); + } + if (debug) warnx("lowpc 0x%lx, textsize 0x%lx", (unsigned long)kvp->gpm.lowpc, kvp->gpm.textsize); @@ -509,11 +526,13 @@ if (kvm_write(kvp->kd, (u_long)kvp->gpm.kcount, zbuf, kvp->gpm.kcountsize) != kvp->gpm.kcountsize) errx(13, "tickbuf zero: %s", kvm_geterr(kvp->kd)); - if (kvm_write(kvp->kd, (u_long)kvp->gpm.froms, zbuf, - kvp->gpm.fromssize) != kvp->gpm.fromssize) + if (kvp->gpm.fromssize > 0 && + kvm_write(kvp->kd, (u_long)kvp->gpm.froms, zbuf, + kvp->gpm.fromssize) != kvp->gpm.fromssize) errx(14, "froms zero: %s", kvm_geterr(kvp->kd)); - if (kvm_write(kvp->kd, (u_long)kvp->gpm.tos, zbuf, - kvp->gpm.tossize) != kvp->gpm.tossize) + if (kvp->gpm.tossize > 0 && + kvm_write(kvp->kd, (u_long)kvp->gpm.tos, zbuf, + kvp->gpm.tossize) != kvp->gpm.tossize) errx(15, "tos zero: %s", kvm_geterr(kvp->kd)); return; } @@ -524,11 +543,33 @@ if (sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.kcountsize) < 0) err(13, "tickbuf zero"); mib[2] = GPROF_FROMS; - if (sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.fromssize) < 0) + if (kvp->gpm.fromssize > 0 && + sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.fromssize) < 0) err(14, "froms zero"); mib[2] = GPROF_TOS; - if (sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.tossize) < 0) - err(15, "tos zero"); + if (kvp->gpm.tossize > 0 && + sysctl(mib, 3, NULL, NULL, zbuf, kvp->gpm.tossize) < 0) (void)seteuid(getuid()); free(zbuf); } + +/* + * Free the kernel profiling date structures. + */ +void +freebuf(kvp) + struct kvmvars *kvp; +{ + int mib[3]; + + setprof(kvp, GMON_PROF_OFF); + if (kflag) + return; + (void)seteuid(0); + mib[0] = CTL_KERN; + mib[1] = KERN_PROF; + mib[2] = GPROF_FREEBUF; + if (sysctl(mib, 3, NULL, 0, NULL, 0) < 0) + err(16, "Freeing profiling buffer failed"); + (void)seteuid(getuid()); +} Index: sys/kern/kern_clock.c =================================================================== --- sys/kern/kern_clock.c (revision 209631) +++ sys/kern/kern_clock.c (working copy) @@ -68,9 +68,7 @@ #include #include -#ifdef GPROF #include -#endif #ifdef HWPMC_HOOKS #include @@ -714,10 +712,8 @@ profclock(int usermode, uintfptr_t pc) { struct thread *td; -#ifdef GPROF struct gmonparam *g; uintfptr_t i; -#endif td = curthread; if (usermode) { @@ -730,7 +726,6 @@ if (td->td_proc->p_flag & P_PROFIL) addupc_intr(td, pc, 1); } -#ifdef GPROF else { /* * Kernel statistics are just like addupc_intr, only easier. @@ -743,7 +738,6 @@ } } } -#endif } /* Index: sys/kern/subr_prof.c =================================================================== --- sys/kern/subr_prof.c (revision 209631) +++ sys/kern/subr_prof.c (working copy) @@ -44,7 +44,6 @@ #include -#ifdef GPROF #include #include #undef MCOUNT @@ -136,7 +135,46 @@ free(cp, M_GPROF); } +#ifndef GPROF +/* Allocate kcount buffer and initialize state */ +static int +prof_alloc_kcountbuf(void) +{ + char *cp; + struct gmonparam *p = &_gmonparam; + int error = 0; + + mtx_lock(&Giant); + if (p->kcount == NULL) { + cp = (char *)malloc(p->kcountsize, M_GPROF, M_NOWAIT); + if (cp == 0) { + printf("No memory for profiling.\n"); + error = ENOMEM; + goto out; + } + bzero(cp, p->kcountsize); + p->kcount = (HISTCOUNTER *)cp; + } +out: + mtx_unlock(&Giant); + return error; +} + static void +prof_free_kcountbuf(void) +{ + struct gmonparam *p = &_gmonparam; + + mtx_lock(&Giant); + if (p->kcount != NULL) { + free(p->kcount, M_GPROF); + p->kcount = (HISTCOUNTER *)NULL; + } + mtx_unlock(&Giant); +} +#endif + +static void kmstartup(dummy) void *dummy; { @@ -152,6 +190,7 @@ int nullfunc_loop_profiled_time; uintfptr_t tmp_addr; #endif + int bufsize; /* * Round lowpc and highpc to multiples of the density we're using @@ -164,6 +203,7 @@ p->textsize, (uintmax_t)p->lowpc, (uintmax_t)p->highpc); p->kcountsize = p->textsize / HISTFRACTION; p->hashfraction = HASHFRACTION; +#ifdef GPROF p->fromssize = p->textsize / HASHFRACTION; p->tolimit = p->textsize * ARCDENSITY / 100; if (p->tolimit < MINARCS) @@ -171,13 +211,30 @@ else if (p->tolimit > MAXARCS) p->tolimit = MAXARCS; p->tossize = p->tolimit * sizeof(struct tostruct); - cp = (char *)malloc(p->kcountsize + p->fromssize + p->tossize, - M_GPROF, M_WAITOK | M_ZERO); + bufsize = p->kcountsize + p->fromssize + p->tossize; +#else + p->fromssize = 0; + p->tolimit = 0; + p->tossize = 0; + bufsize = 0; + p->kcount = (HISTCOUNTER *)NULL; +#endif + cp = NULL; + if (bufsize > 0) + cp = (char *)malloc(bufsize, M_GPROF, M_WAITOK | M_ZERO); +#ifdef GPROF p->tos = (struct tostruct *)cp; cp += p->tossize; +#else + p->tos = (struct tostruct *)NULL; +#endif p->kcount = (HISTCOUNTER *)cp; cp += p->kcountsize; +#ifdef GPROF p->froms = (u_short *)cp; +#else + p->froms = (u_short *)NULL; +#endif p->histcounter_type = FUNCTION_ALIGNMENT / HISTFRACTION * NBBY; #ifdef GUPROF @@ -351,6 +408,12 @@ } else if (state == GMON_PROF_ON) { gp->state = GMON_PROF_OFF; stopguprof(gp); +#ifndef GUPROF + /* Allocate kcount buffer and initialize state */ + error = prof_alloc_kcountbuf(); + if (error) + return error; +#endif gp->profrate = profhz; PROC_LOCK(&proc0); startprofclock(&proc0); @@ -368,15 +431,24 @@ } else if (state != gp->state) return (EINVAL); return (0); +#ifndef GPROF + if (gp->state != GMON_PROF_OFF) + return EINVAL; + /* Free kcount buffer */ + prof_free_kcountbuf(); +#endif + return 0; case GPROF_COUNT: return (sysctl_handle_opaque(oidp, gp->kcount, gp->kcountsize, req)); +#ifdef GPROF case GPROF_FROMS: return (sysctl_handle_opaque(oidp, gp->froms, gp->fromssize, req)); case GPROF_TOS: return (sysctl_handle_opaque(oidp, gp->tos, gp->tossize, req)); +#endif case GPROF_GMONPARAM: return (sysctl_handle_opaque(oidp, gp, sizeof *gp, req)); default: @@ -386,7 +458,6 @@ } SYSCTL_NODE(_kern, KERN_PROF, prof, CTLFLAG_RW, sysctl_kern_prof, ""); -#endif /* GPROF */ /* * Profiling system call. Index: sys/sys/gmon.h =================================================================== --- sys/sys/gmon.h (revision 209631) +++ sys/sys/gmon.h (working copy) @@ -197,6 +197,7 @@ #define GPROF_FROMS 2 /* struct: from location hash bucket */ #define GPROF_TOS 3 /* struct: destination/count structure */ #define GPROF_GMONPARAM 4 /* struct: profiling parameters (see above) */ +#define GPROF_FREEBUF 5 /* int: free flat profiling buffer */ #ifdef _KERNEL --=-Wh2r+zOr01orih2mjubK-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 2 00:38:42 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4FCD1065675 for ; Fri, 2 Jul 2010 00:38:42 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 760AA8FC0A for ; Fri, 2 Jul 2010 00:38:42 +0000 (UTC) Received: by ewy26 with SMTP id 26so1080731ewy.13 for ; Thu, 01 Jul 2010 17:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=8g9szkXKjr911Rw5nSDSQTTQInXMrbI7lHiMi77O/3I=; b=VangFgkqSi47CHyzNEB+s9o397wEZpoT9mnm1WVYdUemdJYaWrsZMcXtM1idXWDaZL WWuIEDDS12P/UVOPMYRTQeYx4/EsDP4V6k8BMSRl6QAsKBmzdCoEkrt0P+cucCm/QHUM bftUYpZ2690R/kxrxtxA+47w4zVFkZICg39bs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=QhwVce4hUQGIudwlV8I9PbY9p8pSvsYf0lgWfjqU47XOEtRwf88g/xAX53qgK51cqm I6iAtn6iT/3PCkifOEycSR0VHAWB/helIV7XkZ17Jbwbc48mQLkqS4ERzLF8h3vLX6Tk XKb0z31YOr/OgBqaXHQDk4lk001JHN+ATtxXw= Received: by 10.213.7.16 with SMTP id b16mr3258421ebb.15.1278031112119; Thu, 01 Jul 2010 17:38:32 -0700 (PDT) Received: from gumby.homeunix.com (bb-87-81-140-128.ukonline.co.uk [87.81.140.128]) by mx.google.com with ESMTPS id x54sm194866eeh.11.2010.07.01.17.38.30 (version=SSLv3 cipher=RC4-MD5); Thu, 01 Jul 2010 17:38:31 -0700 (PDT) Date: Fri, 2 Jul 2010 01:38:28 +0100 From: RW To: freebsd-hackers@freebsd.org Message-ID: <20100702013828.3b43639c@gumby.homeunix.com> In-Reply-To: <20100701220855.70d74b03@gumby.homeunix.com> References: <20100701220855.70d74b03@gumby.homeunix.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: thoughts on sorting files into sub-folders by access date? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 00:38:43 -0000 On Thu, 1 Jul 2010 22:08:55 +0100 RW wrote: > dir="${targetdir}/`stat -f %Sm -t %Y%m%d ${file}`/" > [ -d "${dir}"] || mkdir "${dir}" > mv "${file}" "${dir}"] > Should be: dir="${targetdir}/`stat -f %Sm -t %Y%m%d ${file}`/" [ -d "${dir}" ] || mkdir "${dir}" mv "${file}" "${dir}" From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 2 01:24:33 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 413B5106564A; Fri, 2 Jul 2010 01:24:33 +0000 (UTC) (envelope-from jmorris@namei.org) Received: from tundra.namei.org (tundra.namei.org [65.99.196.166]) by mx1.freebsd.org (Postfix) with ESMTP id BCF348FC14; Fri, 2 Jul 2010 01:24:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by tundra.namei.org (8.13.1/8.13.1) with ESMTP id o620i3OW002785; Thu, 1 Jul 2010 20:44:03 -0400 Date: Fri, 2 Jul 2010 10:44:03 +1000 (EST) From: James Morris To: freebsd-hackers@freebsd.org Message-ID: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Robert Watson Subject: Extended attributes for NFSv3 - possible Linux interop X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 01:24:33 -0000 I've been working on an implementation of extended attributes for the Linux NFSv3 code, initially based on the IRIX implementation [1]. This is being developed as a sideband protocol ('XATTR'), to convey simple name/value string extended attributes over the network. Here's a link to the latest patchset: http://lwn.net/Articles/392944/ and my LinuxCon slides on the topic from last year: http://namei.org/presentations/linuxcon09_nfsv3xattrs.pdf The code is at a working prototype stage, and the next step is to begin formalizing the protocol. I'd like to try and determine whether there is any interest in this XATTR protocol for FreeBSD (which has a similar extended attribute model to Linux), and then whether we should develop an informal specification to cater for interoperability between FreeBSD and Linux. [1] http://oss.sgi.com/projects/ob1.nuked/src/nfs/ Thanks, - James -- James Morris From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 2 08:30:07 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D123106566B; Fri, 2 Jul 2010 08:30:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 340538FC30; Fri, 2 Jul 2010 08:30:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 8B9B241C707; Fri, 2 Jul 2010 10:30:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 1tRcRzzVfR7n; Fri, 2 Jul 2010 10:30:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id B506341C6DB; Fri, 2 Jul 2010 10:30:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 04E0F4448EC; Fri, 2 Jul 2010 08:29:30 +0000 (UTC) Date: Fri, 2 Jul 2010 08:29:30 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Andriy Gapon In-Reply-To: <4C246CD0.3020606@freebsd.org> Message-ID: <20100702082754.S14969@maildrop.int.zabbadoz.net> References: <4C246CD0.3020606@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Konstantin Belousov , Navdeep Parhar , Peter Wemm Subject: Re: elf obj load: skip zero-sized sections early X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 08:30:07 -0000 On Fri, 25 Jun 2010, Andriy Gapon wrote: Hey, > Proposed patch skips zero sized sections without going into trouble of > allocating section entry (progtab), doing zero-sized memory allocs and copies. > I observe that sometimes zero-sized set_pcpu sections are produced in module > objects, maybe when a module doesn't create any per cpu data of its one, but > references external pcpu data. Not sure. > > Main goal of this patch is to play nice with external debugging tools (e.g. > kgdb) which ignore zero-sized sections outright. Current code effectively > ignores but may apply their alignment to the next non-zero section if its > required alignment is smaller. So the patch should get rid of that side effect > as well as do some very tiny resource conservation. > > This work is based on np@'s investigation and original patch: > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html Have you guys figured this out already? Adding kib to Cc: in case he can help. /bz > diff --git a/sys/boot/common/load_elf_obj.c b/sys/boot/common/load_elf_obj.c > index 4b3aaea..6f3b349 100644 > --- a/sys/boot/common/load_elf_obj.c > +++ b/sys/boot/common/load_elf_obj.c > @@ -221,6 +221,8 @@ __elfN(obj_loadimage)(struct preloaded_file *fp, elf_file_t > ef, u_int64_t off) > for (i = 0; i < hdr->e_shnum; i++) > shdr[i].sh_addr = 0; > for (i = 0; i < hdr->e_shnum; i++) { > + if (shdr[i].sh_size == 0) > + continue; > switch (shdr[i].sh_type) { > case SHT_PROGBITS: > case SHT_NOBITS: > diff --git a/sys/kern/link_elf_obj.c b/sys/kern/link_elf_obj.c > index a337fd0..b0df57d 100644 > --- a/sys/kern/link_elf_obj.c > +++ b/sys/kern/link_elf_obj.c > @@ -555,6 +555,8 @@ link_elf_load_file(linker_class_t cls, const char *filename, > symtabindex = -1; > symstrindex = -1; > for (i = 0; i < hdr->e_shnum; i++) { > + if (shdr[i].sh_size == 0) > + continue; > switch (shdr[i].sh_type) { > case SHT_PROGBITS: > case SHT_NOBITS: > @@ -677,6 +679,8 @@ link_elf_load_file(linker_class_t cls, const char *filename, > /* Size up code/data(progbits) and bss(nobits). */ > alignmask = 0; > for (i = 0; i < hdr->e_shnum; i++) { > + if (shdr[i].sh_size == 0) > + continue; > switch (shdr[i].sh_type) { > case SHT_PROGBITS: > case SHT_NOBITS: > @@ -737,6 +741,8 @@ link_elf_load_file(linker_class_t cls, const char *filename, > ra = 0; > alignmask = 0; > for (i = 0; i < hdr->e_shnum; i++) { > + if (shdr[i].sh_size == 0) > + continue; > switch (shdr[i].sh_type) { > case SHT_PROGBITS: > case SHT_NOBITS: > > -- Bjoern A. Zeeb From August on I will have a life. It's now up to you to do the maths and count to 64. -- Bondorf, Germany, 14th June 2010 From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 2 09:34:46 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDAFA106564A; Fri, 2 Jul 2010 09:34:46 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C47FA8FC1F; Fri, 2 Jul 2010 09:34:46 +0000 (UTC) Received: from [192.168.2.105] (host86-162-156-210.range86-162.btcentralplus.com [86.162.156.210]) by cyrus.watson.org (Postfix) with ESMTPSA id 28A3546B17; Fri, 2 Jul 2010 05:34:45 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Fri, 2 Jul 2010 10:34:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <98BC47A1-7A14-48EF-8C4B-EFB7EF063853@freebsd.org> References: To: James Morris X-Mailer: Apple Mail (2.1081) Cc: freebsd-hackers@freebsd.org, Rick Macklem Subject: Re: Extended attributes for NFSv3 - possible Linux interop X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 09:34:47 -0000 On 2 Jul 2010, at 01:44, James Morris wrote: > I've been working on an implementation of extended attributes for the=20= > Linux NFSv3 code, initially based on the IRIX implementation [1]. = This is=20 > being developed as a sideband protocol ('XATTR'), to convey simple=20 > name/value string extended attributes over the network. >=20 > Here's a link to the latest patchset: > http://lwn.net/Articles/392944/ >=20 > and my LinuxCon slides on the topic from last year: > http://namei.org/presentations/linuxcon09_nfsv3xattrs.pdf >=20 > The code is at a working prototype stage, and the next step is to = begin=20 > formalizing the protocol. >=20 > I'd like to try and determine whether there is any interest in this = XATTR=20 > protocol for FreeBSD (which has a similar extended attribute model to=20= > Linux), and then whether we should develop an informal specification = to=20 > cater for interoperability between FreeBSD and Linux.=20 >=20 > [1] http://oss.sgi.com/projects/ob1.nuked/src/nfs/ Hi Other Robert: I think it's a good idea. BTW, Mac OS X *also* supports meta-data = extended attributes (not just forks) on HFS+ and friends, and similarly = uses them to hold ACLs, MAC labels (using a port of FreeBSD's MAC = Framework), etc. My hazy recollection is that they are stored inside a = specially designated file fork, but that might be a misrecollection. So = the Apple folk might be interested as well so we should try to get them = in the loop -- they certainly also understand the file fork vs. = meta-data EA tension. Their API is a bit more like the Linux API than = the FreeBSD API when it comes to meta-data -- minor spelling = differences. Historically other systems have also done IRIX meta-data = EAs (which is where both the Linux and FreeBSD work found its model) = including HPFS on OS 2. On a similar note, we should engage the NetApp = folk and Sun folk; I'm suspect NetApp does not support our notion of = meta-data EAs with atomicity properties, and I'm pretty sure Sun = doesn't. However, if there will be standards, getting their buy-in early = makes sense. FreeBSD currently doesn't implement Sun's NFSv3 ACL extension, which I = believe is what Linux implements, but probably should. If we're going to = standardize the EA RPC interface, we should also standardize the ACL = interface, and then someone in FreeBSD land can implement it as well = :-). And that probably means extending the existing ACL extension: we = will need to support NFSv4 ACLs with NFSv3, since we can use both POSIX = and NFSv4 ACLs on disk in FreeBSD, and the leaning is towards NFSv4 ACLs = for everything these days. Mac OS X uses NTFS ACLs, which are (in many = ways) similar to NFSv4 ACLs and also might be interested. Something that's always worried me about the Mac OS X and Linux EA APIs = is the namespace issue: in FreeBSD, we have an explicit enumeration of = namespaces reflected in an argument to the system calls -- in our case, = an int, but you could imagine other options. As I recall, Linux (perhaps = also IRIX?) designated "system" EAs via an interpretation of names ('$' = prefix). Mac OS X doesn't do this, or at least, the namespace is = different. I wonder given the portability concerns: would it make sense = to make the NFS wire protocol identify the namespace explicitly, and = then OSes can map to/from their local implementation semantics? Linux = could strip the '$' before putting the name on the wire and select the = system namespace in the RPC, whereas FreeBSD could map its local notion = of EXTATTR_NAMESPACE_SYSTEM into whatever the NFS constant is. Then when = it pops out the other end, mapping back to local semantics would occur. = This seems more likely to get the security right (in FreeBSD, writing to = the system namespace requires a specific privilege in our privilege = system), and is an adequate superset of all the APIs to be useful. On a related note, it might make sense to review current consumers of = the EA API and decide if we want to standardize a system call API as = well -- current API consumers have a bit of a hard time right now due to = the differences across all major UNIX platforms, which is silly. = Especially if we have an NFS EA RPC in flight, taking this opportunity = to nail down a new, portable, system call API would be opportune. = Obviously, we'd need to think about the namespace issue, but also = atomicity issues: one of the guarantees we provide in FreeBSD is that EA = writes are atomic with respect to other simultaneous users, and we also = try really hard to provide strong atomicity properties with respect to = persistence (i.e., in the event of a crash you will get $oldlabel for = MAC, or $newlabel, but not half of each). Further, we offer = transactional semantics in our VFS layer, but that isn't exposed to = userspace. This allows atomic update of several EAs at once as required = by our MAC environment (if you run with two policies and both update = labels simultaneously, it will be atomic). Something to think about = offering via system calls, I suppose, but I worry that pushes the edge a = bit far on UNIX APIs. :-) I'm happy to help contribute to the writing on an Internet Draft and/or = RFC -- the lack of NFS support for EAs (and the EA vs. file fork = confusion) have long caused me frustration, and with systems like = SELinux, our various MAC policies, and all sorts of other things = floating around, there's a strong motivation to fix this ... in a = portable way! I'm just sorry I haven't gotten to this sooner... I've added Rick Macklem to the CC line since he did both our original = NFS code, and our more recent NFSv4 code, and is a long-time participant = in the NFS community. Could we set up a phone call to chat about all this? Things are really = busy here this summer, both for good and bad reasons, but a phone call = on East Coast time is usually arrangeable for me (I'm mostly on British = time). Any chance you might be at USENIX Security in DC this August? Another Robert= From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 2 21:51:17 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F177106564A for ; Fri, 2 Jul 2010 21:51:17 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 291258FC16 for ; Fri, 2 Jul 2010 21:51:16 +0000 (UTC) Received: by iwn35 with SMTP id 35so1717766iwn.13 for ; Fri, 02 Jul 2010 14:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=2LGtRDDOttbBMdLxrWO5eWXlvqSqkPQNgeVxrBsbfJc=; b=MLylhwo0a98NYsAoVq4hBrJQ+gAWbK1qma9R99Ag8a/ldbcSLFIYGwLJaIApjnziGJ cY/ziIKZFEU3q6cp00JoREfa1LoKa7HdSkwMcCahHOTQGIVRbsDVQ69+EId+Q5H6GAZc 6OzKkQ648TVUSTrwf/KhxaRyOnpRPqHcCWil4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ccGVLEQybWjjErcqZ4qkkmhSIvvp+OF066HNhJgcuvOHzssCQQVoCusAg+XULygWN7 QF9HM3I5eoqVxrcxh2yLqPWoD770ntsoFjLcquZ930MCkcYYv0HWLRRBZN+nhdBcQLhO xeIMyx4m84hz9X1nruCeKYkJqpfrEj2pCeTWI= MIME-Version: 1.0 Received: by 10.42.6.75 with SMTP id 11mr462397icz.38.1278107476266; Fri, 02 Jul 2010 14:51:16 -0700 (PDT) Received: by 10.42.5.78 with HTTP; Fri, 2 Jul 2010 14:51:16 -0700 (PDT) Date: Fri, 2 Jul 2010 14:51:16 -0700 Message-ID: From: Matthew Fleming To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Using lex in a shared library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 21:51:17 -0000 I have the following Makefile for a shared library at $work: ISI_TOP= ../.. LIB= isi_date SHLIB_MAJOR= 1 SHLIB_MINOR= 0 SRCS= date.c date_parser.new.c lex.yy.c INCS= date.h INCLUDEDIR= /usr/include/isi_date YFLAGS+= -vt FLEX= /usr/bin/flex LDADD= -ll CLEANFILES+= date_parser.new.c y.tab.h y.tab.c lex.yy.c y.output \ check_date.log test lex.yy.c: date_lexer.new.l ${FLEX} $> CFLAGS+= -I${.CURDIR} #CFLAGS+= -g .include "${ISI_TOP}/isi.lib.mk" This builds fine as on i386. I'm trying to get all our user-space to be 64-bit clean, and I run into an error when building on amd64: /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/bin/ld: /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.a(libyywrap.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.a: could not read symbols: Bad value The following diff makes the compile work, but I have no idea (yet) whether this will run, if it's the right solution, etc. Index: usr.bin/lex/lib/Makefile =================================================================== --- usr.bin/lex/lib/Makefile (revision 153343) +++ usr.bin/lex/lib/Makefile (working copy) @@ -4,11 +4,16 @@ LIB= ln SRCS= libmain.c libyywrap.c -NO_PIC= +#NO_PIC= +SHLIB_MAJOR= 1 +SHLIB_MINOR= 0 + .if ${MK_INSTALLLIB} != "no" LINKS= ${LIBDIR}/libln.a ${LIBDIR}/libl.a LINKS+= ${LIBDIR}/libln.a ${LIBDIR}/libfl.a +LINKS+= ${LIBDIR}/libln.so ${LIBDIR}/libl.so +LINKS+= ${LIBDIR}/libln${LIB_SUFFIX}.so ${LIBDIR}/libl${LIB_SUFFIX}.so .endif .if ${MK_PROFILE} != "no" Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 2 21:54:29 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 968D1106564A for ; Fri, 2 Jul 2010 21:54:29 +0000 (UTC) (envelope-from herron.philip@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 286668FC13 for ; Fri, 2 Jul 2010 21:54:28 +0000 (UTC) Received: by wyb34 with SMTP id 34so2365591wyb.13 for ; Fri, 02 Jul 2010 14:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=cju5as+CsoJa6I7OvpCD+si+6rFDTOqx4MNkJlSRpBc=; b=nZ3WascP3l/0sBtM39sRWdh3TcRA+V7ciLF8vcFjnH/xE1pD96khuFJpzLNuWFUdCn LiavWVyWBEoQ+HWX5phic1VZhs+lntVf1ce++4bsddOQRe4TfQINp1XxpoIGfaq9voJ5 Fa6qsFcf4NvthgP5zEsNbkjH04MN1puU8rCIg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=iDsUgSBux5bpPvIoSWupwxFBdCF1ilgqlBIfJDunAJ1A70dbtS5PBZy+8BHgPWoIn4 B33WqztAEx7i1+K2g/YsPUVUyDk42FhIWIwDgu0Vd8uYNmjJySuoP4/0wl+qKbLSuzxr cwqM3mg1t256DcXvAiyLQ1sbJtVsHPVq03ya0= MIME-Version: 1.0 Received: by 10.227.128.213 with SMTP id l21mr805219wbs.166.1278107660915; Fri, 02 Jul 2010 14:54:20 -0700 (PDT) Sender: herron.philip@googlemail.com Received: by 10.216.13.9 with HTTP; Fri, 2 Jul 2010 14:54:20 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 Jul 2010 22:54:20 +0100 X-Google-Sender-Auth: H27I7jLcXAjznOKeoU0Wl3NynW0 Message-ID: From: Philip Herron To: Matthew Fleming Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Using lex in a shared library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 21:54:29 -0000 On 2 July 2010 22:51, Matthew Fleming wrote: > I have the following Makefile for a shared library at $work: > > ISI_TOP=3D =A0 =A0 =A0 =A0../.. > > LIB=3D =A0 =A0 =A0 =A0 =A0 =A0isi_date > SHLIB_MAJOR=3D =A0 =A01 > SHLIB_MINOR=3D =A0 =A00 > SRCS=3D =A0 =A0 =A0 =A0 =A0 date.c date_parser.new.c lex.yy.c > INCS=3D =A0 =A0 =A0 =A0 =A0 date.h > INCLUDEDIR=3D =A0 =A0 /usr/include/isi_date > > YFLAGS+=3D =A0 =A0 =A0 =A0-vt > FLEX=3D =A0 =A0 =A0 =A0 =A0 /usr/bin/flex > LDADD=3D =A0 =A0 =A0 =A0 =A0-ll > > CLEANFILES+=3D =A0 =A0date_parser.new.c y.tab.h y.tab.c lex.yy.c y.output= \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0check_date.log test > > lex.yy.c: date_lexer.new.l > =A0 =A0 =A0 =A0${FLEX} $> > > CFLAGS+=3D =A0 =A0 =A0 =A0-I${.CURDIR} > #CFLAGS+=3D =A0 =A0 =A0 -g > > .include "${ISI_TOP}/isi.lib.mk" > > > > This builds fine as on i386. =A0I'm trying to get all our user-space to > be 64-bit clean, and I run into an error when building on amd64: > > /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/bin/ld: > /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.a= (libyywrap.o): > relocation R_X86_64_32 can not be used when making a shared object; > recompile with -fPIC > /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.a= : > could not read symbols: Bad value > > The following diff makes the compile work, but I have no idea (yet) > whether this will run, if it's the right solution, etc. > > > Index: usr.bin/lex/lib/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- usr.bin/lex/lib/Makefile =A0 =A0(revision 153343) > +++ usr.bin/lex/lib/Makefile =A0 =A0(working copy) > @@ -4,11 +4,16 @@ > > =A0LIB=3D =A0 =A0ln > =A0SRCS=3D =A0 libmain.c libyywrap.c > -NO_PIC=3D > +#NO_PIC=3D > > +SHLIB_MAJOR=3D =A0 1 > +SHLIB_MINOR=3D =A0 0 > + > =A0.if ${MK_INSTALLLIB} !=3D "no" > =A0LINKS=3D =A0${LIBDIR}/libln.a ${LIBDIR}/libl.a > =A0LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln.a ${LIBDIR}/libfl.a > +LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln.so ${LIBDIR}/libl.so > +LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln${LIB_SUFFIX}.so ${LIBDIR}/libl$= {LIB_SUFFIX}.so > =A0.endif > > =A0.if ${MK_PROFILE} !=3D "no" > > > Thanks, > matthew > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > Although maybe not helpful but have you considered using automake/libtool instead makes it so much simpler in my opinion. --Phil From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 2 22:31:47 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEE0B1065670 for ; Fri, 2 Jul 2010 22:31:47 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 73B228FC0A for ; Fri, 2 Jul 2010 22:31:47 +0000 (UTC) Received: by iwn35 with SMTP id 35so1753009iwn.13 for ; Fri, 02 Jul 2010 15:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tplUIfe28pliCQEz/sFuDLTQssUKveXRvU2aKpvvzbg=; b=ln09jSQoVvyx2sOgsSNpBYhD+5W3WkpNj+wcGNI/NFVbGNLsvM5x/YrP7RNeC/NSPh /yHNbWTvhGQtd5OKHocRnjYakbswSSe5Dd9GtVZ55hXETO/68omnMouo0E2INBIqqSLC F+R3kMN3Mc2eXHWH5DId1IVdl8m3j2bVFanXc= 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=pJ+mTPy8Xga/GAEHabI03/0t5phiVKjdmXlle+nemk3EHkXvngCFOdIgiSFZO2sOEf sCrzOo0w1bFMseMo7CYL4p2LPTUD+BHycYagK3EQlGpDy1lIIaGrnOAMoKle52SjXNu7 GCgJfPy7arCIQp1zHXEUmt6BAZ/9uLVlHabaM= MIME-Version: 1.0 Received: by 10.42.9.4 with SMTP id k4mr504056ick.72.1278109906798; Fri, 02 Jul 2010 15:31:46 -0700 (PDT) Received: by 10.42.5.78 with HTTP; Fri, 2 Jul 2010 15:31:46 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 Jul 2010 15:31:46 -0700 Message-ID: From: Matthew Fleming To: Philip Herron Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Using lex in a shared library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 22:31:47 -0000 On Fri, Jul 2, 2010 at 2:54 PM, Philip Herron wrote: > On 2 July 2010 22:51, Matthew Fleming wrote: >> I have the following Makefile for a shared library at $work: >> >> ISI_TOP=3D =A0 =A0 =A0 =A0../.. >> >> LIB=3D =A0 =A0 =A0 =A0 =A0 =A0isi_date >> SHLIB_MAJOR=3D =A0 =A01 >> SHLIB_MINOR=3D =A0 =A00 >> SRCS=3D =A0 =A0 =A0 =A0 =A0 date.c date_parser.new.c lex.yy.c >> INCS=3D =A0 =A0 =A0 =A0 =A0 date.h >> INCLUDEDIR=3D =A0 =A0 /usr/include/isi_date >> >> YFLAGS+=3D =A0 =A0 =A0 =A0-vt >> FLEX=3D =A0 =A0 =A0 =A0 =A0 /usr/bin/flex >> LDADD=3D =A0 =A0 =A0 =A0 =A0-ll >> >> CLEANFILES+=3D =A0 =A0date_parser.new.c y.tab.h y.tab.c lex.yy.c y.outpu= t \ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0check_date.log test >> >> lex.yy.c: date_lexer.new.l >> =A0 =A0 =A0 =A0${FLEX} $> >> >> CFLAGS+=3D =A0 =A0 =A0 =A0-I${.CURDIR} >> #CFLAGS+=3D =A0 =A0 =A0 -g >> >> .include "${ISI_TOP}/isi.lib.mk" >> >> >> >> This builds fine as on i386. =A0I'm trying to get all our user-space to >> be 64-bit clean, and I run into an error when building on amd64: >> >> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/bin/ld: >> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.= a(libyywrap.o): >> relocation R_X86_64_32 can not be used when making a shared object; >> recompile with -fPIC >> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.= a: >> could not read symbols: Bad value >> >> The following diff makes the compile work, but I have no idea (yet) >> whether this will run, if it's the right solution, etc. >> >> >> Index: usr.bin/lex/lib/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- usr.bin/lex/lib/Makefile =A0 =A0(revision 153343) >> +++ usr.bin/lex/lib/Makefile =A0 =A0(working copy) >> @@ -4,11 +4,16 @@ >> >> =A0LIB=3D =A0 =A0ln >> =A0SRCS=3D =A0 libmain.c libyywrap.c >> -NO_PIC=3D >> +#NO_PIC=3D >> >> +SHLIB_MAJOR=3D =A0 1 >> +SHLIB_MINOR=3D =A0 0 >> + >> =A0.if ${MK_INSTALLLIB} !=3D "no" >> =A0LINKS=3D =A0${LIBDIR}/libln.a ${LIBDIR}/libl.a >> =A0LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln.a ${LIBDIR}/libfl.a >> +LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln.so ${LIBDIR}/libl.so >> +LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln${LIB_SUFFIX}.so ${LIBDIR}/libl= ${LIB_SUFFIX}.so >> =A0.endif >> >> =A0.if ${MK_PROFILE} !=3D "no" > > Although maybe not helpful but have you considered using > automake/libtool instead makes it so much simpler in my opinion. Instead of... ? Instead of this makefile? Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 2 22:47:59 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E6AB106564A for ; Fri, 2 Jul 2010 22:47:59 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.sonnenberger.org (www.sonnenberger.org [92.79.50.50]) by mx1.freebsd.org (Postfix) with ESMTP id E4F718FC0A for ; Fri, 2 Jul 2010 22:47:58 +0000 (UTC) Received: from britannica.bec.de (www.sonnenberger.org [192.168.1.10]) by www.sonnenberger.org (Postfix) with ESMTP id 8BA07667AE for ; Sat, 3 Jul 2010 00:47:41 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id 7FBFA15096; Sat, 3 Jul 2010 00:45:37 +0200 (CEST) Date: Sat, 3 Jul 2010 00:45:36 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20100702224536.GA12251@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Using lex in a shared library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 22:47:59 -0000 On Fri, Jul 02, 2010 at 02:51:16PM -0700, Matthew Fleming wrote: > LDADD= -ll Have you considered providing your own yywrap function instead? (Or not using it at all?) Joerg From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 2 22:53:24 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D9A41065675 for ; Fri, 2 Jul 2010 22:53:24 +0000 (UTC) (envelope-from herron.philip@googlemail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E35888FC0A for ; Fri, 2 Jul 2010 22:53:23 +0000 (UTC) Received: by wwd20 with SMTP id 20so184945wwd.31 for ; Fri, 02 Jul 2010 15:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=G47u/+R7EXmMXVdNgmGwtJCfesE73jshdff62FWKmjs=; b=O4ROv+6wWqSXJ6i6aRCQTmqIlJ0InAROGmsJDAiVdZ4PCOoBBe24yQfsWueBpjqnDV SueLotNtBkQs3YCvcIjg8UFMk3YueJ/bJWRH5JqTmHMc7xvQLbJdyDNbd5UqfJ3Bu2yF lU4OWu2AbyS9ALsPEYLLR6aiLO4WlIUZUrmms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=bgeL8M/ZzlvWUzi4gz3fNG7XX4ELpDd/jcx13xnLFjHum3qQMtIkRwrVO+fx+Xkhgb XWJ/QWMNo6VWoUkoj7V6T65QY3YMSn58BIjF5wu79QB6Iq7z6sUqVg/YxBc4fDc/K85o zveUfFnDZ/aIg2aMonq3NxFCK4KL+USDmFO+Q= MIME-Version: 1.0 Received: by 10.227.151.138 with SMTP id c10mr866360wbw.46.1278111197573; Fri, 02 Jul 2010 15:53:17 -0700 (PDT) Sender: herron.philip@googlemail.com Received: by 10.216.13.9 with HTTP; Fri, 2 Jul 2010 15:53:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 Jul 2010 23:53:17 +0100 X-Google-Sender-Auth: 8Jblp_n96r3N1R9pJchPsEKV7XE Message-ID: From: Philip Herron To: Matthew Fleming Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Using lex in a shared library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 22:53:24 -0000 On 2 July 2010 23:31, Matthew Fleming wrote: > On Fri, Jul 2, 2010 at 2:54 PM, Philip Herron wrot= e: >> On 2 July 2010 22:51, Matthew Fleming wrote: >>> I have the following Makefile for a shared library at $work: >>> >>> ISI_TOP=3D =A0 =A0 =A0 =A0../.. >>> >>> LIB=3D =A0 =A0 =A0 =A0 =A0 =A0isi_date >>> SHLIB_MAJOR=3D =A0 =A01 >>> SHLIB_MINOR=3D =A0 =A00 >>> SRCS=3D =A0 =A0 =A0 =A0 =A0 date.c date_parser.new.c lex.yy.c >>> INCS=3D =A0 =A0 =A0 =A0 =A0 date.h >>> INCLUDEDIR=3D =A0 =A0 /usr/include/isi_date >>> >>> YFLAGS+=3D =A0 =A0 =A0 =A0-vt >>> FLEX=3D =A0 =A0 =A0 =A0 =A0 /usr/bin/flex >>> LDADD=3D =A0 =A0 =A0 =A0 =A0-ll >>> >>> CLEANFILES+=3D =A0 =A0date_parser.new.c y.tab.h y.tab.c lex.yy.c y.outp= ut \ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0check_date.log test >>> >>> lex.yy.c: date_lexer.new.l >>> =A0 =A0 =A0 =A0${FLEX} $> >>> >>> CFLAGS+=3D =A0 =A0 =A0 =A0-I${.CURDIR} >>> #CFLAGS+=3D =A0 =A0 =A0 -g >>> >>> .include "${ISI_TOP}/isi.lib.mk" >>> >>> >>> >>> This builds fine as on i386. =A0I'm trying to get all our user-space to >>> be 64-bit clean, and I run into an error when building on amd64: >>> >>> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/bin/ld: >>> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl= .a(libyywrap.o): >>> relocation R_X86_64_32 can not be used when making a shared object; >>> recompile with -fPIC >>> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl= .a: >>> could not read symbols: Bad value >>> >>> The following diff makes the compile work, but I have no idea (yet) >>> whether this will run, if it's the right solution, etc. >>> >>> >>> Index: usr.bin/lex/lib/Makefile >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- usr.bin/lex/lib/Makefile =A0 =A0(revision 153343) >>> +++ usr.bin/lex/lib/Makefile =A0 =A0(working copy) >>> @@ -4,11 +4,16 @@ >>> >>> =A0LIB=3D =A0 =A0ln >>> =A0SRCS=3D =A0 libmain.c libyywrap.c >>> -NO_PIC=3D >>> +#NO_PIC=3D >>> >>> +SHLIB_MAJOR=3D =A0 1 >>> +SHLIB_MINOR=3D =A0 0 >>> + >>> =A0.if ${MK_INSTALLLIB} !=3D "no" >>> =A0LINKS=3D =A0${LIBDIR}/libln.a ${LIBDIR}/libl.a >>> =A0LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln.a ${LIBDIR}/libfl.a >>> +LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln.so ${LIBDIR}/libl.so >>> +LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln${LIB_SUFFIX}.so ${LIBDIR}/lib= l${LIB_SUFFIX}.so >>> =A0.endif >>> >>> =A0.if ${MK_PROFILE} !=3D "no" >> >> Although maybe not helpful but have you considered using >> automake/libtool instead makes it so much simpler in my opinion. > > Instead of... ? =A0Instead of this makefile? > > Thanks, > matthew > Yeah to create your self a shared library using automake: $ rm Makefile $ cat >> Makefile.am <.la libcrules_la_LDFLAGS =3D -release 0.5.0 libcrules_la_SOURCES =3D ss_parser.y \ ss_lexical.l \ bb_backend.c \ ... EOF Automake will auto-handle Lex and Yacc files too. And is extremely portable= . $ automake --gnu --add-missing --copy --force This will generate you all the Makefie.in files recursively over your work dir. When building these Makefile.in you only need do it once really, unless you change your makefile.am files. The makefiles.in are designed to be portable. All they need is some configuration though autoconf to tell it what compiler to use etc. --Phil From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 2 23:03:01 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED9FE1065672 for ; Fri, 2 Jul 2010 23:03:00 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A21828FC0C for ; Fri, 2 Jul 2010 23:02:57 +0000 (UTC) Received: by vws6 with SMTP id 6so3955756vws.13 for ; Fri, 02 Jul 2010 16:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xV5NuL6Ou0SRvuIbCec9PgkoClFpR6lKMVpxr4BCI1I=; b=KYtLGbv+a0CM0odAuqII6VFbbyroe5TjH68TPoIMifVlqqn1f7GhH010ZFuyfn6ZaU zsw2hvm0gV57cI8QAYSz6x/dJ18X+DB1BXVtSqwZvf/0QSFxZ3kN/eep09CmdaUFzr0j UNdifrWDYjlgsjscCw8+comNGrAl0nR7JrygM= 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=GI5/n2UwEDbZzTiR76aILoapVc9L+BDmmghU8uLwlFCd+FzbfpjzbFQcYljwXiZiPg 3F/IUnbY7OqVlesXh8PERtW4iQfyEflPEENMUfmisW8Ta6iv+BrpVHP4FiosB50S9ebE wb41/mr8gaYm3lsstPzVzsLgzp4Itkadic6Jk= MIME-Version: 1.0 Received: by 10.229.189.12 with SMTP id dc12mr382493qcb.10.1278111770615; Fri, 02 Jul 2010 16:02:50 -0700 (PDT) Received: by 10.229.192.201 with HTTP; Fri, 2 Jul 2010 16:02:50 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 Jul 2010 16:02:50 -0700 Message-ID: From: Garrett Cooper To: Matthew Fleming Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Using lex in a shared library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 23:03:01 -0000 On Fri, Jul 2, 2010 at 2:51 PM, Matthew Fleming wrote: > I have the following Makefile for a shared library at $work: > > ISI_TOP=3D =A0 =A0 =A0 =A0../.. > > LIB=3D =A0 =A0 =A0 =A0 =A0 =A0isi_date > SHLIB_MAJOR=3D =A0 =A01 > SHLIB_MINOR=3D =A0 =A00 > SRCS=3D =A0 =A0 =A0 =A0 =A0 date.c date_parser.new.c lex.yy.c > INCS=3D =A0 =A0 =A0 =A0 =A0 date.h > INCLUDEDIR=3D =A0 =A0 /usr/include/isi_date > > YFLAGS+=3D =A0 =A0 =A0 =A0-vt > FLEX=3D =A0 =A0 =A0 =A0 =A0 /usr/bin/flex > LDADD=3D =A0 =A0 =A0 =A0 =A0-ll > > CLEANFILES+=3D =A0 =A0date_parser.new.c y.tab.h y.tab.c lex.yy.c y.output= \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0check_date.log test > > lex.yy.c: date_lexer.new.l > =A0 =A0 =A0 =A0${FLEX} $> > > CFLAGS+=3D =A0 =A0 =A0 =A0-I${.CURDIR} > #CFLAGS+=3D =A0 =A0 =A0 -g > > .include "${ISI_TOP}/isi.lib.mk" > > > > This builds fine as on i386. =A0I'm trying to get all our user-space to > be 64-bit clean, and I run into an error when building on amd64: > > /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/bin/ld: > /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.a= (libyywrap.o): > relocation R_X86_64_32 can not be used when making a shared object; > recompile with -fPIC > /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.a= : > could not read symbols: Bad value > > The following diff makes the compile work, but I have no idea (yet) > whether this will run, if it's the right solution, etc. > > > Index: usr.bin/lex/lib/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- usr.bin/lex/lib/Makefile =A0 =A0(revision 153343) > +++ usr.bin/lex/lib/Makefile =A0 =A0(working copy) > @@ -4,11 +4,16 @@ > > =A0LIB=3D =A0 =A0ln > =A0SRCS=3D =A0 libmain.c libyywrap.c > -NO_PIC=3D > +#NO_PIC=3D > > +SHLIB_MAJOR=3D =A0 1 > +SHLIB_MINOR=3D =A0 0 > + > =A0.if ${MK_INSTALLLIB} !=3D "no" > =A0LINKS=3D =A0${LIBDIR}/libln.a ${LIBDIR}/libl.a > =A0LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln.a ${LIBDIR}/libfl.a > +LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln.so ${LIBDIR}/libl.so > +LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln${LIB_SUFFIX}.so ${LIBDIR}/libl$= {LIB_SUFFIX}.so > =A0.endif > > =A0.if ${MK_PROFILE} !=3D "no" The static-only version was done on purpose: Revision 1.2: download - view: text, markup, annotated - select for diffs Thu Aug 25 23:11:07 1994 UTC (15 years, 10 months ago) by wollman Branches: MAIN CVS tags: RELENG_2_1_7_RELEASE, RELENG_2_1_6_RELEASE, RELENG_2_1_6_1_RELEASE, RELENG_2_1_5_RELEASE, RELENG_2_1_0_RELEASE, RELENG_2_1_0_BP, RELENG_2_0_5_RELEASE, RELENG_2_0_5_BP, RELENG_2_0_5_ALPHA, RELENG_2_0_5, RELEASE_2_0, BETA_2_0, ALPHA_2_0 Branch point for: RELENG_2_1_0 Diff to: previous 1.1: preferred, colored Changes since revision 1.1: +2 -8 lines We really, really /don't/ want to have a shared lex library. Also, current users should note that the old 1.1.5 lex can't process the new scan.l, so you have to copy initscan.c to obj/scan.c before it will build. Garrett Wollman probably has more information about why this was done. I think that fixing the lib to build with the appropriate options (not -m32, or CPUTYPE =3D> some 32-bit x86 variant, etc) is what really needs to be done here. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 2 23:05:33 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66361106566C for ; Fri, 2 Jul 2010 23:05:33 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 148398FC08 for ; Fri, 2 Jul 2010 23:05:32 +0000 (UTC) Received: by vws6 with SMTP id 6so3958408vws.13 for ; Fri, 02 Jul 2010 16:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tvmEcjMzbKssSNXFxpambnprUDvkn2shYkx8ukDr0h8=; b=qb8S+sARI93JjkmXuwh+DN6mwII1kywoVKalMbpMTW+J4d3nrnQJWuqDRsLX54ytH8 9JCUyUWT+5wUUD78Ywscq5+hqbivJrSxa4hpL6rq0IklZR+m56tss4ks5Ttg+bxVz2Cv G3ZOJp4ah5/6n7AJwgYUW4Aky+fIGP1jAy8U0= 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=HIxKsBx/LgFHorP4arxCCCjO4JQmCAZyd5MUj6ZiQN53LAP1qFRHtSFXW+xifmjo2p Ql6DKE1nlRj6dbxGDbKuiqLnSe17nqeg0M8cZI/7vW35T6oJ8P7ewdnn+EewFf8xarIk LX4ETM8OA0WkZsON8o+p9CcJBTPqODqIRlVnE= MIME-Version: 1.0 Received: by 10.229.230.3 with SMTP id jk3mr987638qcb.214.1278111928234; Fri, 02 Jul 2010 16:05:28 -0700 (PDT) Received: by 10.229.192.201 with HTTP; Fri, 2 Jul 2010 16:05:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 Jul 2010 16:05:28 -0700 Message-ID: From: Garrett Cooper To: Philip Herron Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Matthew Fleming Subject: Re: Using lex in a shared library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 23:05:33 -0000 On Fri, Jul 2, 2010 at 3:53 PM, Philip Herron wrote: > On 2 July 2010 23:31, Matthew Fleming wrote: >> On Fri, Jul 2, 2010 at 2:54 PM, Philip Herron wro= te: >>> Although maybe not helpful but have you considered using >>> automake/libtool instead makes it so much simpler in my opinion. >> >> Instead of... ? =A0Instead of this makefile? > > Yeah to create your self a shared library using automake: ... > This will generate you all the Makefie.in files recursively over your > work dir. When building these Makefile.in you only need do it once > really, unless you change your makefile.am files. The makefiles.in are > designed to be portable. All they need is some configuration though > autoconf to tell it what compiler to use etc. Why create a dependency on several ports (which tends to be painful to maintain) instead of using what's available to you in the base system? Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 2 23:34:29 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAC3F106566B for ; Fri, 2 Jul 2010 23:34:29 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF54A8FC15 for ; Fri, 2 Jul 2010 23:34:29 +0000 (UTC) Received: by iwn35 with SMTP id 35so1800683iwn.13 for ; Fri, 02 Jul 2010 16:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cs4oBMDvH741PYW5L4xERSGRNicts+o1Se6LsNXOXzM=; b=xod0SVgi1j023bndRiF7LH+cW+RutlwnK5H2aJSwVIgXJ9Z1+4kA7dCqTy5gGnefQa iotLc6ZfCJzOQbkxKHiXzVis/Ev9wYjfqF9SX6Nrdugf8SX9KEWAS9ZaS/80b+MQ01m6 wZyf6GbfDCud962HsxJQY4cjeBka1Aw8/db+4= 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=AD5TcG680kmVyEkJB3HTA5AXQlu67iimX5uXEnuLKLRRMCc+nJa1HJLc3zTPsoE7Dv aSKPfxJyCsK2QU39aESYy3Xj5lp6m9fgrw+PKYNaZ3MO8SKDcVxCgy4pthXV8Yo8OPtW OBL1JiDFquAjqxwsuwSmfZ2v6EPL5vCf+oDBQ= MIME-Version: 1.0 Received: by 10.42.6.75 with SMTP id 11mr491733icz.38.1278113668957; Fri, 02 Jul 2010 16:34:28 -0700 (PDT) Received: by 10.42.5.78 with HTTP; Fri, 2 Jul 2010 16:34:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 Jul 2010 16:34:28 -0700 Message-ID: From: Matthew Fleming To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Using lex in a shared library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 23:34:30 -0000 On Fri, Jul 2, 2010 at 4:02 PM, Garrett Cooper wrote: > On Fri, Jul 2, 2010 at 2:51 PM, Matthew Fleming wrote: >> I have the following Makefile for a shared library at $work: >> >> ISI_TOP=3D =A0 =A0 =A0 =A0../.. >> >> LIB=3D =A0 =A0 =A0 =A0 =A0 =A0isi_date >> SHLIB_MAJOR=3D =A0 =A01 >> SHLIB_MINOR=3D =A0 =A00 >> SRCS=3D =A0 =A0 =A0 =A0 =A0 date.c date_parser.new.c lex.yy.c >> INCS=3D =A0 =A0 =A0 =A0 =A0 date.h >> INCLUDEDIR=3D =A0 =A0 /usr/include/isi_date >> >> YFLAGS+=3D =A0 =A0 =A0 =A0-vt >> FLEX=3D =A0 =A0 =A0 =A0 =A0 /usr/bin/flex >> LDADD=3D =A0 =A0 =A0 =A0 =A0-ll >> >> CLEANFILES+=3D =A0 =A0date_parser.new.c y.tab.h y.tab.c lex.yy.c y.outpu= t \ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0check_date.log test >> >> lex.yy.c: date_lexer.new.l >> =A0 =A0 =A0 =A0${FLEX} $> >> >> CFLAGS+=3D =A0 =A0 =A0 =A0-I${.CURDIR} >> #CFLAGS+=3D =A0 =A0 =A0 -g >> >> .include "${ISI_TOP}/isi.lib.mk" >> >> >> >> This builds fine as on i386. =A0I'm trying to get all our user-space to >> be 64-bit clean, and I run into an error when building on amd64: >> >> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/bin/ld: >> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.= a(libyywrap.o): >> relocation R_X86_64_32 can not be used when making a shared object; >> recompile with -fPIC >> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.= a: >> could not read symbols: Bad value >> >> The following diff makes the compile work, but I have no idea (yet) >> whether this will run, if it's the right solution, etc. >> >> >> Index: usr.bin/lex/lib/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- usr.bin/lex/lib/Makefile =A0 =A0(revision 153343) >> +++ usr.bin/lex/lib/Makefile =A0 =A0(working copy) >> @@ -4,11 +4,16 @@ >> >> =A0LIB=3D =A0 =A0ln >> =A0SRCS=3D =A0 libmain.c libyywrap.c >> -NO_PIC=3D >> +#NO_PIC=3D >> >> +SHLIB_MAJOR=3D =A0 1 >> +SHLIB_MINOR=3D =A0 0 >> + >> =A0.if ${MK_INSTALLLIB} !=3D "no" >> =A0LINKS=3D =A0${LIBDIR}/libln.a ${LIBDIR}/libl.a >> =A0LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln.a ${LIBDIR}/libfl.a >> +LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln.so ${LIBDIR}/libl.so >> +LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln${LIB_SUFFIX}.so ${LIBDIR}/libl= ${LIB_SUFFIX}.so >> =A0.endif >> >> =A0.if ${MK_PROFILE} !=3D "no" > > The static-only version was done on purpose: > > Revision 1.2: download - view: text, markup, annotated =A0- select for di= ffs > Thu Aug 25 23:11:07 1994 UTC (15 years, 10 months ago) by wollman > Branches: MAIN > CVS tags: RELENG_2_1_7_RELEASE, RELENG_2_1_6_RELEASE, > RELENG_2_1_6_1_RELEASE, RELENG_2_1_5_RELEASE, RELENG_2_1_0_RELEASE, > RELENG_2_1_0_BP, RELENG_2_0_5_RELEASE, RELENG_2_0_5_BP, > RELENG_2_0_5_ALPHA, RELENG_2_0_5, RELEASE_2_0, BETA_2_0, ALPHA_2_0 > Branch point for: RELENG_2_1_0 > Diff to: previous 1.1: preferred, colored > Changes since revision 1.1: +2 -8 lines > > We really, really /don't/ want to have a shared lex library. =A0Also, > current users should note that the old 1.1.5 lex can't process the > new scan.l, so you have to copy initscan.c to obj/scan.c before it will > build. > > Garrett Wollman probably has more information about why this was done. > > I think that fixing the lib to build with the appropriate options (not > -m32, or CPUTYPE =3D> some 32-bit x86 variant, etc) is what really needs > to be done here. I guess I'm still confused. The isi_date library compiles fine if it's for i386, but switching to amd64 gives this error. Since I didn't specify any -m32 flags or anything, and it's essentially using the standard bsd.lib.mk magic, I am trying to figure out why the 32-bit isi_date.1.so built and the 64-bit one won't. Was the 32-bit version building successfully an unfortunate fluke? What build flags would get the shared library to link with -ll? Unfortunately, I didn't write this library, and I don't know anything about lex(1), so if I need my own yywrap() that might be fine, but I wouldn't have the first clue what to put in there. :-( Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 2 23:52:59 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE146106566C for ; Fri, 2 Jul 2010 23:52:59 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 327128FC08 for ; Fri, 2 Jul 2010 23:52:59 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 3A379A5A480; Sat, 3 Jul 2010 07:52:58 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id AQu8bQGWVL6b; Sat, 3 Jul 2010 07:52:52 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 8C0CAA5A47B; Sat, 3 Jul 2010 07:52:50 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=NXSxbpQkRtEFg2owCXKttGHcgD/RoT4kC5i0b1a8rvQ9B7yBPpkOMTf7YTAmPhU2g cQA3UxJvkx+tbp+bPw5Gg== Message-ID: <4C2E7BCD.4020609@delphij.net> Date: Fri, 02 Jul 2010 16:52:45 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100629 Thunderbird/3.0.5 ThunderBrowse/3.3 MIME-Version: 1.0 To: Matthew Fleming References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , freebsd-hackers@freebsd.org Subject: Re: Using lex in a shared library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 23:53:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/07/02 16:34, Matthew Fleming wrote: > On Fri, Jul 2, 2010 at 4:02 PM, Garrett Cooper wrote: >> On Fri, Jul 2, 2010 at 2:51 PM, Matthew Fleming wrote: >>> I have the following Makefile for a shared library at $work: >>> >>> ISI_TOP= ../.. >>> >>> LIB= isi_date >>> SHLIB_MAJOR= 1 >>> SHLIB_MINOR= 0 >>> SRCS= date.c date_parser.new.c lex.yy.c >>> INCS= date.h >>> INCLUDEDIR= /usr/include/isi_date >>> >>> YFLAGS+= -vt >>> FLEX= /usr/bin/flex >>> LDADD= -ll >>> >>> CLEANFILES+= date_parser.new.c y.tab.h y.tab.c lex.yy.c y.output \ >>> check_date.log test >>> >>> lex.yy.c: date_lexer.new.l >>> ${FLEX} $> >>> >>> CFLAGS+= -I${.CURDIR} >>> #CFLAGS+= -g >>> >>> .include "${ISI_TOP}/isi.lib.mk" >>> >>> >>> >>> This builds fine as on i386. I'm trying to get all our user-space to >>> be 64-bit clean, and I run into an error when building on amd64: >>> >>> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/bin/ld: >>> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.a(libyywrap.o): >>> relocation R_X86_64_32 can not be used when making a shared object; >>> recompile with -fPIC >>> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.a: >>> could not read symbols: Bad value >>> >>> The following diff makes the compile work, but I have no idea (yet) >>> whether this will run, if it's the right solution, etc. >>> >>> >>> Index: usr.bin/lex/lib/Makefile >>> =================================================================== >>> --- usr.bin/lex/lib/Makefile (revision 153343) >>> +++ usr.bin/lex/lib/Makefile (working copy) >>> @@ -4,11 +4,16 @@ >>> >>> LIB= ln >>> SRCS= libmain.c libyywrap.c >>> -NO_PIC= >>> +#NO_PIC= >>> >>> +SHLIB_MAJOR= 1 >>> +SHLIB_MINOR= 0 >>> + >>> .if ${MK_INSTALLLIB} != "no" >>> LINKS= ${LIBDIR}/libln.a ${LIBDIR}/libl.a >>> LINKS+= ${LIBDIR}/libln.a ${LIBDIR}/libfl.a >>> +LINKS+= ${LIBDIR}/libln.so ${LIBDIR}/libl.so >>> +LINKS+= ${LIBDIR}/libln${LIB_SUFFIX}.so ${LIBDIR}/libl${LIB_SUFFIX}.so >>> .endif >>> >>> .if ${MK_PROFILE} != "no" >> >> The static-only version was done on purpose: >> >> Revision 1.2: download - view: text, markup, annotated - select for diffs >> Thu Aug 25 23:11:07 1994 UTC (15 years, 10 months ago) by wollman >> Branches: MAIN >> CVS tags: RELENG_2_1_7_RELEASE, RELENG_2_1_6_RELEASE, >> RELENG_2_1_6_1_RELEASE, RELENG_2_1_5_RELEASE, RELENG_2_1_0_RELEASE, >> RELENG_2_1_0_BP, RELENG_2_0_5_RELEASE, RELENG_2_0_5_BP, >> RELENG_2_0_5_ALPHA, RELENG_2_0_5, RELEASE_2_0, BETA_2_0, ALPHA_2_0 >> Branch point for: RELENG_2_1_0 >> Diff to: previous 1.1: preferred, colored >> Changes since revision 1.1: +2 -8 lines >> >> We really, really /don't/ want to have a shared lex library. Also, >> current users should note that the old 1.1.5 lex can't process the >> new scan.l, so you have to copy initscan.c to obj/scan.c before it will >> build. >> >> Garrett Wollman probably has more information about why this was done. >> >> I think that fixing the lib to build with the appropriate options (not >> -m32, or CPUTYPE => some 32-bit x86 variant, etc) is what really needs >> to be done here. > > I guess I'm still confused. The isi_date library compiles fine if > it's for i386, but switching to amd64 gives this error. Since I > didn't specify any -m32 flags or anything, and it's essentially using > the standard bsd.lib.mk magic, I am trying to figure out why the > 32-bit isi_date.1.so built and the 64-bit one won't. Was the 32-bit > version building successfully an unfortunate fluke? What build flags > would get the shared library to link with -ll? I think that amd64 requires a static library be compiled with -fPIC if it's being linked into shared object. This should not be done for normal static libraries, though, as this could give some performance penalty when it's not needed (i.e. a static binary). > Unfortunately, I didn't write this library, and I don't know anything > about lex(1), so if I need my own yywrap() that might be fine, but I > wouldn't have the first clue what to put in there. :-( I think you could probably just change the code and use %option noyywrap in the .l file? (do your code call yywrap() directly?) Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMLnvNAAoJEATO+BI/yjfB5Z0IAKLkyPPdzjeA0XJiLC3yTPRl qzMHis5eo9rfFZgFpUzc22AQqxtu6pCYeovnESPiMkxG4r+Y20qQelJWEJs0nADT AOAqv1dftwnd+WDbdkUOdBwELOOghJerlPClrn8XV5WiBVSf0GUNWeITXbOUEe3n Urk5rINfoDwgXO1Xg/uxrEVsvJlCpzoKhS6ioQ8MW0QoBLk7WNujNakYqTYMCbLe yaVkB44ab8Epka+LyjCWQcGtevwE+YX847malrAhtW4RChMEvIzZ9o76vAWPAo6q 8DRjRdN1xtC9hx3yH97kv3nFNMnvYRVCOTiVuatQKDCri60WyQ7vlhyi/zCw5jg= =Vzkj -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 2 23:54:30 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3A7D1065678 for ; Fri, 2 Jul 2010 23:54:30 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id C6F9F8FC1C for ; Fri, 2 Jul 2010 23:54:28 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 775FDA5A48F; Sat, 3 Jul 2010 07:54:27 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id uRlZbXHDcpQZ; Sat, 3 Jul 2010 07:54:21 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id A8060A5A47B; Sat, 3 Jul 2010 07:54:19 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=lU5xJqUTSnur/NWtPDYTLRwnRqD9iqCWLm5rUuuQvQ2HIbdhYbDLvCR4KAN1TQiUq 4lbdJALtYXte1vMn3B5Cg== Message-ID: <4C2E7C29.2080307@delphij.net> Date: Fri, 02 Jul 2010 16:54:17 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100629 Thunderbird/3.0.5 ThunderBrowse/3.3 MIME-Version: 1.0 To: d@delphij.net References: <4C2E7BCD.4020609@delphij.net> In-Reply-To: <4C2E7BCD.4020609@delphij.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , Matthew Fleming , freebsd-hackers@freebsd.org Subject: Re: Using lex in a shared library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 23:54:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/07/02 16:52, Xin LI wrote: > On 2010/07/02 16:34, Matthew Fleming wrote: >> On Fri, Jul 2, 2010 at 4:02 PM, Garrett Cooper wrote: >>> On Fri, Jul 2, 2010 at 2:51 PM, Matthew Fleming wrote: >>>> I have the following Makefile for a shared library at $work: >>>> >>>> ISI_TOP= ../.. >>>> >>>> LIB= isi_date >>>> SHLIB_MAJOR= 1 >>>> SHLIB_MINOR= 0 >>>> SRCS= date.c date_parser.new.c lex.yy.c >>>> INCS= date.h >>>> INCLUDEDIR= /usr/include/isi_date >>>> >>>> YFLAGS+= -vt >>>> FLEX= /usr/bin/flex >>>> LDADD= -ll >>>> >>>> CLEANFILES+= date_parser.new.c y.tab.h y.tab.c lex.yy.c y.output \ >>>> check_date.log test >>>> >>>> lex.yy.c: date_lexer.new.l >>>> ${FLEX} $> >>>> >>>> CFLAGS+= -I${.CURDIR} >>>> #CFLAGS+= -g >>>> >>>> .include "${ISI_TOP}/isi.lib.mk" >>>> >>>> >>>> >>>> This builds fine as on i386. I'm trying to get all our user-space to >>>> be 64-bit clean, and I run into an error when building on amd64: >>>> >>>> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/bin/ld: >>>> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.a(libyywrap.o): >>>> relocation R_X86_64_32 can not be used when making a shared object; >>>> recompile with -fPIC >>>> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/libl.a: >>>> could not read symbols: Bad value >>>> >>>> The following diff makes the compile work, but I have no idea (yet) >>>> whether this will run, if it's the right solution, etc. >>>> >>>> >>>> Index: usr.bin/lex/lib/Makefile >>>> =================================================================== >>>> --- usr.bin/lex/lib/Makefile (revision 153343) >>>> +++ usr.bin/lex/lib/Makefile (working copy) >>>> @@ -4,11 +4,16 @@ >>>> >>>> LIB= ln >>>> SRCS= libmain.c libyywrap.c >>>> -NO_PIC= >>>> +#NO_PIC= >>>> >>>> +SHLIB_MAJOR= 1 >>>> +SHLIB_MINOR= 0 >>>> + >>>> .if ${MK_INSTALLLIB} != "no" >>>> LINKS= ${LIBDIR}/libln.a ${LIBDIR}/libl.a >>>> LINKS+= ${LIBDIR}/libln.a ${LIBDIR}/libfl.a >>>> +LINKS+= ${LIBDIR}/libln.so ${LIBDIR}/libl.so >>>> +LINKS+= ${LIBDIR}/libln${LIB_SUFFIX}.so ${LIBDIR}/libl${LIB_SUFFIX}.so >>>> .endif >>>> >>>> .if ${MK_PROFILE} != "no" >>> >>> The static-only version was done on purpose: >>> >>> Revision 1.2: download - view: text, markup, annotated - select for diffs >>> Thu Aug 25 23:11:07 1994 UTC (15 years, 10 months ago) by wollman >>> Branches: MAIN >>> CVS tags: RELENG_2_1_7_RELEASE, RELENG_2_1_6_RELEASE, >>> RELENG_2_1_6_1_RELEASE, RELENG_2_1_5_RELEASE, RELENG_2_1_0_RELEASE, >>> RELENG_2_1_0_BP, RELENG_2_0_5_RELEASE, RELENG_2_0_5_BP, >>> RELENG_2_0_5_ALPHA, RELENG_2_0_5, RELEASE_2_0, BETA_2_0, ALPHA_2_0 >>> Branch point for: RELENG_2_1_0 >>> Diff to: previous 1.1: preferred, colored >>> Changes since revision 1.1: +2 -8 lines >>> >>> We really, really /don't/ want to have a shared lex library. Also, >>> current users should note that the old 1.1.5 lex can't process the >>> new scan.l, so you have to copy initscan.c to obj/scan.c before it will >>> build. >>> >>> Garrett Wollman probably has more information about why this was done. >>> >>> I think that fixing the lib to build with the appropriate options (not >>> -m32, or CPUTYPE => some 32-bit x86 variant, etc) is what really needs >>> to be done here. > >> I guess I'm still confused. The isi_date library compiles fine if >> it's for i386, but switching to amd64 gives this error. Since I >> didn't specify any -m32 flags or anything, and it's essentially using >> the standard bsd.lib.mk magic, I am trying to figure out why the >> 32-bit isi_date.1.so built and the 64-bit one won't. Was the 32-bit >> version building successfully an unfortunate fluke? What build flags >> would get the shared library to link with -ll? > > I think that amd64 requires a static library be compiled with -fPIC if > it's being linked into shared object. This should not be done for > normal static libraries, though, as this could give some performance > penalty when it's not needed (i.e. a static binary). > >> Unfortunately, I didn't write this library, and I don't know anything >> about lex(1), so if I need my own yywrap() that might be fine, but I >> wouldn't have the first clue what to put in there. :-( > > I think you could probably just change the code and use %option noyywrap > in the .l file? (do your code call yywrap() directly?) ^^^^ I mean that the -ll can be just removed for most .l files that have noyywrap. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMLnwpAAoJEATO+BI/yjfBWqYIAIIWXmxVQd4M50KGu95aqlcm cfNKfyNzVfskdIj6Bcv5R/rRBAcqzdO+lPFdOupe0yMLFe0RUXiakNrI/NsMwKDx T/JErNiOgIUnsAKzkeV720nd73o1oTFGwIfqJ0XoNzYwl+bPU1JWG6cognXSlJha MCVVO8Rh/91Sle0KUb51dhCC+LFES+F9zzDMrPb1cGihN2CLZgaLvdDVbLYuRXn3 SZd62lE2dCZiILy7fy3nJRhybDJf/9hvu4WWFlmNPGt95U6Nzo9KBx9/MHMuvGCm kt7BUxj/zxR2PW9gBhn7ao8AtOkwA5qKSm07xb3w0LL6xXtgZDQpXQNwMIZP57g= =Ilvp -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 3 04:04:48 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7385F1065672 for ; Sat, 3 Jul 2010 04:04:48 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 369D98FC0C for ; Sat, 3 Jul 2010 04:04:47 +0000 (UTC) Received: by iwn35 with SMTP id 35so1963681iwn.13 for ; Fri, 02 Jul 2010 21:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GgbCKxjDMBJIQzBK3ois0wt+UljZO/8+74sqSK3dfGE=; b=DlABBfxlwpjGH7rGxdnoyBoB6Eqg3f2npnZs3y9+fO2jYcCrTaaJ8fDp6RH2j/g3SY a9j7WKjrKX8PVCPe2spgkLQWI78rCAHtzbTY7hLVLh1XTnfkb3UG+2iCgZgMf5iI54z2 2zPeZjmyCN0VziuOPsJBL9TDHoZ3rwKHkN4lY= 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=WNtUfw7Ri0j0KvXwQ48P5ZbC9xfnIwnCzqgFingACWZTyYLIwepfgwpg2eABefDcDd baRNx8dFg688auL4XgZ14eTtrUadcYntsvOum2uZOBXPee7m4k2Emwjl8otu5lsQofVI mcPKbQIC+pmxoKd2GlTgh4Uj43b41weUvYNrA= MIME-Version: 1.0 Received: by 10.42.9.29 with SMTP id k29mr561769ick.90.1278129887522; Fri, 02 Jul 2010 21:04:47 -0700 (PDT) Received: by 10.42.5.78 with HTTP; Fri, 2 Jul 2010 21:04:47 -0700 (PDT) In-Reply-To: <4C2E7C29.2080307@delphij.net> References: <4C2E7BCD.4020609@delphij.net> <4C2E7C29.2080307@delphij.net> Date: Sat, 3 Jul 2010 04:04:47 +0000 Message-ID: From: Matthew Fleming To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , freebsd-hackers@freebsd.org Subject: Re: Using lex in a shared library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 04:04:48 -0000 On Fri, Jul 2, 2010 at 11:54 PM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 2010/07/02 16:52, Xin LI wrote: >> On 2010/07/02 16:34, Matthew Fleming wrote: >>> On Fri, Jul 2, 2010 at 4:02 PM, Garrett Cooper wro= te: >>>> On Fri, Jul 2, 2010 at 2:51 PM, Matthew Fleming wro= te: >>>>> I have the following Makefile for a shared library at $work: >>>>> >>>>> ISI_TOP=3D =A0 =A0 =A0 =A0../.. >>>>> >>>>> LIB=3D =A0 =A0 =A0 =A0 =A0 =A0isi_date >>>>> SHLIB_MAJOR=3D =A0 =A01 >>>>> SHLIB_MINOR=3D =A0 =A00 >>>>> SRCS=3D =A0 =A0 =A0 =A0 =A0 date.c date_parser.new.c lex.yy.c >>>>> INCS=3D =A0 =A0 =A0 =A0 =A0 date.h >>>>> INCLUDEDIR=3D =A0 =A0 /usr/include/isi_date >>>>> >>>>> YFLAGS+=3D =A0 =A0 =A0 =A0-vt >>>>> FLEX=3D =A0 =A0 =A0 =A0 =A0 /usr/bin/flex >>>>> LDADD=3D =A0 =A0 =A0 =A0 =A0-ll >>>>> >>>>> CLEANFILES+=3D =A0 =A0date_parser.new.c y.tab.h y.tab.c lex.yy.c y.ou= tput \ >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0check_date.log test >>>>> >>>>> lex.yy.c: date_lexer.new.l >>>>> =A0 =A0 =A0 =A0${FLEX} $> >>>>> >>>>> CFLAGS+=3D =A0 =A0 =A0 =A0-I${.CURDIR} >>>>> #CFLAGS+=3D =A0 =A0 =A0 -g >>>>> >>>>> .include "${ISI_TOP}/isi.lib.mk" >>>>> >>>>> >>>>> >>>>> This builds fine as on i386. =A0I'm trying to get all our user-space = to >>>>> be 64-bit clean, and I run into an error when building on amd64: >>>>> >>>>> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/bin/ld= : >>>>> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/li= bl.a(libyywrap.o): >>>>> relocation R_X86_64_32 can not be used when making a shared object; >>>>> recompile with -fPIC >>>>> /data/sb/BR_MDF_64CLEAN/obj/data/sb/BR_MDF_64CLEAN/src/tmp/usr/lib/li= bl.a: >>>>> could not read symbols: Bad value >>>>> >>>>> The following diff makes the compile work, but I have no idea (yet) >>>>> whether this will run, if it's the right solution, etc. >>>>> >>>>> >>>>> Index: usr.bin/lex/lib/Makefile >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> --- usr.bin/lex/lib/Makefile =A0 =A0(revision 153343) >>>>> +++ usr.bin/lex/lib/Makefile =A0 =A0(working copy) >>>>> @@ -4,11 +4,16 @@ >>>>> >>>>> =A0LIB=3D =A0 =A0ln >>>>> =A0SRCS=3D =A0 libmain.c libyywrap.c >>>>> -NO_PIC=3D >>>>> +#NO_PIC=3D >>>>> >>>>> +SHLIB_MAJOR=3D =A0 1 >>>>> +SHLIB_MINOR=3D =A0 0 >>>>> + >>>>> =A0.if ${MK_INSTALLLIB} !=3D "no" >>>>> =A0LINKS=3D =A0${LIBDIR}/libln.a ${LIBDIR}/libl.a >>>>> =A0LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln.a ${LIBDIR}/libfl.a >>>>> +LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln.so ${LIBDIR}/libl.so >>>>> +LINKS+=3D =A0 =A0 =A0 =A0${LIBDIR}/libln${LIB_SUFFIX}.so ${LIBDIR}/l= ibl${LIB_SUFFIX}.so >>>>> =A0.endif >>>>> >>>>> =A0.if ${MK_PROFILE} !=3D "no" >>>> >>>> The static-only version was done on purpose: >>>> >>>> Revision 1.2: download - view: text, markup, annotated =A0- select for= diffs >>>> Thu Aug 25 23:11:07 1994 UTC (15 years, 10 months ago) by wollman >>>> Branches: MAIN >>>> CVS tags: RELENG_2_1_7_RELEASE, RELENG_2_1_6_RELEASE, >>>> RELENG_2_1_6_1_RELEASE, RELENG_2_1_5_RELEASE, RELENG_2_1_0_RELEASE, >>>> RELENG_2_1_0_BP, RELENG_2_0_5_RELEASE, RELENG_2_0_5_BP, >>>> RELENG_2_0_5_ALPHA, RELENG_2_0_5, RELEASE_2_0, BETA_2_0, ALPHA_2_0 >>>> Branch point for: RELENG_2_1_0 >>>> Diff to: previous 1.1: preferred, colored >>>> Changes since revision 1.1: +2 -8 lines >>>> >>>> We really, really /don't/ want to have a shared lex library. =A0Also, >>>> current users should note that the old 1.1.5 lex can't process the >>>> new scan.l, so you have to copy initscan.c to obj/scan.c before it wil= l >>>> build. >>>> >>>> Garrett Wollman probably has more information about why this was done. >>>> >>>> I think that fixing the lib to build with the appropriate options (not >>>> -m32, or CPUTYPE =3D> some 32-bit x86 variant, etc) is what really nee= ds >>>> to be done here. >> >>> I guess I'm still confused. =A0The isi_date library compiles fine if >>> it's for i386, but switching to amd64 gives this error. =A0Since I >>> didn't specify any -m32 flags or anything, and it's essentially using >>> the standard bsd.lib.mk magic, I am trying to figure out why the >>> 32-bit isi_date.1.so built and the 64-bit one won't. =A0Was the 32-bit >>> version building successfully an unfortunate fluke? =A0What build flags >>> would get the shared library to link with -ll? >> >> I think that amd64 requires a static library be compiled with -fPIC if >> it's being linked into shared object. =A0This should not be done for >> normal static libraries, though, as this could give some performance >> penalty when it's not needed (i.e. a static binary). >> >>> Unfortunately, I didn't write this library, and I don't know anything >>> about lex(1), so if I need my own yywrap() that might be fine, but I >>> wouldn't have the first clue what to put in there. :-( >> >> I think you could probably just change the code and use %option noyywrap >> in the .l file? =A0(do your code call yywrap() directly?) > > ^^^^ I mean that the -ll can be just removed for most .l files that have > noyywrap. Thanks! I will try this on Tuesday when I get back to $work, Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 3 10:10:48 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D3CF1065672 for ; Sat, 3 Jul 2010 10:10:48 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.sonnenberger.org (www.sonnenberger.org [92.79.50.50]) by mx1.freebsd.org (Postfix) with ESMTP id F36FF8FC1B for ; Sat, 3 Jul 2010 10:10:47 +0000 (UTC) Received: from britannica.bec.de (www.sonnenberger.org [192.168.1.10]) by www.sonnenberger.org (Postfix) with ESMTP id 71B2366787 for ; Sat, 3 Jul 2010 12:10:17 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1000) id 82CEB15096; Sat, 3 Jul 2010 12:08:11 +0200 (CEST) Date: Sat, 3 Jul 2010 12:08:11 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20100703100811.GA1605@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <4C2E7BCD.4020609@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C2E7BCD.4020609@delphij.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Using lex in a shared library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 10:10:48 -0000 On Fri, Jul 02, 2010 at 04:52:45PM -0700, Xin LI wrote: > I think that amd64 requires a static library be compiled with -fPIC if > it's being linked into shared object. This should not be done for > normal static libraries, though, as this could give some performance > penalty when it's not needed (i.e. a static binary). More precisely, AMD64 disallows absolute references in the text segment. The performance penalty for PIC on AMD64 is minimal as it can do RIP-relative addressing. Joerg From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 3 11:22:38 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E36321065673 for ; Sat, 3 Jul 2010 11:22:38 +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 5BE938FC14 for ; Sat, 3 Jul 2010 11:22:37 +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 o63BMYnj018131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 3 Jul 2010 14:22:34 +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.4/8.14.4) with ESMTP id o63BMYdj028302 for ; Sat, 3 Jul 2010 14:22:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o63BMY5s028301 for freebsd-hackers@freebsd.org; Sat, 3 Jul 2010 14:22:34 +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: Sat, 3 Jul 2010 14:22:34 +0300 From: Kostik Belousov To: freebsd-hackers@freebsd.org Message-ID: <20100703112234.GE13238@deviant.kiev.zoral.com.ua> References: <4C2E7BCD.4020609@delphij.net> <20100703100811.GA1605@britannica.bec.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GLnf9Go3l6tdAkV+" Content-Disposition: inline In-Reply-To: <20100703100811.GA1605@britannica.bec.de> 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.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, 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 Subject: Re: Using lex in a shared library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 11:22:39 -0000 --GLnf9Go3l6tdAkV+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 03, 2010 at 12:08:11PM +0200, Joerg Sonnenberger wrote: > On Fri, Jul 02, 2010 at 04:52:45PM -0700, Xin LI wrote: > > I think that amd64 requires a static library be compiled with -fPIC if > > it's being linked into shared object. This should not be done for > > normal static libraries, though, as this could give some performance > > penalty when it's not needed (i.e. a static binary). >=20 > More precisely, AMD64 disallows absolute references in the text segment. > The performance penalty for PIC on AMD64 is minimal as it can do > RIP-relative addressing. Even more precisely, amd64 does not disallow such references, it only disallows the 32bit signed relocations. The reasoning is that shared object may be loaded at arbitrary location at the process address space, and correct relocation might be larger then can be fi in 32 signed bit. The solution is either use PIC, thus going through PLT, or use big (or whatever is called) memory model when compiling, that makes all relocations 64 bit, with obvious performance penalty. --GLnf9Go3l6tdAkV+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwvHXoACgkQC3+MBN1Mb4jAqACeMxEbv/42NYE8UarvlhBIEAYy MfgAoK5ggZopU0CeNGx63FNP+119/KmC =OMow -----END PGP SIGNATURE----- --GLnf9Go3l6tdAkV+--