From owner-freebsd-arch@FreeBSD.ORG Sun Jun 27 00:19:39 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EE2C1065670; Sun, 27 Jun 2010 00:19:39 +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 27A3C8FC16; Sun, 27 Jun 2010 00:19:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o5R0HA2A064848; Sat, 26 Jun 2010 18:17:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 26 Jun 2010 18:17:19 -0600 (MDT) Message-Id: <20100626.181719.295937982837325865.imp@bsdimp.com> To: ru@freebsd.org From: "M. Warner Losh" In-Reply-To: <20100626.172307.4959786928950356.imp@bsdimp.com> References: <20100626.172307.4959786928950356.imp@bsdimp.com> 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: arch@freebsd.org Subject: Re: Build tools X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2010 00:19:39 -0000 In message: <20100626.172307.4959786928950356.imp@bsdimp.com> "M. Warner Losh" writes: : Hey Ruslan, : : Maybe you can help me understand why the following are in the : buildtools list: : _share= share/syscons/scrnmaps : : bin/csh \ : lib/ncurses/ncurses \ : lib/ncurses/ncursesw \ : ${_share} \ : lib/libmagic \ : usr.sbin/sysinstall : : There's clearly some side effects that I'm missing here... I'm missing that build-tools: target is built, and that those tools are then used to build these items. It isn't that these items are built themselves. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Jun 28 05:35:45 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4FC4106564A for ; Mon, 28 Jun 2010 05:35:45 +0000 (UTC) (envelope-from ru@freebsd.org) Received: from mail.vega.ru (mail.vega.ru [90.156.167.5]) by mx1.freebsd.org (Postfix) with ESMTP id A20898FC12 for ; Mon, 28 Jun 2010 05:35:45 +0000 (UTC) Received: from [10.100.124.99] (helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OT6pW-000O0b-F1; Mon, 28 Jun 2010 09:24:26 +0400 Date: Mon, 28 Jun 2010 09:23:44 +0400 From: Ruslan Ermilov To: "M. Warner Losh" Message-ID: <20100628052344.GB8478@edoofus.dev.vega.ru> References: <20100626.172307.4959786928950356.imp@bsdimp.com> <20100626.181719.295937982837325865.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100626.181719.295937982837325865.imp@bsdimp.com> Cc: arch@freebsd.org Subject: Re: Build tools X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 05:35:46 -0000 Hi Warner, On Sat, Jun 26, 2010 at 06:17:19PM -0600, M. Warner Losh wrote: > In message: <20100626.172307.4959786928950356.imp@bsdimp.com> > "M. Warner Losh" writes: > : Hey Ruslan, > : > : Maybe you can help me understand why the following are in the > : buildtools list: > : _share= share/syscons/scrnmaps > : > : bin/csh \ > : lib/ncurses/ncurses \ > : lib/ncurses/ncursesw \ > : ${_share} \ > : lib/libmagic \ > : usr.sbin/sysinstall > : > : There's clearly some side effects that I'm missing here... > > I'm missing that build-tools: target is built, and that those tools > are then used to build these items. It isn't that these items are > built themselves. Is there anything else I'm supposed to answer? :-) Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-arch@FreeBSD.ORG Mon Jun 28 06:38:29 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77852106566C; Mon, 28 Jun 2010 06:38:29 +0000 (UTC) (envelope-from yanegomi@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 2E3C98FC08; Mon, 28 Jun 2010 06:38:28 +0000 (UTC) Received: by iwn4 with SMTP id 4so465756iwn.13 for ; Sun, 27 Jun 2010 23:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=zslg+BTZZUzmY0cg6N0vJwwpoBlFstX7dQ2Hl5Q28LQ=; b=r8+d2mvkbKv3zvKfGG7qLS131Df4LuVUfcLHXeXbC4PI9nZtGzJun/l9HVG2qeqRPo L8E8Z3GPKHMwM8s9KngP6Zi51tGVj6hfDPJ0NO89U9pcnCVAj/lLHG3qgvdjIqs6yWsN okL6HlvSceAfhwelBjErLLFf2QZKR1BjnXQs8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.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=qG9CF14fw6umGUnruqrgfPuakTVxXdNV0GfP6Ao2RQHUQTAtGUa6MiMT6hg/a6g7Eg zBJKX/pCMLCjHDkmb6JSxOtHCq/Cj62nkSbaBXItOtEg7U+9JvVdFSRXexKaISX4xqv4 /Z4/+QQRPzeKYxWYBWLS6eUmF+CKlp++ZfFQo= MIME-Version: 1.0 Received: by 10.231.32.200 with SMTP id e8mr2626301ibd.66.1277707107473; Sun, 27 Jun 2010 23:38:27 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.209.71 with HTTP; Sun, 27 Jun 2010 23:38:27 -0700 (PDT) In-Reply-To: <20100628052344.GB8478@edoofus.dev.vega.ru> References: <20100626.172307.4959786928950356.imp@bsdimp.com> <20100626.181719.295937982837325865.imp@bsdimp.com> <20100628052344.GB8478@edoofus.dev.vega.ru> Date: Sun, 27 Jun 2010 23:38:27 -0700 X-Google-Sender-Auth: Wv-rSOu8l8JDDoExBookDChmuDI Message-ID: From: Garrett Cooper To: Ruslan Ermilov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: Build tools X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2010 06:38:29 -0000 On Sun, Jun 27, 2010 at 10:23 PM, Ruslan Ermilov wrote: > Hi Warner, > > On Sat, Jun 26, 2010 at 06:17:19PM -0600, M. Warner Losh wrote: >> In message: <20100626.172307.4959786928950356.imp@bsdimp.com> >> =A0 =A0 =A0 =A0 =A0 =A0 "M. Warner Losh" writes: >> : Hey Ruslan, >> : >> : Maybe you can help me understand why the following are in the >> : buildtools list: >> : _share=3D share/syscons/scrnmaps >> : >> : =A0 =A0 bin/csh \ >> : =A0 =A0 lib/ncurses/ncurses \ >> : =A0 =A0 lib/ncurses/ncursesw \ >> : =A0 =A0 ${_share} \ >> : =A0 =A0 lib/libmagic \ >> : =A0 =A0 usr.sbin/sysinstall >> : >> : There's clearly some side effects that I'm missing here... >> >> I'm missing that build-tools: target is built, and that those tools >> are then used to build these items. =A0It isn't that these items are >> built themselves. > > Is there anything else I'm supposed to answer? =A0:-) I think I see why peter@ added the sysinstall bit. If you look at the Makefile itself there's a built-tools target (which is fairly inconsequential as the rtermcap program is relatively small), and a dependency to check for an existing prebuilt fat termcap file and/or build a copy from scratch if the prebuilt one doesn't exist. I have no idea why it's in sysinstall's Makefile -- but it's there today (which means that one should probably tread around it with a big stick for the time being, and eventually be moved out if it's of value). -Garrett From owner-freebsd-arch@FreeBSD.ORG Tue Jun 29 10:30:50 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61357106566C; Tue, 29 Jun 2010 10:30:50 +0000 (UTC) (envelope-from yanegomi@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 E6A978FC1A; Tue, 29 Jun 2010 10:30:49 +0000 (UTC) Received: by iwn9 with SMTP id 9so707985iwn.13 for ; Tue, 29 Jun 2010 03:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=4RwlbcM/ZfEh5LFdYn4OmJd845ceykKNOnkeAJJrZAw=; b=O2MbIHIpBvaax2w8gA0d8bsLdkwBfi5JCVmz6QDl8mM/3Qb+0LuTCZR8JsCdQUElGt IUK88mabyMRqbJzbaoFC7YZ9yujI2eLJDttvmYjYvhPJ435Ht6LVaumuSUnaJWxU3c2P VjZ+r/xbu+lpF+rZntWSuEe8XeISQhBmX1KPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.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=bp1MUJSgFwGDMeAHPI6PqAc2rdDRYtyOMSl+IIr2FYGZ9cDGPEO0mDVdbwylCzYrpy PzHudja4NoX/Kb9aSjtgryCYB6AU7bR22pGcUqBF7q5dRXKkpN0kppXOdFs6sBuMG1cJ tdTYRsULoc7pkEMEbIL3eyaymyxS8i1zXiVgw= MIME-Version: 1.0 Received: by 10.231.60.7 with SMTP id n7mr6415194ibh.60.1277807449158; Tue, 29 Jun 2010 03:30:49 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.209.71 with HTTP; Tue, 29 Jun 2010 03:30:49 -0700 (PDT) In-Reply-To: References: <20100626.172307.4959786928950356.imp@bsdimp.com> <20100626.181719.295937982837325865.imp@bsdimp.com> <20100628052344.GB8478@edoofus.dev.vega.ru> Date: Tue, 29 Jun 2010 03:30:49 -0700 X-Google-Sender-Auth: AYELAkiGMLp5UpdZMuEiFnsvZj4 Message-ID: From: Garrett Cooper To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: Build tools X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 10:30:50 -0000 On Sun, Jun 27, 2010 at 11:38 PM, Garrett Cooper wrot= e: > On Sun, Jun 27, 2010 at 10:23 PM, Ruslan Ermilov wrote: >> Hi Warner, >> >> On Sat, Jun 26, 2010 at 06:17:19PM -0600, M. Warner Losh wrote: >>> In message: <20100626.172307.4959786928950356.imp@bsdimp.com> >>> =A0 =A0 =A0 =A0 =A0 =A0 "M. Warner Losh" writes: >>> : Hey Ruslan, >>> : >>> : Maybe you can help me understand why the following are in the >>> : buildtools list: >>> : _share=3D share/syscons/scrnmaps >>> : >>> : =A0 =A0 bin/csh \ >>> : =A0 =A0 lib/ncurses/ncurses \ >>> : =A0 =A0 lib/ncurses/ncursesw \ >>> : =A0 =A0 ${_share} \ >>> : =A0 =A0 lib/libmagic \ >>> : =A0 =A0 usr.sbin/sysinstall >>> : >>> : There's clearly some side effects that I'm missing here... >>> >>> I'm missing that build-tools: target is built, and that those tools >>> are then used to build these items. =A0It isn't that these items are >>> built themselves. >> >> Is there anything else I'm supposed to answer? =A0:-) > > I think I see why peter@ added the sysinstall bit. If you look at the > Makefile itself there's a built-tools target (which is fairly > inconsequential as the rtermcap program is relatively small), and a > dependency to check for an existing prebuilt fat termcap file and/or > build a copy from scratch if the prebuilt one doesn't exist. I have no > idea why it's in sysinstall's Makefile -- but it's there today (which > means that one should probably tread around it with a big stick for > the time being, and eventually be moved out if it's of value). Finally got things netbooted, and I verified that nothing blew up with sysinstall missing from the box. Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Tue Jun 29 17:26:13 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEA241065670; Tue, 29 Jun 2010 17:26:13 +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 50A418FC16; Tue, 29 Jun 2010 17:26:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o5THJ8sB012003; Tue, 29 Jun 2010 11:19:08 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 29 Jun 2010 11:19:21 -0600 (MDT) Message-Id: <20100629.111921.1075071109811565815.imp@bsdimp.com> To: gcooper@freebsd.org From: "M. Warner Losh" In-Reply-To: References: <20100628052344.GB8478@edoofus.dev.vega.ru> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: Build tools X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 17:26:13 -0000 In message: Garrett Cooper writes: : On Sun, Jun 27, 2010 at 11:38 PM, Garrett Cooper wrote: : > On Sun, Jun 27, 2010 at 10:23 PM, Ruslan Ermilov w= rote: : >> Hi Warner, : >> : >> On Sat, Jun 26, 2010 at 06:17:19PM -0600, M. Warner Losh wrote: : >>> In message: <20100626.172307.4959786928950356.imp@bsdimp.com> : >>> =A0 =A0 =A0 =A0 =A0 =A0 "M. Warner Losh" writes:= : >>> : Hey Ruslan, : >>> : : >>> : Maybe you can help me understand why the following are in the : >>> : buildtools list: : >>> : _share=3D share/syscons/scrnmaps : >>> : : >>> : =A0 =A0 bin/csh \ : >>> : =A0 =A0 lib/ncurses/ncurses \ : >>> : =A0 =A0 lib/ncurses/ncursesw \ : >>> : =A0 =A0 ${_share} \ : >>> : =A0 =A0 lib/libmagic \ : >>> : =A0 =A0 usr.sbin/sysinstall : >>> : : >>> : There's clearly some side effects that I'm missing here... : >>> : >>> I'm missing that build-tools: target is built, and that those too= ls : >>> are then used to build these items. =A0It isn't that these items = are : >>> built themselves. : >> : >> Is there anything else I'm supposed to answer? =A0:-) : > : > I think I see why peter@ added the sysinstall bit. If you look at t= he : > Makefile itself there's a built-tools target (which is fairly : > inconsequential as the rtermcap program is relatively small), and a= : > dependency to check for an existing prebuilt fat termcap file and/o= r : > build a copy from scratch if the prebuilt one doesn't exist. I have= no : > idea why it's in sysinstall's Makefile -- but it's there today (whi= ch : > means that one should probably tread around it with a big stick for= : > the time being, and eventually be moved out if it's of value). : = : Finally got things netbooted, and I verified that nothing blew up= : with sysinstall missing from the box. I've audited at least the build-tools target portion, and nothing will break if we don't build it during the build-tools phase, so long as we don't try to build sysinstall later. Of course, a stripped termcap file likely should replace the compiled-in entries. Many people have had good luck getting the stripped version to be extra-tiny. Also, many of the entries that are compiled in are no longer relevant, and could be removed (another reason to have them be in a file sysinstall reads). The days of 1.2MB floppies that motivated this in the first place are long gone... Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jun 29 20:40:21 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC1E71065675; Tue, 29 Jun 2010 20:40:21 +0000 (UTC) (envelope-from yanegomi@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 61B208FC17; Tue, 29 Jun 2010 20:40:21 +0000 (UTC) Received: by iwn9 with SMTP id 9so70353iwn.13 for ; Tue, 29 Jun 2010 13:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=CMxNCQpUZ7Xeqnze69UOuPN5jlZ0Yhyf4VErut7CwyQ=; b=fM13Ppc+lgi+nOFUq2FBXnksn74CZXbfjO5mbvLXWFcLnzL8C363bL/jOJ7Z4UcE/5 XAorYbcKuzNkf0tAb/ZWLZyHYc+clmd2NDzunwpLhvL18J3OKCRtm/nwS7CLchHXZwxr yGoiFfGwKPteVJp49C50Np954Lo3PnF+ZU+X0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.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=Ldr9n4BNsD6ROeP8V5y/mcLOtBUVIcqHEIoCgEe6/zh6wmQ925D+uXjyOKy9QpjZjr 3FDD4/CZS1W39Sdz/Zfyfvp9mMQSozOxG1P30aJRhBtT2wGL6OHffCKOGGlPmxTHPV0o er86JP/mOKxpee24vWgCsxe5c5t1ABxTM2VUo= MIME-Version: 1.0 Received: by 10.231.184.75 with SMTP id cj11mr7673813ibb.51.1277844020837; Tue, 29 Jun 2010 13:40:20 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.209.71 with HTTP; Tue, 29 Jun 2010 13:40:20 -0700 (PDT) In-Reply-To: <20100629.111921.1075071109811565815.imp@bsdimp.com> References: <20100628052344.GB8478@edoofus.dev.vega.ru> <20100629.111921.1075071109811565815.imp@bsdimp.com> Date: Tue, 29 Jun 2010 13:40:20 -0700 X-Google-Sender-Auth: xiE_7LT6HNc8vcUWsZ1WDDElGgk Message-ID: From: Garrett Cooper To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: Build tools X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 20:40:21 -0000 On Tue, Jun 29, 2010 at 10:19 AM, M. Warner Losh wrote: > In message: > =A0 =A0 =A0 =A0 =A0 =A0Garrett Cooper writes: > : On Sun, Jun 27, 2010 at 11:38 PM, Garrett Cooper = wrote: > : > On Sun, Jun 27, 2010 at 10:23 PM, Ruslan Ermilov wro= te: > : >> Hi Warner, > : >> > : >> On Sat, Jun 26, 2010 at 06:17:19PM -0600, M. Warner Losh wrote: > : >>> In message: <20100626.172307.4959786928950356.imp@bsdimp.com> > : >>> =A0 =A0 =A0 =A0 =A0 =A0 "M. Warner Losh" writes: > : >>> : Hey Ruslan, > : >>> : > : >>> : Maybe you can help me understand why the following are in the > : >>> : buildtools list: > : >>> : _share=3D share/syscons/scrnmaps > : >>> : > : >>> : =A0 =A0 bin/csh \ > : >>> : =A0 =A0 lib/ncurses/ncurses \ > : >>> : =A0 =A0 lib/ncurses/ncursesw \ > : >>> : =A0 =A0 ${_share} \ > : >>> : =A0 =A0 lib/libmagic \ > : >>> : =A0 =A0 usr.sbin/sysinstall > : >>> : > : >>> : There's clearly some side effects that I'm missing here... > : >>> > : >>> I'm missing that build-tools: target is built, and that those tools > : >>> are then used to build these items. =A0It isn't that these items ar= e > : >>> built themselves. > : >> > : >> Is there anything else I'm supposed to answer? =A0:-) > : > > : > I think I see why peter@ added the sysinstall bit. If you look at the > : > Makefile itself there's a built-tools target (which is fairly > : > inconsequential as the rtermcap program is relatively small), and a > : > dependency to check for an existing prebuilt fat termcap file and/or > : > build a copy from scratch if the prebuilt one doesn't exist. I have n= o > : > idea why it's in sysinstall's Makefile -- but it's there today (which > : > means that one should probably tread around it with a big stick for > : > the time being, and eventually be moved out if it's of value). > : > : =A0 =A0 Finally got things netbooted, and I verified that nothing blew = up > : with sysinstall missing from the box. > > I've audited at least the build-tools target portion, and nothing will > break if we don't build it during the build-tools phase, so long as we > don't try to build sysinstall later. =A0Of course, a stripped termcap > file likely should replace the compiled-in entries. =A0Many people have > had good luck getting the stripped version to be extra-tiny. =A0Also, > many of the entries that are compiled in are no longer relevant, and > could be removed (another reason to have them be in a file sysinstall > reads). =A0The days of 1.2MB floppies that motivated this in the first > place are long gone... Because the defacto floppy size was increased from 1.2MB to 1.44MB, or because floppies should die (pc98 folks would probably disagree though as that's why sysinstall still has floppy support :/)? Thanks! -Garrett From owner-freebsd-arch@FreeBSD.ORG Tue Jun 29 21:06:24 2010 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1CCB1065676; Tue, 29 Jun 2010 21:06:24 +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 652158FC28; Tue, 29 Jun 2010 21:06:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o5TL2QwV014533; Tue, 29 Jun 2010 15:02:26 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 29 Jun 2010 15:02:40 -0600 (MDT) Message-Id: <20100629.150240.339978944265510529.imp@bsdimp.com> To: gcooper@FreeBSD.org From: "M. Warner Losh" In-Reply-To: References: <20100629.111921.1075071109811565815.imp@bsdimp.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@FreeBSD.org, ru@FreeBSD.org Subject: Re: Build tools X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 21:06:24 -0000 In message: Garrett Cooper writes: : On Tue, Jun 29, 2010 at 10:19 AM, M. Warner Losh wro= te: : > In message: : > =A0 =A0 =A0 =A0 =A0 =A0Garrett Cooper writes:= : > : On Sun, Jun 27, 2010 at 11:38 PM, Garrett Cooper wrote: : > : > On Sun, Jun 27, 2010 at 10:23 PM, Ruslan Ermilov wrote: : > : >> Hi Warner, : > : >> : > : >> On Sat, Jun 26, 2010 at 06:17:19PM -0600, M. Warner Losh wrote= : : > : >>> In message: <20100626.172307.4959786928950356.imp@bsdimp.com>= : > : >>> =A0 =A0 =A0 =A0 =A0 =A0 "M. Warner Losh" wri= tes: : > : >>> : Hey Ruslan, : > : >>> : : > : >>> : Maybe you can help me understand why the following are in t= he : > : >>> : buildtools list: : > : >>> : _share=3D share/syscons/scrnmaps : > : >>> : : > : >>> : =A0 =A0 bin/csh \ : > : >>> : =A0 =A0 lib/ncurses/ncurses \ : > : >>> : =A0 =A0 lib/ncurses/ncursesw \ : > : >>> : =A0 =A0 ${_share} \ : > : >>> : =A0 =A0 lib/libmagic \ : > : >>> : =A0 =A0 usr.sbin/sysinstall : > : >>> : : > : >>> : There's clearly some side effects that I'm missing here... : > : >>> : > : >>> I'm missing that build-tools: target is built, and that those= tools : > : >>> are then used to build these items. =A0It isn't that these it= ems are : > : >>> built themselves. : > : >> : > : >> Is there anything else I'm supposed to answer? =A0:-) : > : > : > : > I think I see why peter@ added the sysinstall bit. If you look = at the : > : > Makefile itself there's a built-tools target (which is fairly : > : > inconsequential as the rtermcap program is relatively small), a= nd a : > : > dependency to check for an existing prebuilt fat termcap file a= nd/or : > : > build a copy from scratch if the prebuilt one doesn't exist. I = have no : > : > idea why it's in sysinstall's Makefile -- but it's there today = (which : > : > means that one should probably tread around it with a big stick= for : > : > the time being, and eventually be moved out if it's of value). : > : : > : =A0 =A0 Finally got things netbooted, and I verified that nothing= blew up : > : with sysinstall missing from the box. : > : > I've audited at least the build-tools target portion, and nothing w= ill : > break if we don't build it during the build-tools phase, so long as= we : > don't try to build sysinstall later. =A0Of course, a stripped termc= ap : > file likely should replace the compiled-in entries. =A0Many people = have : > had good luck getting the stripped version to be extra-tiny. =A0Als= o, : > many of the entries that are compiled in are no longer relevant, an= d : > could be removed (another reason to have them be in a file sysinsta= ll : > reads). =A0The days of 1.2MB floppies that motivated this in the fi= rst : > place are long gone... : = : Because the defacto floppy size was increased from 1.2MB to : 1.44MB, or because floppies should die (pc98 folks would probably : disagree though as that's why sysinstall still has floppy support :/)= ? No. Because the size sysinstall has to fit in is now constrained by the CDROM's size, not by the floppy's size. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jun 30 03:18:47 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B84F106566B for ; Wed, 30 Jun 2010 03:18:47 +0000 (UTC) (envelope-from cyrille.lefevre-lists@laposte.net) Received: from out5.laposte.net (out6.laposte.net [193.251.214.123]) by mx1.freebsd.org (Postfix) with ESMTP id 4EA638FC0A for ; Wed, 30 Jun 2010 03:18:46 +0000 (UTC) Received: from meplus.info (localhost [127.0.0.1]) by mwinf8414.laposte.net (SMTP Server) with ESMTP id 54A04E000086 for ; Wed, 30 Jun 2010 05:18:45 +0200 (CEST) Received: from [192.168.1.133] (156.64.99-84.rev.gaoland.net [84.99.64.156]) by mwinf8414.laposte.net (SMTP Server) with ESMTP id 151FBE000085 for ; Wed, 30 Jun 2010 05:18:44 +0200 (CEST) X-ME-UUID: 20100630031845866.151FBE000085@mwinf8414.laposte.net Message-ID: <4C2AB793.4040601@laposte.net> Date: Wed, 30 Jun 2010 05:18:43 +0200 From: Cyrille Lefevre Organization: ACME User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-me-spamlevel: not-spam X-me-spamrating: 39.799999 X-me-spamcause: OK, (-5)(0000)gggruggvucftvghtrhhoucdtuddrvdelhedrtdeiucetggdotefuucfrrhhofhhilhgvmecuoehnohhnvgeqnecuuegrihhlohhuthemuceftddtnecufghrlhcuvffnffculdehmdenuefuffculddquddtmd Cc: Subject: dwb : groff replacement proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 03:18:47 -0000 Hi, seen on http://wiki.freebsd.org/ContribSoftware, groff have switch to GPLv3 license, so, don't know if the license permit it, but the Documentation WorkBench is available for download here : http://www2.research.att.com/sw/download/ search for dwb - standalone documenters workbench command and libraries PS : the current dwb.1993-02-04.tgz archive doesn't contain any license, however, the download states that "Unknown License" agreement is required for the dwb but require the acceptance of the Common Public License Version 1.0, don't know if the CPL is compatible w/ the BSD one? If you are interrested, I suggest you to contact gsf or dgk : http://www.research.att.com/people/Fowler_Glenn_S http://www.research.att.com/people/Korn_David_G Regards, Cyrille Lefevre -- mailto:Cyrille.Lefevre-lists@laposte.net From owner-freebsd-arch@FreeBSD.ORG Wed Jun 30 03:46:23 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A003D106566C for ; Wed, 30 Jun 2010 03:46:23 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 68D888FC18 for ; Wed, 30 Jun 2010 03:46:23 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o5U3kM1p048826; Tue, 29 Jun 2010 20:46:22 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o5U3kMLd048825; Tue, 29 Jun 2010 20:46:22 -0700 (PDT) (envelope-from sgk) Date: Tue, 29 Jun 2010 20:46:22 -0700 From: Steve Kargl To: Cyrille Lefevre Message-ID: <20100630034622.GA48794@troutmask.apl.washington.edu> References: <4C2AB793.4040601@laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C2AB793.4040601@laposte.net> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: dwb : groff replacement proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 03:46:23 -0000 On Wed, Jun 30, 2010 at 05:18:43AM +0200, Cyrille Lefevre wrote: > > seen on http://wiki.freebsd.org/ContribSoftware, groff have switch > to GPLv3 license, so, So what? The version of groff in the src/ isn't going to suddenly stop working. Please send this type of email to free-advocacy or freebsd-chat. It has no place here. -- Steve From owner-freebsd-arch@FreeBSD.ORG Wed Jun 30 04:48:01 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7E371065672 for ; Wed, 30 Jun 2010 04:48:01 +0000 (UTC) (envelope-from yanegomi@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 7AB678FC16 for ; Wed, 30 Jun 2010 04:48:01 +0000 (UTC) Received: by iwn9 with SMTP id 9so555677iwn.13 for ; Tue, 29 Jun 2010 21:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=o3hbqOe1Er9S7Miq00skeMC8Sa5W5/jIVpKpmZhdGEI=; b=CgVIz010QSpgzT7kC9O+9MCC83QEnt9Ou1yzqdJhFvcuweAiau/J2EtWlR08KXlrnz 8HSejka4GArhWAbBI+xbNpr44XmWqCqYvwVtAiTFjG6h4Apk3i7B+YAilDMowbC68wjo hX385KyhjB9xIEURRzGfjAySwcVbUJpHfT0eY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.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=xkCFaDgCwP1MSAjtAKBgkk2A/NiusUNSVYM/8ZHL1qjc8j4TEFN4A6F0CNj0pggQSa XKRtKoSeC+0823IH8FjoQguDzvQoG35/TgQAPKLSa3wITDZTr7747Jw0MpQYKjxzlzQc p7GToftitom6L8yyTOYlchgr86BwaFXKB8AF8= MIME-Version: 1.0 Received: by 10.231.12.136 with SMTP id x8mr119953ibx.159.1277873280406; Tue, 29 Jun 2010 21:48:00 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.214.145 with HTTP; Tue, 29 Jun 2010 21:48:00 -0700 (PDT) In-Reply-To: <20100630034622.GA48794@troutmask.apl.washington.edu> References: <4C2AB793.4040601@laposte.net> <20100630034622.GA48794@troutmask.apl.washington.edu> Date: Tue, 29 Jun 2010 21:48:00 -0700 X-Google-Sender-Auth: z74sUkgPNQAvwhhlfCTMXXA6w8o Message-ID: From: Garrett Cooper To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: dwb : groff replacement proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 04:48:01 -0000 On Tue, Jun 29, 2010 at 8:46 PM, Steve Kargl wrote: > On Wed, Jun 30, 2010 at 05:18:43AM +0200, Cyrille Lefevre wrote: >> >> seen on http://wiki.freebsd.org/ContribSoftware, groff have switch >> to GPLv3 license, so, > > So what? =A0The version of groff in the src/ isn't > going to suddenly stop working. =A0Please send this > type of email to free-advocacy or freebsd-chat. > It has no place here. Steve, I do see his point because bitrot software doesn't help, and apart from our toolchain and a few other things, a lot of the GNU software is being forced out eventually. groff hasn't been touched in ages however. Regardless, there's already work being done to remedy this in the FreeBSD community; see: http://www.freebsdnews.net/2009/05/11/deprecating-groff-bsd-manual-display/ for one link. Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Wed Jun 30 06:24:04 2010 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E884B106566C; Wed, 30 Jun 2010 06:24:04 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id ABA2F8FC08; Wed, 30 Jun 2010 06:24:04 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o5U6O4vP049447; Tue, 29 Jun 2010 23:24:04 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o5U6O3Hd049446; Tue, 29 Jun 2010 23:24:03 -0700 (PDT) (envelope-from sgk) Date: Tue, 29 Jun 2010 23:24:03 -0700 From: Steve Kargl To: Garrett Cooper Message-ID: <20100630062403.GA49395@troutmask.apl.washington.edu> References: <4C2AB793.4040601@laposte.net> <20100630034622.GA48794@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: arch@FreeBSD.org Subject: Re: dwb : groff replacement proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 06:24:05 -0000 On Tue, Jun 29, 2010 at 09:48:00PM -0700, Garrett Cooper wrote: > On Tue, Jun 29, 2010 at 8:46 PM, Steve Kargl > wrote: > > On Wed, Jun 30, 2010 at 05:18:43AM +0200, Cyrille Lefevre wrote: > >> > >> seen on http://wiki.freebsd.org/ContribSoftware, groff have switch > >> to GPLv3 license, so, > > > > So what? ?The version of groff in the src/ isn't > > going to suddenly stop working. ?Please send this > > type of email to free-advocacy or freebsd-chat. > > It has no place here. > > Steve, > I do see his point because bitrot software doesn't help, and apart > from our toolchain and a few other things, a lot of the GNU software > is being forced out eventually. groff hasn't been touched in ages > however. "groff hasn't been touched in ages" so FreeBSD suddenly can't render its man pages? Cyrille's post should have gone to freebsd-advocacy or -chat. The fact that FSF is moving its software distributions to GPLv3 isn't some state secret. > Regardless, there's already work being done to remedy this in the > FreeBSD community; see: > http://www.freebsdnews.net/2009/05/11/deprecating-groff-bsd-manual-display/ > for one link. I'm aware of mdocml and other efforts. None of these efforts come close to replacing the functionality provided by the version of groff in src/. The current version of groff in FreeBSD meets FreeBSD needs. Do you envision bitrot in FreeBSD's groff that will go unnotice? Do you envision an in flux of man pages into FreeBSD that are written in mdoc (or other macro packages) that can't be rendered by FreeBSD's version of groff, but can be rendered by mdocml? -- Steve From owner-freebsd-arch@FreeBSD.ORG Wed Jun 30 08:08:58 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69B2F1065670 for ; Wed, 30 Jun 2010 08:08:58 +0000 (UTC) (envelope-from yanegomi@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 273008FC1C for ; Wed, 30 Jun 2010 08:08:57 +0000 (UTC) Received: by iwn9 with SMTP id 9so725760iwn.13 for ; Wed, 30 Jun 2010 01:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=n7j+12YwWHJ1ow/UdPFOrbRNKqDgBBRrbIDZPqj4KFM=; b=Axip2O8WhxOWpDXb3FefrTytmNJvUIoQvrtZgecpxF2oWm6wSjL0Tn7Sm6rXWQU2hi dDWfiu4d/CP4Bi60sAoV1x2AKlt5ncQZbnsJg0A6Poy4xKwV1NAQ3Fu2AmYUpYDMK18A YApSYHi47P3n9zDjCA1RBTMQFPouTSnur0Z30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.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=k7bOiO/DoVyrUjMLgV5uWTykHEoBB2eDIVcm5Cg62+7bSPzcRDfPHZLQ6UzbbNKdgr l1JpMOH/K8ndEycOKwEGxYeAsePHU08XPP8iekXKJvV38PpgDpUQdMshI82j4rQQt0XA ULMNhxyZ7lc/Sw6J8Zkmn6C64IhfGrZBiMb9o= MIME-Version: 1.0 Received: by 10.42.5.134 with SMTP id 6mr2666828icw.2.1277885337360; Wed, 30 Jun 2010 01:08:57 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.214.145 with HTTP; Wed, 30 Jun 2010 01:08:57 -0700 (PDT) In-Reply-To: <20100630062403.GA49395@troutmask.apl.washington.edu> References: <4C2AB793.4040601@laposte.net> <20100630034622.GA48794@troutmask.apl.washington.edu> <20100630062403.GA49395@troutmask.apl.washington.edu> Date: Wed, 30 Jun 2010 01:08:57 -0700 X-Google-Sender-Auth: pgxk0aTmRnguYjWMhWuojkczNuo Message-ID: From: Garrett Cooper To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: dwb : groff replacement proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 08:08:58 -0000 On Tue, Jun 29, 2010 at 11:24 PM, Steve Kargl wrote: > On Tue, Jun 29, 2010 at 09:48:00PM -0700, Garrett Cooper wrote: >> On Tue, Jun 29, 2010 at 8:46 PM, Steve Kargl >> wrote: >> > On Wed, Jun 30, 2010 at 05:18:43AM +0200, Cyrille Lefevre wrote: >> >> >> >> seen on http://wiki.freebsd.org/ContribSoftware, groff have switch >> >> to GPLv3 license, so, >> > >> > So what? ?The version of groff in the src/ isn't >> > going to suddenly stop working. ?Please send this >> > type of email to free-advocacy or freebsd-chat. >> > It has no place here. >> >> Steve, >> =A0 =A0 I do see his point because bitrot software doesn't help, and apa= rt >> from our toolchain and a few other things, a lot of the GNU software >> is being forced out eventually. groff hasn't been touched in ages >> however. > > "groff hasn't been touched in ages" so FreeBSD suddenly can't > render its man pages? > > Cyrille's post should have gone to freebsd-advocacy or -chat. > The fact that FSF is moving its software distributions to > GPLv3 isn't some state secret. > >> =A0 =A0 Regardless, there's already work being done to remedy this in th= e >> FreeBSD community; see: >> http://www.freebsdnews.net/2009/05/11/deprecating-groff-bsd-manual-displ= ay/ >> for one link. > > I'm aware of mdocml and other efforts. =A0None of these efforts > come close to replacing the functionality provided by the > version of groff in src/. =A0The current version of groff in > FreeBSD meets FreeBSD needs. =A0Do you envision bitrot in > FreeBSD's groff that will go unnotice? =A0Do you envision an > in flux of man pages into FreeBSD that are written in > mdoc (or other macro packages) that can't be rendered by > FreeBSD's version of groff, but can be rendered by mdocml? Well, ok. The reply was to kind of make the Cyrille message moot, but it kind of morphed into something else by accident. I think we should bury the hatchet on this topic after this to avoid useless spinning. Thanks, -Garrett From owner-freebsd-arch@FreeBSD.ORG Wed Jun 30 09:43:07 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C25151065675 for ; Wed, 30 Jun 2010 09:43:07 +0000 (UTC) (envelope-from cyrille.lefevre-lists@laposte.net) Received: from out5.laposte.net (out6.laposte.net [193.251.214.123]) by mx1.freebsd.org (Postfix) with ESMTP id 8339A8FC27 for ; Wed, 30 Jun 2010 09:43:07 +0000 (UTC) Received: from meplus.info (localhost [127.0.0.1]) by mwinf8414.laposte.net (SMTP Server) with ESMTP id 87BF5E0000B4; Wed, 30 Jun 2010 11:43:05 +0200 (CEST) Received: from [192.168.1.133] (156.64.99-84.rev.gaoland.net [84.99.64.156]) by mwinf8414.laposte.net (SMTP Server) with ESMTP id EFA00E0000B3; Wed, 30 Jun 2010 11:43:04 +0200 (CEST) X-ME-UUID: 20100630094304981.EFA00E0000B3@mwinf8414.laposte.net Message-ID: <4C2B11A9.4020206@laposte.net> Date: Wed, 30 Jun 2010 11:43:05 +0200 From: Cyrille Lefevre Organization: ACME User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Steve Kargl References: <4C2AB793.4040601@laposte.net> <20100630034622.GA48794@troutmask.apl.washington.edu> In-Reply-To: <20100630034622.GA48794@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-me-spamlevel: not-spam X-me-spamrating: 35.200001 X-me-spamcause: OK, (-120)(0000)gggruggvucftvghtrhhoucdtuddrvdelhedrtdeiucetggdotefuucfrrhhofhhilhgvmecuoehnohhnvgeqnecuuegrihhlohhuthemuceftddtnecufghrlhcuvffnffculddvtddmneculddquddttddmnehfrhgvvggsshgufeigucdlqdeftddmneeuufffucdlqddutddm Cc: arch@freebsd.org Subject: Re: dwb : groff replacement proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 09:43:07 -0000 Le 30/06/2010 05:46, Steve Kargl a =E9crit : > > On Wed, Jun 30, 2010 at 05:18:43AM +0200, Cyrille Lefevre wrote: >> >> seen on http://wiki.freebsd.org/ContribSoftware, groff have switch >> to GPLv3 license, so, > > So what? The version of groff in the src/ isn't > going to suddenly stop working. Please send this > type of email to free-advocacy or freebsd-chat. > It has no place here. it was just for information and I do not know every dozen freebsd lists=20 by heart... so I appology. however, you answer remember me why I quit FreeBSD, cease fire, courtesy = is the key. Regards, Cyrille Lefevre --=20 mailto:Cyrille.Lefevre-lists@laposte.net From owner-freebsd-arch@FreeBSD.ORG Wed Jun 30 09:43:15 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92394106566B for ; Wed, 30 Jun 2010 09:43:15 +0000 (UTC) (envelope-from cyrille.lefevre-lists@laposte.net) Received: from out5.laposte.net (out6.laposte.net [193.251.214.123]) by mx1.freebsd.org (Postfix) with ESMTP id 543BA8FC15 for ; Wed, 30 Jun 2010 09:43:15 +0000 (UTC) Received: from meplus.info (localhost [127.0.0.1]) by mwinf8414.laposte.net (SMTP Server) with ESMTP id B177EE0000B3; Wed, 30 Jun 2010 11:43:14 +0200 (CEST) Received: from [192.168.1.133] (156.64.99-84.rev.gaoland.net [84.99.64.156]) by mwinf8414.laposte.net (SMTP Server) with ESMTP id 0735CE0000B2; Wed, 30 Jun 2010 11:43:13 +0200 (CEST) X-ME-UUID: 20100630094314296.0735CE0000B2@mwinf8414.laposte.net Message-ID: <4C2B11B2.7080409@laposte.net> Date: Wed, 30 Jun 2010 11:43:14 +0200 From: Cyrille Lefevre Organization: ACME User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Steve Kargl References: <4C2AB793.4040601@laposte.net> <20100630034622.GA48794@troutmask.apl.washington.edu> In-Reply-To: <20100630034622.GA48794@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-me-spamlevel: not-spam X-me-spamrating: 35.200001 X-me-spamcause: OK, (-120)(0000)gggruggvucftvghtrhhoucdtuddrvdelhedrtdeiucetggdotefuucfrrhhofhhilhgvmecuoehnohhnvgeqnecuuegrihhlohhuthemuceftddtnecufghrlhcuvffnffculddvtddmneculddquddttddmnehfrhgvvggsshgufeigucdlqdeftddmneeuufffucdlqddutddm Cc: arch@freebsd.org Subject: Re: dwb : groff replacement proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 09:43:15 -0000 Le 30/06/2010 05:46, Steve Kargl a =E9crit : > > On Wed, Jun 30, 2010 at 05:18:43AM +0200, Cyrille Lefevre wrote: >> >> seen on http://wiki.freebsd.org/ContribSoftware, groff have switch >> to GPLv3 license, so, > > So what? The version of groff in the src/ isn't > going to suddenly stop working. Please send this > type of email to free-advocacy or freebsd-chat. > It has no place here. it was just for information and I do not know every dozen freebsd lists=20 by heart... so I appology. however, you answer remember me why I quit FreeBSD, cease fire, courtesy = is the key. Regards, Cyrille Lefevre --=20 mailto:Cyrille.Lefevre-lists@laposte.net From owner-freebsd-arch@FreeBSD.ORG Wed Jun 30 15:55:57 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E08401065673 for ; Wed, 30 Jun 2010 15:55:57 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (outp.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id C39CF8FC0C for ; Wed, 30 Jun 2010 15:55:57 +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 o5UFtvEr024557 for ; Wed, 30 Jun 2010 08:55:57 -0700 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 697722D6014 for ; Wed, 30 Jun 2010 08:55:56 -0700 (PDT) Message-ID: <4C2B6922.6090300@elischer.org> Date: Wed, 30 Jun 2010 08:56:18 -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: freebsd-arch@freebsd.org References: <4C2AB793.4040601@laposte.net> <20100630034622.GA48794@troutmask.apl.washington.edu> <4C2B11A9.4020206@laposte.net> In-Reply-To: <4C2B11A9.4020206@laposte.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Subject: Re: dwb : groff replacement proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 15:55:58 -0000 On 6/30/10 2:43 AM, Cyrille Lefevre wrote: > > Le 30/06/2010 05:46, Steve Kargl a écrit : >> >> On Wed, Jun 30, 2010 at 05:18:43AM +0200, Cyrille Lefevre wrote: >>> >>> seen on http://wiki.freebsd.org/ContribSoftware, groff have switch >>> to GPLv3 license, so, >> >> So what? The version of groff in the src/ isn't >> going to suddenly stop working. Please send this >> type of email to free-advocacy or freebsd-chat. >> It has no place here. > > it was just for information and I do not know every dozen freebsd lists > by heart... so I appology. > however, you answer remember me why I quit FreeBSD, cease fire, courtesy > is the key. > > Regards, > > Cyrille Lefevre Steve K's social skills leave a bit to be desired, but the question remains, "is there a good reason to do this?" as a work to gain trade-off, do we get anything we don't already have? It seems to me that the PWB version is pretty unmaintained. it could of course be because it is now perfect.. :-) From owner-freebsd-arch@FreeBSD.ORG Wed Jun 30 17:07:59 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F6E6106564A for ; Wed, 30 Jun 2010 17:07:59 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 22AE18FC12 for ; Wed, 30 Jun 2010 17:07:59 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o5UH7w9v052604; Wed, 30 Jun 2010 10:07:58 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o5UH7wTP052603; Wed, 30 Jun 2010 10:07:58 -0700 (PDT) (envelope-from sgk) Date: Wed, 30 Jun 2010 10:07:57 -0700 From: Steve Kargl To: Julian Elischer Message-ID: <20100630170757.GA52509@troutmask.apl.washington.edu> References: <4C2AB793.4040601@laposte.net> <20100630034622.GA48794@troutmask.apl.washington.edu> <4C2B11A9.4020206@laposte.net> <4C2B6922.6090300@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C2B6922.6090300@elischer.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: dwb : groff replacement proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 17:07:59 -0000 On Wed, Jun 30, 2010 at 08:56:18AM -0700, Julian Elischer wrote: > On 6/30/10 2:43 AM, Cyrille Lefevre wrote: > > > >Le 30/06/2010 05:46, Steve Kargl a ?crit : > >> > >>On Wed, Jun 30, 2010 at 05:18:43AM +0200, Cyrille Lefevre wrote: > >>> > >>>seen on http://wiki.freebsd.org/ContribSoftware, groff have switch > >>>to GPLv3 license, so, > >> > >>So what? The version of groff in the src/ isn't > >>going to suddenly stop working. Please send this > >>type of email to free-advocacy or freebsd-chat. > >>It has no place here. > > > >it was just for information and I do not know every dozen freebsd lists > >by heart... so I appology. > >however, you answer remember me why I quit FreeBSD, cease fire, courtesy > >is the key. > > > >Regards, > > > >Cyrille Lefevre > > Steve K's social skills leave a bit to be desired, but the question > remains, "is there a good reason to do this?" Oh please. It was a legitimate question. So what if groff is now gplv3? The version contained in src/ is not sudden going to stop working and it is not suddenly going to become gplv3. The fact remains that there is no available alternative that contains the functionality of groff. Perhaps, the best alternative is The Heirloom Documentation Tools at http://heirloom.sourceforge.net/doctools.html. Several weeks ago, I got the heirloom tools to compile (after fixing several bugs) on x86_64-*-freebsd only to find that the tools segfault on all manpages I tried to render. -- Steve From owner-freebsd-arch@FreeBSD.ORG Wed Jun 30 19:27:10 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79268106564A for ; Wed, 30 Jun 2010 19:27:10 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp1.one.com (csmtp1.one.com [195.47.247.21]) by mx1.freebsd.org (Postfix) with ESMTP id 0EF998FC08 for ; Wed, 30 Jun 2010 19:27:09 +0000 (UTC) Received: from [192.168.10.164] (0x573b9942.cpe.ge-1-2-0-1101.ronqu1.customer.tele.dk [87.59.153.66]) by csmtp1.one.com (Postfix) with ESMTP id 91CE81BC00EEA; Wed, 30 Jun 2010 18:48:05 +0000 (UTC) References: <4C2AB793.4040601@laposte.net> <20100630034622.GA48794@troutmask.apl.washington.edu> <4C2B11A9.4020206@laposte.net> <4C2B6922.6090300@elischer.org> <20100630170757.GA52509@troutmask.apl.washington.edu> In-Reply-To: <20100630170757.GA52509@troutmask.apl.washington.edu> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4--1031225403; protocol="application/pkcs7-signature" Message-Id: <877EF62B-D2BE-422F-8545-DBC63E5AA682@cederstrand.dk> From: Erik Cederstrand Date: Wed, 30 Jun 2010 20:48:04 +0200 To: Steve Kargl X-Mailer: Apple Mail (2.1081) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: dwb : groff replacement proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 19:27:10 -0000 --Apple-Mail-4--1031225403 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Den 30/06/2010 kl. 19.07 skrev Steve Kargl: >=20 > The fact remains that there is no available alternative that > contains the functionality of groff. I still can't read from this discussion if FreeBSD base actually needs = all the functionality that groff provides, and if the proposed = alternatives are lacking needed functionality which cannot be worked = around by simple changes to the distributed man-pages like the ones = committed in the last weeks. I may be horribly misinformed, but man-page rendering does seem like a = fairly simple task. Erik= --Apple-Mail-4--1031225403-- From owner-freebsd-arch@FreeBSD.ORG Wed Jun 30 20:41:41 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6989C1065741 for ; Wed, 30 Jun 2010 20:41:41 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1C1B28FC08 for ; Wed, 30 Jun 2010 20:41:40 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.3/8.14.3) id o5UK1xPF003949; Wed, 30 Jun 2010 20:01:59 GMT (envelope-from tim@kientzle.com) Received: from [10.123.2.173] (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id 4kanf4etb4nr533fi42eansrm2; Wed, 30 Jun 2010 20:01:59 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <877EF62B-D2BE-422F-8545-DBC63E5AA682@cederstrand.dk> Date: Wed, 30 Jun 2010 13:01:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C2AB793.4040601@laposte.net> <20100630034622.GA48794@troutmask.apl.washington.edu> <4C2B11A9.4020206@laposte.net> <4C2B6922.6090300@elischer.org> <20100630170757.GA52509@troutmask.apl.washington.edu> <877EF62B-D2BE-422F-8545-DBC63E5AA682@cederstrand.dk> To: Erik Cederstrand X-Mailer: Apple Mail (2.1081) Cc: Julian Elischer , Steve Kargl , freebsd-arch@freebsd.org Subject: Re: dwb : groff replacement proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 20:41:41 -0000 On Jun 30, 2010, at 11:48 AM, Erik Cederstrand wrote: > Den 30/06/2010 kl. 19.07 skrev Steve Kargl: >>=20 >> The fact remains that there is no available alternative that >> contains the functionality of groff. >=20 > I still can't read from this discussion if FreeBSD base actually needs = all the functionality that groff provides, and if the proposed = alternatives are lacking needed functionality which cannot be worked = around by simple changes to the distributed man-pages like the ones = committed in the last weeks. >=20 > I may be horribly misinformed, but man-page rendering does seem like a = fairly simple task. As many have pointed out, "replacing groff" is certainly not a priority for the project. Our current groff works, works reasonably well, and is likely to meet our needs for at least another decade (unlike C or C++, nroff functionality is not a moving target). But more importantly "correct man-page rendering" is actually pretty hard. The issue is not the manpages in the FreeBSD base---we can and should clean those up and experimentally rendering them with other tools is a good way to verify them. The problem comes with third-party manpages, including those installed by ports. Either the in-base replacement is pretty much bug-for-bug compatible with groff or else everyone will have to install groff anyway, which defeats most of the point of replacing groff in base. That said, if someone has tested an alternative to ensure that it provides the same quality output as groff across a wide swathe of base and ports-installed manpages, and there are other real advantages (license, size, features, complexity), then I think it's = worth considering. Tim From owner-freebsd-arch@FreeBSD.ORG Wed Jun 30 21:01:48 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF8FC106564A for ; Wed, 30 Jun 2010 21:01:48 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 7F6D98FC16 for ; Wed, 30 Jun 2010 21:01:46 +0000 (UTC) Received: from park.js.berklix.net (p549A7CDC.dip.t-dialin.net [84.154.124.220]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o5UL1bPM035704; Wed, 30 Jun 2010 21:01:39 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o5UL0wvc009012; Wed, 30 Jun 2010 23:00:58 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o5UL0L5X058705; Wed, 30 Jun 2010 23:00:26 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201006302100.o5UL0L5X058705@fire.js.berklix.net> To: Erik Cederstrand From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 30 Jun 2010 20:48:04 +0200." <877EF62B-D2BE-422F-8545-DBC63E5AA682@cederstrand.dk> Date: Wed, 30 Jun 2010 23:00:21 +0200 Sender: jhs@berklix.com Cc: Julian Elischer , Steve Kargl , freebsd-arch@freebsd.org Subject: Re: dwb : groff replacement proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 21:01:49 -0000 > Den 30/06/2010 kl. 19.07 skrev Steve Kargl: > >=20 > > The fact remains that there is no available alternative that > > contains the functionality of groff. > > I still can't read from this discussion if FreeBSD base actually needs = > all the functionality that groff provides, and if the proposed = > alternatives are lacking needed functionality which cannot be worked = > around by simple changes to the distributed man-pages like the ones = > committed in the last weeks. > > I may be horribly misinformed, but man-page rendering does seem like a = > fairly simple task. > > Erik= There's more use of groff than just being a man page builder. I personaly use it for lots of things, eg (multi lingual (human language) front end input & multiple back end output to .ps .asc & .html, & I developed patches to allow wysiwyg so you can vi in an xterm & each time you type :w , a remake occurs, & gv/ghostview redisplays the .ps (without clicking redisplay). http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/wysiwyg.shar.asc Doubtless some other groff users too, whether or not on FreeBSD mail lists. There's been a roff in Unix since V6 ie 1978 or so. Principle of least surprise tilts us to try to avoid discarding it from src/ to ports/, as it would make our Unix less easy to use than others (& we BSDs are supposed to be true Unix inheritance :-) Even BSD needs groff: If some people might rewrite all FreeBSD manuals in some other format, that would still leave other BSD uses of groff eg: new imports to src/ of bits from other BSD eg Net/Open/Dragon whatever, ditto if we import sources from other Unix eg Linux, Solaris, HP-UX etc, & just think of the vast swathe of 3rd party PD software in ports, chunks written by long time Unix people, who of course have written manuals for tools in roff/ nroff/ troff/ groff type syntax. Tossing groff out of src/ to ports/ (as someone suggested a month or so back) would be bad. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML quoted-printable Base64 http://www.asciiribbon.org From owner-freebsd-arch@FreeBSD.ORG Thu Jul 1 04:35:02 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71E041065674 for ; Thu, 1 Jul 2010 04:35:02 +0000 (UTC) (envelope-from cyrille.lefevre-lists@laposte.net) Received: from out2.laposte.net (out1.laposte.net [193.251.214.118]) by mx1.freebsd.org (Postfix) with ESMTP id F18A58FC12 for ; Thu, 1 Jul 2010 04:35:01 +0000 (UTC) Received: from out1.laposte.net (unknown [10.98.49.225]) by mwinf8210.laposte.net (SMTP Server) with ESMTP id E664E1C00605 for ; Thu, 1 Jul 2010 06:05:32 +0200 (CEST) Received: from meplus.info (localhost [127.0.0.1]) by mwinf8211.laposte.net (SMTP Server) with ESMTP id D214C7000084; Thu, 1 Jul 2010 06:05:30 +0200 (CEST) Received: from [192.168.1.133] (156.64.99-84.rev.gaoland.net [84.99.64.156]) by mwinf8211.laposte.net (SMTP Server) with ESMTP id 2930E7000083; Thu, 1 Jul 2010 06:05:28 +0200 (CEST) X-ME-UUID: 20100701040529168.2930E7000083@mwinf8211.laposte.net Message-ID: <4C2C1408.6080703@laposte.net> Date: Thu, 01 Jul 2010 06:05:28 +0200 From: Cyrille Lefevre Organization: ACME User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Julian H. Stacey" References: <201006302100.o5UL0L5X058705@fire.js.berklix.net> In-Reply-To: <201006302100.o5UL0L5X058705@fire.js.berklix.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-me-spamlevel: not-spam X-me-spamrating: 33.200001 X-me-spamcause: OK, (-170)(0000)gggruggvucftvghtrhhoucdtuddrvdelhedrtdejucetggdotefuucfrrhhofhhilhgvmecuoehnohhnvgeqnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenlhhinhhugiculddquddtmdenfhhrvggvsghsugefgiculddqfedtmdenuefuffefgiculddqfedtmd Cc: Steve Kargl , Julian Elischer , Erik Cederstrand , freebsd-arch@freebsd.org Subject: Re: dwb : groff replacement proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 04:35:02 -0000 Le 30/06/2010 23:00, Julian H. Stacey a =E9crit : >> Den 30/06/2010 kl. 19.07 skrev Steve Kargl: Hi, first of all, I'm not asking to rid out groff from FreeBSD, but I know that *BSD aims to be FSF not aware. I've just seen a few days ago that the "Documenters Work Bench" is=20 available for download. for the ones who don't know what is the DWB, it's the nroff/troff=20 package which inspired groff... no more than this. I then inform you about a possible replacement of groff w/ the DWB. well, the license has to be studed, the troff driver list would be=20 minimal and the mdoc macros would probably be adapted. however, it would probably render manual pages on tty, which is the=20 primary usage asked, I am wrong ? >>> The fact remains that there is no available alternative that >>> contains the functionality of groff. maybe not all functionalities, but at least the one which is to render=20 well on tty. I may be wrong... of course, for printing, groff will be=20 more adavanced, but is this really needed for the common usage ? and if=20 this feature is needed, it may be sufficient to have if from ports. >> I still can't read from this discussion if FreeBSD base actually needs= >> all the functionality that groff provides, and if the proposed >> alternatives are lacking needed functionality which cannot be worked >> around by simple changes to the distributed man-pages like the ones >> committed in the last weeks. >> >> I may be horribly misinformed, but man-page rendering does seem like a= >> fairly simple task. you're right. > There's more use of groff than just being a man page builder. > > I personaly use it for lots of things, eg this point doesn't require groff in src/ :-) > Doubtless some other groff users too, whether or not on FreeBSD mail li= sts. > There's been a roff in Unix since V6 ie 1978 or so. Principle > of least surprise tilts us to try to avoid discarding it from > src/ to ports/, as it would make our Unix less easy to use than > others (& we BSDs are supposed to be true Unix inheritance :-) nobody's asking to get rid of *roff... > Even BSD needs groff: > If some people might rewrite all FreeBSD manuals in some > other format, that would still leave other BSD uses of groff eg: > new imports to src/ of bits from other BSD eg Net/Open/Dragon whate= ver, > ditto if we import sources from other Unix eg Linux, > Solaris, HP-UX etc,& just think of the vast swathe of 3rd > party PD software in ports, chunks written by long time Unix > people, who of course have written manuals for tools in > roff/ nroff/ troff/ groff type syntax. if the mdoc macros may be adapted to the DWB, there would be no loss of=20 functionality and since the usual manual pages uses the man macros,=20 which is of course provided as well as the mm and ms macros ones. it's not even impossible than the DWB render better then groff :-) in any case, it's just a story of macros, no more than this, no need to=20 rewrite anything and so. the only problem may be the use of GNUism as if someone wanted to run as = bash script under dash... they are wrong to go this way. > Tossing groff out of src/ to ports/ (as someone suggested a month > or so back) would be bad. except if an acceptable replacement alternative exists and the DWB may=20 be the one ? Regards, Cyrille Lefevre --=20 mailto:Cyrille.Lefevre-lists@laposte.net From owner-freebsd-arch@FreeBSD.ORG Thu Jul 1 05:37:18 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C1201065672 for ; Thu, 1 Jul 2010 05:37:18 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) by mx1.freebsd.org (Postfix) with ESMTP id 9A0A58FC13 for ; Thu, 1 Jul 2010 05:37:17 +0000 (UTC) Received: from [192.168.0.32] (0x573fa596.cpe.ge-1-1-0-1109.ronqu1.customer.tele.dk [87.63.165.150]) by csmtp3.one.com (Postfix) with ESMTP id 23B3D24091A0; Thu, 1 Jul 2010 05:37:16 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-79--992274866; protocol="application/pkcs7-signature"; micalg=sha1 From: Erik Cederstrand In-Reply-To: Date: Thu, 1 Jul 2010 07:37:15 +0200 Message-Id: References: <4C2AB793.4040601@laposte.net> <20100630034622.GA48794@troutmask.apl.washington.edu> <4C2B11A9.4020206@laposte.net> <4C2B6922.6090300@elischer.org> <20100630170757.GA52509@troutmask.apl.washington.edu> <877EF62B-D2BE-422F-8545-DBC63E5AA682@cederstrand.dk> To: Tim Kientzle X-Mailer: Apple Mail (2.1081) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-arch@freebsd.org Subject: Re: dwb : groff replacement proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 05:37:18 -0000 --Apple-Mail-79--992274866 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Den 30/06/2010 kl. 22.01 skrev Tim Kientzle: > > As many have pointed out, "replacing groff" is certainly > not a priority for the project. Our current groff works, > works reasonably well, and is likely to meet our > needs for at least another decade (unlike C or C++, > nroff functionality is not a moving target). > > But more importantly "correct man-page rendering" is actually > pretty hard. The issue is not the manpages in the > FreeBSD base---we can and should clean those up > and experimentally rendering them with other tools is > a good way to verify them. The problem comes with third-party > manpages, including those installed by ports. Either the > in-base replacement is pretty much bug-for-bug compatible > with groff or else everyone will have to install groff anyway, > which defeats most of the point of replacing groff in base. > > That said, if someone has tested an alternative to ensure that > it provides the same quality output as groff across a wide swathe > of base and ports-installed manpages, and there are other real > advantages (license, size, features, complexity), then I think it's worth > considering. Thanks. Just the clarification I was looking for. Erik --Apple-Mail-79--992274866-- From owner-freebsd-arch@FreeBSD.ORG Thu Jul 1 13:42:22 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B147B1065670 for ; Thu, 1 Jul 2010 13:42:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id C30188FC1C for ; Thu, 1 Jul 2010 13:42:21 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o61DgHjM006071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Jul 2010 16:42:17 +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 o61DgHfK000165 for ; Thu, 1 Jul 2010 16:42:17 +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 o61DgHOO000164 for arch@freebsd.org; Thu, 1 Jul 2010 16:42:17 +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: Thu, 1 Jul 2010 16:42:17 +0300 From: Kostik Belousov To: arch@freebsd.org Message-ID: <20100701134217.GM13238@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w9Xseu/t+w8u+RRD" Content-Disposition: inline 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: Subject: Access to siginfo for the signal from debugger X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 13:42:22 -0000 --w9Xseu/t+w8u+RRD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, below is the patch that provides the debugger with access to siginfo of the signal that stopped the debuggee. This allows to see a lot more details for the cause of the process stop. E.g. you can see a fault address if process get SIGSEGV or SIGBUS, you can distinguish between breakpoint-generated SIGTRAP and non-breakpoint, whether the signal was send due to external event etc. The change to struct ptrace_lwpinfo is backward-compatible in the sense that programs that were compiled with old definition for the struct will work on new kernels. I tested the change on i386 and amd64, both native and ia32 mode. diff --git a/sys/compat/freebsd32/freebsd32_misc.c b/sys/compat/freebsd32/f= reebsd32_misc.c index f0fde2b..1d60ed4 100644 --- a/sys/compat/freebsd32/freebsd32_misc.c +++ b/sys/compat/freebsd32/freebsd32_misc.c @@ -2208,7 +2208,7 @@ freebsd32_thr_suspend(struct thread *td, struct freeb= sd32_thr_suspend_args *uap) } =20 void -siginfo_to_siginfo32(siginfo_t *src, struct siginfo32 *dst) +siginfo_to_siginfo32(const siginfo_t *src, struct siginfo32 *dst) { bzero(dst, sizeof(*dst)); dst->si_signo =3D src->si_signo; diff --git a/sys/compat/freebsd32/freebsd32_signal.h b/sys/compat/freebsd32= /freebsd32_signal.h index ba0922a..2669581 100644 --- a/sys/compat/freebsd32/freebsd32_signal.h +++ b/sys/compat/freebsd32/freebsd32_signal.h @@ -96,6 +96,6 @@ struct sigevent32 { } _sigev_un; }; =20 -void siginfo_to_siginfo32(siginfo_t *src, struct siginfo32 *dst); +void siginfo_to_siginfo32(const siginfo_t *src, struct siginfo32 *dst); =20 #endif /* !_COMPAT_FREEBSD32_SIGNAL_H_ */ diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 04c2ba7..af3c7da 100644 --- a/sys/kern/kern_sig.c +++ b/sys/kern/kern_sig.c @@ -2522,7 +2522,6 @@ issignal(struct thread *td, int stop_allowed) struct sigacts *ps; struct sigqueue *queue; sigset_t sigpending; - ksiginfo_t ksi; int sig, prop, newsig; =20 p =3D td->td_proc; @@ -2565,10 +2564,10 @@ issignal(struct thread *td, int stop_allowed) * be thrown away. */ queue =3D &td->td_sigqueue; - ksi.ksi_signo =3D 0; - if (sigqueue_get(queue, sig, &ksi) =3D=3D 0) { + td->td_dbgksi.ksi_signo =3D 0; + if (sigqueue_get(queue, sig, &td->td_dbgksi) =3D=3D 0) { queue =3D &p->p_sigqueue; - sigqueue_get(queue, sig, &ksi); + sigqueue_get(queue, sig, &td->td_dbgksi); } =20 mtx_unlock(&ps->ps_mtx); @@ -2595,13 +2594,13 @@ issignal(struct thread *td, int stop_allowed) continue; signotify(td); } else { - if (ksi.ksi_signo !=3D 0) { - ksi.ksi_flags |=3D KSI_HEAD; + if (td->td_dbgksi.ksi_signo !=3D 0) { + td->td_dbgksi.ksi_flags |=3D KSI_HEAD; if (sigqueue_add(&td->td_sigqueue, sig, - &ksi) !=3D 0) - ksi.ksi_signo =3D 0; + &td->td_dbgksi) !=3D 0) + td->td_dbgksi.ksi_signo =3D 0; } - if (ksi.ksi_signo =3D=3D 0) + if (td->td_dbgksi.ksi_signo =3D=3D 0) sigqueue_add(&td->td_sigqueue, sig, NULL); } diff --git a/sys/kern/sys_process.c b/sys/kern/sys_process.c index 40c861b..525c0e2 100644 --- a/sys/kern/sys_process.c +++ b/sys/kern/sys_process.c @@ -64,6 +64,7 @@ __FBSDID("$FreeBSD$"); =20 #ifdef COMPAT_FREEBSD32 #include +#include =20 struct ptrace_io_desc32 { int piod_op; @@ -85,6 +86,15 @@ struct ptrace_vm_entry32 { uint32_t pve_path; }; =20 +struct ptrace_lwpinfo32 { + lwpid_t pl_lwpid; /* LWP described. */ + int pl_event; /* Event that stopped the LWP. */ + int pl_flags; /* LWP flags. */ + sigset_t pl_sigmask; /* LWP signal mask */ + sigset_t pl_siglist; /* LWP pending signal */ + struct siginfo32 pl_siginfo; /* siginfo for signal */ +}; + #endif =20 /* @@ -498,6 +508,19 @@ ptrace_vm_entry32(struct thread *td, struct proc *p, pve32->pve_pathlen =3D pve.pve_pathlen; return (error); } + +static void +ptrace_lwpinfo_to32(const struct ptrace_lwpinfo *pl, + struct ptrace_lwpinfo32 *pl32) +{ + + pl32->pl_lwpid =3D pl->pl_lwpid; + pl32->pl_event =3D pl->pl_event; + pl32->pl_flags =3D pl->pl_flags; + pl32->pl_sigmask =3D pl->pl_sigmask; + pl32->pl_siglist =3D pl->pl_siglist; + siginfo_to_siginfo32(&pl->pl_siginfo, &pl32->pl_siginfo); +} #endif /* COMPAT_FREEBSD32 */ =20 /* @@ -552,6 +575,7 @@ ptrace(struct thread *td, struct ptrace_args *uap) struct fpreg32 fpreg32; struct reg32 reg32; struct ptrace_io_desc32 piod32; + struct ptrace_lwpinfo32 pl32; struct ptrace_vm_entry32 pve32; #endif } r; @@ -662,6 +686,8 @@ kern_ptrace(struct thread *td, int req, pid_t pid, void= *addr, int data) #ifdef COMPAT_FREEBSD32 int wrap32 =3D 0, safe =3D 0; struct ptrace_io_desc32 *piod32 =3D NULL; + struct ptrace_lwpinfo32 *pl32 =3D NULL; + struct ptrace_lwpinfo plr; #endif =20 curp =3D td->td_proc; @@ -1103,15 +1129,44 @@ kern_ptrace(struct thread *td, int req, pid_t pid, = void *addr, int data) break; =20 case PT_LWPINFO: - if (data <=3D 0 || data > sizeof(*pl)) { + if (data <=3D 0 || +#ifdef COMPAT_FREEBSD32 + (!wrap32 && data > sizeof(*pl)) || + (wrap32 && data > sizeof(*pl32))) { +#else + data > sizeof(*pl)) { +#endif error =3D EINVAL; break; } +#ifdef COMPAT_FREEBSD32 + if (wrap32) { + pl =3D &plr; + pl32 =3D addr; + } else +#endif pl =3D addr; pl->pl_lwpid =3D td2->td_tid; - if (td2->td_dbgflags & TDB_XSIG) - pl->pl_event =3D PL_EVENT_SIGNAL; pl->pl_flags =3D 0; + if (td2->td_dbgflags & TDB_XSIG) { + pl->pl_event =3D PL_EVENT_SIGNAL; + if (td2->td_dbgksi.ksi_signo !=3D 0 && +#ifdef COMPAT_FREEBSD32 + ((!wrap32 && data >=3D offsetof(struct ptrace_lwpinfo, + pl_siginfo) + sizeof(pl->pl_siginfo)) || + (wrap32 && data >=3D offsetof(struct ptrace_lwpinfo32, + pl_siginfo) + sizeof(struct siginfo32))) +#else + data >=3D offsetof(struct ptrace_lwpinfo, pl_siginfo) + + sizeof(pl->pl_siginfo) +#endif + ){ + pl->pl_flags |=3D PL_FLAG_SI; + pl->pl_siginfo =3D td2->td_dbgksi.ksi_info; + } + } + if ((pl->pl_flags & PL_FLAG_SI) =3D=3D 0) + bzero(&pl->pl_siginfo, sizeof(pl->pl_siginfo)); if (td2->td_dbgflags & TDB_SCE) pl->pl_flags |=3D PL_FLAG_SCE; else if (td2->td_dbgflags & TDB_SCX) @@ -1120,6 +1175,10 @@ kern_ptrace(struct thread *td, int req, pid_t pid, v= oid *addr, int data) pl->pl_flags |=3D PL_FLAG_EXEC; pl->pl_sigmask =3D td2->td_sigmask; pl->pl_siglist =3D td2->td_siglist; +#ifdef COMPAT_FREEBSD32 + if (wrap32) + ptrace_lwpinfo_to32(pl, pl32); +#endif break; =20 case PT_GETNUMLWPS: diff --git a/sys/sys/proc.h b/sys/sys/proc.h index 3c9a2de..cd00550 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -259,6 +259,7 @@ struct thread { char td_name[MAXCOMLEN + 1]; /* (*) Thread name. */ struct file *td_fpop; /* (k) file referencing cdev under op */ int td_dbgflags; /* (c) Userland debugger flags */ + struct ksiginfo td_dbgksi; /* (c) ksi reflected to debugger. */ int td_ng_outbound; /* (k) Thread entered ng from above. */ struct osd td_osd; /* (k) Object specific data. */ #define td_endzero td_base_pri diff --git a/sys/sys/ptrace.h b/sys/sys/ptrace.h index a6dbe2c..f4b25d4 100644 --- a/sys/sys/ptrace.h +++ b/sys/sys/ptrace.h @@ -33,7 +33,7 @@ #ifndef _SYS_PTRACE_H_ #define _SYS_PTRACE_H_ =20 -#include +#include #include =20 #define PT_TRACE_ME 0 /* child declares it's being traced */ @@ -102,8 +102,10 @@ struct ptrace_lwpinfo { #define PL_FLAG_SCE 0x04 /* syscall enter point */ #define PL_FLAG_SCX 0x08 /* syscall leave point */ #define PL_FLAG_EXEC 0x10 /* exec(2) succeeded */ +#define PL_FLAG_SI 0x20 /* siginfo is valid */ sigset_t pl_sigmask; /* LWP signal mask */ sigset_t pl_siglist; /* LWP pending signal */ + struct __siginfo pl_siginfo; /* siginfo for signal */ }; =20 /* Argument structure for PT_VM_ENTRY. */ --w9Xseu/t+w8u+RRD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwsmzkACgkQC3+MBN1Mb4ilGgCglKAG92I6om1+whCrt1gAY+WZ lC0AnAhdBxREUd2SU0xeOwL3aXWIxuIf =aH25 -----END PGP SIGNATURE----- --w9Xseu/t+w8u+RRD-- From owner-freebsd-arch@FreeBSD.ORG Thu Jul 1 21:06:08 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CAEF106566B for ; Thu, 1 Jul 2010 21:06:08 +0000 (UTC) (envelope-from john@baldwin.cx) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5016A8FC08 for ; Thu, 1 Jul 2010 21:06:08 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E025946B17; Thu, 1 Jul 2010 17:06:07 -0400 (EDT) Received: from zion.baldwin.cx (c-68-45-19-154.hsd1.nj.comcast.net [68.45.19.154]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B0FC58A03C; Thu, 1 Jul 2010 17:06:06 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 1 Jul 2010 17:05:26 -0400 User-Agent: KMail/1.12.4 (FreeBSD/7.3-PRERELEASE; KDE/4.3.4; i386; ; ) References: <20100701134217.GM13238@deviant.kiev.zoral.com.ua> In-Reply-To: <20100701134217.GM13238@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201007011705.26173.john@baldwin.cx> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 01 Jul 2010 17:06:06 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Kostik Belousov Subject: Re: Access to siginfo for the signal from debugger X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 21:06:08 -0000 On Thursday 01 July 2010 09:42:17 am Kostik Belousov wrote: > Hi, > below is the patch that provides the debugger with access to siginfo > of the signal that stopped the debuggee. This allows to see a lot more > details for the cause of the process stop. E.g. you can see a fault > address if process get SIGSEGV or SIGBUS, you can distinguish between > breakpoint-generated SIGTRAP and non-breakpoint, whether the signal > was send due to external event etc. > > The change to struct ptrace_lwpinfo is backward-compatible in the sense > that programs that were compiled with old definition for the struct will > work on new kernels. Nice! Does gdb "just work" with these changes or does it need patching as well? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Jul 1 21:27:44 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E5F21065673 for ; Thu, 1 Jul 2010 21:27:44 +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 DCDC38FC08 for ; Thu, 1 Jul 2010 21:27:43 +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 o61LRAV0040531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Jul 2010 00:27:10 +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 o61LRA17003932; Fri, 2 Jul 2010 00:27:10 +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 o61LRAtw003931; Fri, 2 Jul 2010 00:27:10 +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: Fri, 2 Jul 2010 00:27:10 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20100701212710.GP13238@deviant.kiev.zoral.com.ua> References: <20100701134217.GM13238@deviant.kiev.zoral.com.ua> <201007011705.26173.john@baldwin.cx> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d81eMP4bt36Qfuc6" Content-Disposition: inline In-Reply-To: <201007011705.26173.john@baldwin.cx> 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-arch@freebsd.org Subject: Re: Access to siginfo for the signal from debugger X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 21:27:44 -0000 --d81eMP4bt36Qfuc6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 01, 2010 at 05:05:26PM -0400, John Baldwin wrote: > On Thursday 01 July 2010 09:42:17 am Kostik Belousov wrote: > > Hi, > > below is the patch that provides the debugger with access to siginfo > > of the signal that stopped the debuggee. This allows to see a lot more > > details for the cause of the process stop. E.g. you can see a fault > > address if process get SIGSEGV or SIGBUS, you can distinguish between > > breakpoint-generated SIGTRAP and non-breakpoint, whether the signal > > was send due to external event etc. > >=20 > > The change to struct ptrace_lwpinfo is backward-compatible in the sense > > that programs that were compiled with old definition for the struct will > > work on new kernels. >=20 > Nice! Does gdb "just work" with these changes or does it need patching a= s=20 > well? It should "just work", and my testing seems to confirm this. gdb uses PT_LWPINFO to enumerate the thread ids, and I checked it on mt process. As I said, the change is ABI backward-compatible, i.e. you do not need even to recompile the old program for new kernel. Sure, gdb cannot show additional available information without modifications. --d81eMP4bt36Qfuc6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwtCC0ACgkQC3+MBN1Mb4jjAwCdG8/1I3EXl1uzNfqNjI35ZbBj 7eYAn2ZRUrNca7m/H6aUMRBTlTyjMhsM =sduh -----END PGP SIGNATURE----- --d81eMP4bt36Qfuc6-- From owner-freebsd-arch@FreeBSD.ORG Fri Jul 2 02:13:59 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 781581065670 for ; Fri, 2 Jul 2010 02:13:59 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 65CF28FC17; Fri, 2 Jul 2010 02:13:59 +0000 (UTC) Received: from apple.my.domain (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o622Dv6M086952; Fri, 2 Jul 2010 02:13:58 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4C2D4B65.8080708@freebsd.org> Date: Fri, 02 Jul 2010 10:13:57 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Kostik Belousov References: <20100701134217.GM13238@deviant.kiev.zoral.com.ua> <201007011705.26173.john@baldwin.cx> <20100701212710.GP13238@deviant.kiev.zoral.com.ua> In-Reply-To: <20100701212710.GP13238@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John Baldwin , freebsd-arch@freebsd.org Subject: Re: Access to siginfo for the signal from debugger X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 02:13:59 -0000 Kostik Belousov wrote: > On Thu, Jul 01, 2010 at 05:05:26PM -0400, John Baldwin wrote: >> On Thursday 01 July 2010 09:42:17 am Kostik Belousov wrote: >>> Hi, >>> below is the patch that provides the debugger with access to siginfo >>> of the signal that stopped the debuggee. This allows to see a lot more >>> details for the cause of the process stop. E.g. you can see a fault >>> address if process get SIGSEGV or SIGBUS, you can distinguish between >>> breakpoint-generated SIGTRAP and non-breakpoint, whether the signal >>> was send due to external event etc. >>> >>> The change to struct ptrace_lwpinfo is backward-compatible in the sense >>> that programs that were compiled with old definition for the struct will >>> work on new kernels. >> Nice! Does gdb "just work" with these changes or does it need patching as >> well? > It should "just work", and my testing seems to confirm this. gdb uses > PT_LWPINFO to enumerate the thread ids, and I checked it on mt process. > > As I said, the change is ABI backward-compatible, i.e. you do not need > even to recompile the old program for new kernel. > > Sure, gdb cannot show additional available information without > modifications. Yes, you can add new fields to ptrace_lwpinfo without any problem. To print new fields, you should change the function fbsd_thread_signal_cmd in file src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c after change, you just type 'thread signal' command in gdb to show thread's signal info. The command is freebsd specific, others may or may not have it. Regards, David Xu From owner-freebsd-arch@FreeBSD.ORG Fri Jul 2 02:51:53 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 357F11065674 for ; Fri, 2 Jul 2010 02:51:53 +0000 (UTC) (envelope-from cyrille.lefevre-lists@laposte.net) Received: from out5.laposte.net (out6.laposte.net [193.251.214.123]) by mx1.freebsd.org (Postfix) with ESMTP id DE6098FC13 for ; Fri, 2 Jul 2010 02:51:51 +0000 (UTC) Received: from meplus.info (localhost [127.0.0.1]) by mwinf8402.laposte.net (SMTP Server) with ESMTP id D3A257000085; Fri, 2 Jul 2010 04:51:49 +0200 (CEST) Received: from [192.168.1.133] (156.64.99-84.rev.gaoland.net [84.99.64.156]) by mwinf8402.laposte.net (SMTP Server) with ESMTP id C13ED7000082; Fri, 2 Jul 2010 04:51:45 +0200 (CEST) X-ME-UUID: 20100702025145791.C13ED7000082@mwinf8402.laposte.net Message-ID: <4C2D5441.9020408@laposte.net> Date: Fri, 02 Jul 2010 04:51:45 +0200 From: Cyrille Lefevre Organization: ACME User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: "Julian H. Stacey" References: <201006302100.o5UL0L5X058705@fire.js.berklix.net> <4C2C1408.6080703@laposte.net> In-Reply-To: <4C2C1408.6080703@laposte.net> Content-Type: multipart/mixed; boundary="------------040209070908030303010506" X-me-spamlevel: not-spam X-me-spamrating: 36.000000 X-me-spamcause: OK, (-100)(0000)gggruggvucftvghtrhhoucdtuddrvdelhedrtdelucetggdotefuucfrrhhofhhilhgvmecuoehnohhnvgeqnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Erik Cederstrand , Julian Elischer , Steve Kargl , freebsd-arch@freebsd.org Subject: Re: dwb : groff replacement proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 02:51:53 -0000 This is a multi-part message in MIME format. --------------040209070908030303010506 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi, it works w/ a little change for now. I made it compile under cygwin but more work is needed. out of the box, makefiles don't install everything :-( whenever I have time, I'll make it a port... so, you'll have the possibility to evaluate it. one "major" problem is than nroff uses nterm definitions, this would have to be ported to termcap/terminfo or to convert termcap/terminfo entries to nterm ones ? one minor problem is that everything has to be rearanged to match today's file structure :-) in attachment, you'll find : dwb.txt : the actual directory listing faucet.txt : nroff -Tlp -rd4 -rm1 -ry93 -man | col faucet.ps : troff -man | dpost faucet2.ps : nroff ... | postprint faucet.1 is a standard manual page from netpipes. how do you found the rendering ? in fact, this remember me the nroff/troff Solaris package in regard of dpost filter, etc. Regards, Cyrille Lefevre -- mailto:Cyrille.Lefevre-lists@laposte.net --------------040209070908030303010506 Content-Type: text/plain; name="dwb.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dwb.txt" /opt/dwb/bin/ /opt/dwb/bin/.man.swp /opt/dwb/bin/atoL1 /opt/dwb/bin/checkdoc /opt/dwb/bin/col /opt/dwb/bin/diffmk /opt/dwb/bin/dnroff /opt/dwb/bin/dpcl /opt/dwb/bin/dpost /opt/dwb/bin/dsplit /opt/dwb/bin/dwbv /opt/dwb/bin/eqn /opt/dwb/bin/gc2pic /opt/dwb/bin/grap /opt/dwb/bin/hyphen /opt/dwb/bin/man /opt/dwb/bin/mm /opt/dwb/bin/mmt /opt/dwb/bin/mvt /opt/dwb/bin/ndx /opt/dwb/bin/neqn /opt/dwb/bin/nroff /opt/dwb/bin/otbl /opt/dwb/bin/pic /opt/dwb/bin/picasso /opt/dwb/bin/picpack /opt/dwb/bin/ptx /opt/dwb/bin/subj /opt/dwb/bin/tbl /opt/dwb/bin/tc /opt/dwb/bin/troff /opt/dwb/lbin/ /opt/dwb/lbin/postscript /opt/dwb/lbin/postscript/buildtables /opt/dwb/lbin/postscript/cropmarks /opt/dwb/lbin/postscript/download /opt/dwb/lbin/postscript/grabit /opt/dwb/lbin/postscript/hardcopy /opt/dwb/lbin/postscript/postbgi /opt/dwb/lbin/postscript/postdaisy /opt/dwb/lbin/postscript/postdmd /opt/dwb/lbin/postscript/postgif /opt/dwb/lbin/postscript/postio /opt/dwb/lbin/postscript/postmd /opt/dwb/lbin/postscript/postplot /opt/dwb/lbin/postscript/postprint /opt/dwb/lbin/postscript/postreverse /opt/dwb/lbin/postscript/posttek /opt/dwb/lbin/postscript/printfont /opt/dwb/lbin/postscript/psencoding /opt/dwb/lbin/postscript/trofftable /opt/dwb/lib/ /opt/dwb/lib/dwb /opt/dwb/lib/dwb/deroff /opt/dwb/lib/dwb/xpand /opt/dwb/lib/font /opt/dwb/lib/font/devLatin1 /opt/dwb/lib/font/devLatin1/AB /opt/dwb/lib/font/devLatin1/AI /opt/dwb/lib/font/devLatin1/AR /opt/dwb/lib/font/devLatin1/AX /opt/dwb/lib/font/devLatin1/B /opt/dwb/lib/font/devLatin1/BI /opt/dwb/lib/font/devLatin1/C /opt/dwb/lib/font/devLatin1/CB /opt/dwb/lib/font/devLatin1/charlib /opt/dwb/lib/font/devLatin1/charlib/12 /opt/dwb/lib/font/devLatin1/charlib/14 /opt/dwb/lib/font/devLatin1/charlib/34 /opt/dwb/lib/font/devLatin1/charlib/bx /opt/dwb/lib/font/devLatin1/charlib/ci /opt/dwb/lib/font/devLatin1/charlib/DG /opt/dwb/lib/font/devLatin1/charlib/ff /opt/dwb/lib/font/devLatin1/charlib/Fi /opt/dwb/lib/font/devLatin1/charlib/Fl /opt/dwb/lib/font/devLatin1/charlib/L1 /opt/dwb/lib/font/devLatin1/charlib/LA /opt/dwb/lib/font/devLatin1/charlib/lc /opt/dwb/lib/font/devLatin1/charlib/lf /opt/dwb/lib/font/devLatin1/charlib/LH /opt/dwb/lib/font/devLatin1/charlib/lH /opt/dwb/lib/font/devLatin1/charlib/lh /opt/dwb/lib/font/devLatin1/charlib/LH.example /opt/dwb/lib/font/devLatin1/charlib/LV /opt/dwb/lib/font/devLatin1/charlib/ob /opt/dwb/lib/font/devLatin1/charlib/PC /opt/dwb/lib/font/devLatin1/charlib/RC /opt/dwb/lib/font/devLatin1/charlib/rc /opt/dwb/lib/font/devLatin1/charlib/README /opt/dwb/lib/font/devLatin1/charlib/rf /opt/dwb/lib/font/devLatin1/charlib/rH /opt/dwb/lib/font/devLatin1/charlib/rh /opt/dwb/lib/font/devLatin1/charlib/Sl /opt/dwb/lib/font/devLatin1/charlib/sq /opt/dwb/lib/font/devLatin1/charlib/~= /opt/dwb/lib/font/devLatin1/CI /opt/dwb/lib/font/devLatin1/CO /opt/dwb/lib/font/devLatin1/CW /opt/dwb/lib/font/devLatin1/CX /opt/dwb/lib/font/devLatin1/DESC /opt/dwb/lib/font/devLatin1/GR /opt/dwb/lib/font/devLatin1/H /opt/dwb/lib/font/devLatin1/HB /opt/dwb/lib/font/devLatin1/Hb /opt/dwb/lib/font/devLatin1/HI /opt/dwb/lib/font/devLatin1/Hi /opt/dwb/lib/font/devLatin1/HK /opt/dwb/lib/font/devLatin1/HL /opt/dwb/lib/font/devLatin1/HM /opt/dwb/lib/font/devLatin1/Hr /opt/dwb/lib/font/devLatin1/HX /opt/dwb/lib/font/devLatin1/Hx /opt/dwb/lib/font/devLatin1/I /opt/dwb/lib/font/devLatin1/KB /opt/dwb/lib/font/devLatin1/KI /opt/dwb/lib/font/devLatin1/KR /opt/dwb/lib/font/devLatin1/KX /opt/dwb/lib/font/devLatin1/NB /opt/dwb/lib/font/devLatin1/NI /opt/dwb/lib/font/devLatin1/NR /opt/dwb/lib/font/devLatin1/NX /opt/dwb/lib/font/devLatin1/PA /opt/dwb/lib/font/devLatin1/PB /opt/dwb/lib/font/devLatin1/PI /opt/dwb/lib/font/devLatin1/PX /opt/dwb/lib/font/devLatin1/R /opt/dwb/lib/font/devLatin1/S /opt/dwb/lib/font/devLatin1/S1 /opt/dwb/lib/font/devLatin1/shell.lib /opt/dwb/lib/font/devLatin1/shell.lib.last /opt/dwb/lib/font/devLatin1/shell.lib.old /opt/dwb/lib/font/devLatin1/ZD /opt/dwb/lib/font/devLatin1/ZI /opt/dwb/lib/font/devnroff /opt/dwb/lib/font/devnroff/B /opt/dwb/lib/font/devnroff/CW /opt/dwb/lib/font/devnroff/DESC /opt/dwb/lib/font/devnroff/I /opt/dwb/lib/font/devnroff/R /opt/dwb/lib/font/devnroff/S /opt/dwb/lib/font/devnroff-12 /opt/dwb/lib/font/devnroff-12/B /opt/dwb/lib/font/devnroff-12/CW /opt/dwb/lib/font/devnroff-12/DESC /opt/dwb/lib/font/devnroff-12/I /opt/dwb/lib/font/devnroff-12/R /opt/dwb/lib/font/devnroff-12/S /opt/dwb/lib/font/devopost /opt/dwb/lib/font/devopost/AB /opt/dwb/lib/font/devopost/AI /opt/dwb/lib/font/devopost/AR /opt/dwb/lib/font/devopost/AX /opt/dwb/lib/font/devopost/B /opt/dwb/lib/font/devopost/BI /opt/dwb/lib/font/devopost/CB /opt/dwb/lib/font/devopost/charlib /opt/dwb/lib/font/devopost/charlib/12 /opt/dwb/lib/font/devopost/charlib/14 /opt/dwb/lib/font/devopost/charlib/34 /opt/dwb/lib/font/devopost/charlib/BRACKETS_NOTE /opt/dwb/lib/font/devopost/charlib/bx /opt/dwb/lib/font/devopost/charlib/ci /opt/dwb/lib/font/devopost/charlib/ff /opt/dwb/lib/font/devopost/charlib/Fi /opt/dwb/lib/font/devopost/charlib/Fl /opt/dwb/lib/font/devopost/charlib/L1 /opt/dwb/lib/font/devopost/charlib/L1.map /opt/dwb/lib/font/devopost/charlib/Lb /opt/dwb/lib/font/devopost/charlib/Lb.map /opt/dwb/lib/font/devopost/charlib/lc /opt/dwb/lib/font/devopost/charlib/lf /opt/dwb/lib/font/devopost/charlib/LH /opt/dwb/lib/font/devopost/charlib/lh /opt/dwb/lib/font/devopost/charlib/LH.map /opt/dwb/lib/font/devopost/charlib/ob /opt/dwb/lib/font/devopost/charlib/rc /opt/dwb/lib/font/devopost/charlib/README /opt/dwb/lib/font/devopost/charlib/rf /opt/dwb/lib/font/devopost/charlib/rh /opt/dwb/lib/font/devopost/charlib/Sl /opt/dwb/lib/font/devopost/charlib/sq /opt/dwb/lib/font/devopost/charlib/~= /opt/dwb/lib/font/devopost/CI /opt/dwb/lib/font/devopost/CO /opt/dwb/lib/font/devopost/CW /opt/dwb/lib/font/devopost/CX /opt/dwb/lib/font/devopost/DESC /opt/dwb/lib/font/devopost/GR /opt/dwb/lib/font/devopost/H /opt/dwb/lib/font/devopost/HB /opt/dwb/lib/font/devopost/Hb /opt/dwb/lib/font/devopost/HI /opt/dwb/lib/font/devopost/Hi /opt/dwb/lib/font/devopost/Hr /opt/dwb/lib/font/devopost/HX /opt/dwb/lib/font/devopost/Hx /opt/dwb/lib/font/devopost/I /opt/dwb/lib/font/devopost/KB /opt/dwb/lib/font/devopost/KI /opt/dwb/lib/font/devopost/KR /opt/dwb/lib/font/devopost/KX /opt/dwb/lib/font/devopost/NB /opt/dwb/lib/font/devopost/NI /opt/dwb/lib/font/devopost/NR /opt/dwb/lib/font/devopost/NX /opt/dwb/lib/font/devopost/PA /opt/dwb/lib/font/devopost/PB /opt/dwb/lib/font/devopost/PI /opt/dwb/lib/font/devopost/PX /opt/dwb/lib/font/devopost/R /opt/dwb/lib/font/devopost/S /opt/dwb/lib/font/devopost/S1 /opt/dwb/lib/font/devopost/ZD /opt/dwb/lib/font/devopost/ZI /opt/dwb/lib/font/devpcl /opt/dwb/lib/font/devpcl/B /opt/dwb/lib/font/devpcl/BI /opt/dwb/lib/font/devpcl/CB /opt/dwb/lib/font/devpcl/CW /opt/dwb/lib/font/devpcl/DESC /opt/dwb/lib/font/devpcl/G /opt/dwb/lib/font/devpcl/GI /opt/dwb/lib/font/devpcl/GR /opt/dwb/lib/font/devpcl/H /opt/dwb/lib/font/devpcl/HB /opt/dwb/lib/font/devpcl/HI /opt/dwb/lib/font/devpcl/HK /opt/dwb/lib/font/devpcl/HL /opt/dwb/lib/font/devpcl/HM /opt/dwb/lib/font/devpcl/HX /opt/dwb/lib/font/devpcl/I /opt/dwb/lib/font/devpcl/LO /opt/dwb/lib/font/devpcl/PA /opt/dwb/lib/font/devpcl/PI /opt/dwb/lib/font/devpcl/R /opt/dwb/lib/font/devpcl/S /opt/dwb/lib/font/devpcl/S1 /opt/dwb/lib/font/devpcl/S2 /opt/dwb/lib/font/devpcl/S3 /opt/dwb/lib/font/devpost /opt/dwb/lib/font/devpost/a1 /opt/dwb/lib/font/devpost/a2 /opt/dwb/lib/font/devpost/AB /opt/dwb/lib/font/devpost/AI /opt/dwb/lib/font/devpost/AR /opt/dwb/lib/font/devpost/AX /opt/dwb/lib/font/devpost/B /opt/dwb/lib/font/devpost/BI /opt/dwb/lib/font/devpost/C /opt/dwb/lib/font/devpost/C1 /opt/dwb/lib/font/devpost/c1 /opt/dwb/lib/font/devpost/C2 /opt/dwb/lib/font/devpost/c2 /opt/dwb/lib/font/devpost/C3 /opt/dwb/lib/font/devpost/c3 /opt/dwb/lib/font/devpost/CB /opt/dwb/lib/font/devpost/charlib /opt/dwb/lib/font/devpost/charlib/12 /opt/dwb/lib/font/devpost/charlib/14 /opt/dwb/lib/font/devpost/charlib/34 /opt/dwb/lib/font/devpost/charlib/bx /opt/dwb/lib/font/devpost/charlib/ci /opt/dwb/lib/font/devpost/charlib/DG /opt/dwb/lib/font/devpost/charlib/ff /opt/dwb/lib/font/devpost/charlib/Fi /opt/dwb/lib/font/devpost/charlib/Fl /opt/dwb/lib/font/devpost/charlib/L1 /opt/dwb/lib/font/devpost/charlib/LA /opt/dwb/lib/font/devpost/charlib/lc /opt/dwb/lib/font/devpost/charlib/lf /opt/dwb/lib/font/devpost/charlib/LH /opt/dwb/lib/font/devpost/charlib/lH /opt/dwb/lib/font/devpost/charlib/lh /opt/dwb/lib/font/devpost/charlib/LH.example /opt/dwb/lib/font/devpost/charlib/LV /opt/dwb/lib/font/devpost/charlib/ob /opt/dwb/lib/font/devpost/charlib/PC /opt/dwb/lib/font/devpost/charlib/RC /opt/dwb/lib/font/devpost/charlib/rc /opt/dwb/lib/font/devpost/charlib/README /opt/dwb/lib/font/devpost/charlib/rf /opt/dwb/lib/font/devpost/charlib/rH /opt/dwb/lib/font/devpost/charlib/rh /opt/dwb/lib/font/devpost/charlib/Sl /opt/dwb/lib/font/devpost/charlib/sq /opt/dwb/lib/font/devpost/charlib/~= /opt/dwb/lib/font/devpost/CI /opt/dwb/lib/font/devpost/CO /opt/dwb/lib/font/devpost/CW /opt/dwb/lib/font/devpost/CX /opt/dwb/lib/font/devpost/DESC /opt/dwb/lib/font/devpost/devpost.mk /opt/dwb/lib/font/devpost/F1 /opt/dwb/lib/font/devpost/F2 /opt/dwb/lib/font/devpost/F3 /opt/dwb/lib/font/devpost/F4 /opt/dwb/lib/font/devpost/F5 /opt/dwb/lib/font/devpost/F6 /opt/dwb/lib/font/devpost/G1 /opt/dwb/lib/font/devpost/G2 /opt/dwb/lib/font/devpost/G3 /opt/dwb/lib/font/devpost/G4 /opt/dwb/lib/font/devpost/Gb /opt/dwb/lib/font/devpost/Gi /opt/dwb/lib/font/devpost/GR /opt/dwb/lib/font/devpost/Gr /opt/dwb/lib/font/devpost/Gx /opt/dwb/lib/font/devpost/H /opt/dwb/lib/font/devpost/H1 /opt/dwb/lib/font/devpost/H2 /opt/dwb/lib/font/devpost/H3 /opt/dwb/lib/font/devpost/H4 /opt/dwb/lib/font/devpost/H5 /opt/dwb/lib/font/devpost/H6 /opt/dwb/lib/font/devpost/H7 /opt/dwb/lib/font/devpost/H8 /opt/dwb/lib/font/devpost/HB /opt/dwb/lib/font/devpost/Hb /opt/dwb/lib/font/devpost/HC /opt/dwb/lib/font/devpost/HI /opt/dwb/lib/font/devpost/Hi /opt/dwb/lib/font/devpost/HK /opt/dwb/lib/font/devpost/HL /opt/dwb/lib/font/devpost/HM /opt/dwb/lib/font/devpost/Hr /opt/dwb/lib/font/devpost/HX /opt/dwb/lib/font/devpost/Hx /opt/dwb/lib/font/devpost/HY /opt/dwb/lib/font/devpost/I /opt/dwb/lib/font/devpost/KB /opt/dwb/lib/font/devpost/KI /opt/dwb/lib/font/devpost/KR /opt/dwb/lib/font/devpost/KX /opt/dwb/lib/font/devpost/LINKFILE /opt/dwb/lib/font/devpost/MU /opt/dwb/lib/font/devpost/NB /opt/dwb/lib/font/devpost/NI /opt/dwb/lib/font/devpost/NR /opt/dwb/lib/font/devpost/NX /opt/dwb/lib/font/devpost/OA /opt/dwb/lib/font/devpost/OB /opt/dwb/lib/font/devpost/OI /opt/dwb/lib/font/devpost/OX /opt/dwb/lib/font/devpost/PA /opt/dwb/lib/font/devpost/PB /opt/dwb/lib/font/devpost/PI /opt/dwb/lib/font/devpost/PX /opt/dwb/lib/font/devpost/R /opt/dwb/lib/font/devpost/S /opt/dwb/lib/font/devpost/S1 /opt/dwb/lib/font/devpost/shell.lib /opt/dwb/lib/font/devpost/shell.lib.bak /opt/dwb/lib/font/devpost/ZD /opt/dwb/lib/font/devpost/ZI /opt/dwb/lib/font/postscript /opt/dwb/lib/macros /opt/dwb/lib/macros/an /opt/dwb/lib/macros/color /opt/dwb/lib/macros/csmacros /opt/dwb/lib/macros/mmn /opt/dwb/lib/macros/mmt /opt/dwb/lib/macros/pictures /opt/dwb/lib/macros/ptx /opt/dwb/lib/macros/safe /opt/dwb/lib/macros/strings.mm /opt/dwb/lib/macros/v /opt/dwb/lib/macros/view /opt/dwb/lib/manprog /opt/dwb/lib/nterm /opt/dwb/lib/nterm/tab.2631 /opt/dwb/lib/nterm/tab.2631-c /opt/dwb/lib/nterm/tab.2631-e /opt/dwb/lib/nterm/tab.300 /opt/dwb/lib/nterm/tab.300-12 /opt/dwb/lib/nterm/tab.300S /opt/dwb/lib/nterm/tab.300s /opt/dwb/lib/nterm/tab.300S-12 /opt/dwb/lib/nterm/tab.300s-12 /opt/dwb/lib/nterm/tab.37 /opt/dwb/lib/nterm/tab.382 /opt/dwb/lib/nterm/tab.4000A /opt/dwb/lib/nterm/tab.4000a /opt/dwb/lib/nterm/tab.450 /opt/dwb/lib/nterm/tab.450-12 /opt/dwb/lib/nterm/tab.832 /opt/dwb/lib/nterm/tab.8510 /opt/dwb/lib/nterm/tab.lp /opt/dwb/lib/nterm/tab.lpr /opt/dwb/lib/nterm/tab.man /opt/dwb/lib/nterm/tab.tn300 /opt/dwb/lib/nterm/tab.X /opt/dwb/lib/nterm/tab.X97 /opt/dwb/lib/nterm/tab.X97ni /opt/dwb/lib/nterm/tab.X97test /opt/dwb/lib/postscript /opt/dwb/lib/postscript/aps.ps /opt/dwb/lib/postscript/banner.ps /opt/dwb/lib/postscript/baseline.ps /opt/dwb/lib/postscript/color.ps /opt/dwb/lib/postscript/cropmarks.ps /opt/dwb/lib/postscript/dpost.ps /opt/dwb/lib/postscript/draw.ps /opt/dwb/lib/postscript/fatcourier.ps /opt/dwb/lib/postscript/forms.ps /opt/dwb/lib/postscript/grabit.ps /opt/dwb/lib/postscript/hardcopy.ps /opt/dwb/lib/postscript/Nroundpage.ps /opt/dwb/lib/postscript/postbgi.ps /opt/dwb/lib/postscript/postdaisy.ps /opt/dwb/lib/postscript/postdmd.ps /opt/dwb/lib/postscript/postgif.ps /opt/dwb/lib/postscript/postmd.ps /opt/dwb/lib/postscript/postnprint.ps /opt/dwb/lib/postscript/postplot.ps /opt/dwb/lib/postscript/postprint.ps /opt/dwb/lib/postscript/posttek.ps /opt/dwb/lib/postscript/printfont.ps /opt/dwb/lib/postscript/ps.requests /opt/dwb/lib/postscript/ps_include.ps /opt/dwb/lib/postscript/roundpage.ps /opt/dwb/lib/postscript/setbaud.ps /opt/dwb/lib/postscript/shade.ps /opt/dwb/lib/postscript/trofftable.ps /opt/dwb/lib/postscript/unbind.ps /opt/dwb/lib/raster /opt/dwb/lib/raster/rastpcl /opt/dwb/lib/raster/rastpcl/B.10 /opt/dwb/lib/raster/rastpcl/B.11 /opt/dwb/lib/raster/rastpcl/B.12 /opt/dwb/lib/raster/rastpcl/B.14 /opt/dwb/lib/raster/rastpcl/B.16 /opt/dwb/lib/raster/rastpcl/B.18 /opt/dwb/lib/raster/rastpcl/B.20 /opt/dwb/lib/raster/rastpcl/B.22 /opt/dwb/lib/raster/rastpcl/B.24 /opt/dwb/lib/raster/rastpcl/B.28 /opt/dwb/lib/raster/rastpcl/B.36 /opt/dwb/lib/raster/rastpcl/B.6 /opt/dwb/lib/raster/rastpcl/B.7 /opt/dwb/lib/raster/rastpcl/B.8 /opt/dwb/lib/raster/rastpcl/B.9 /opt/dwb/lib/raster/rastpcl/BI.10 /opt/dwb/lib/raster/rastpcl/BI.11 /opt/dwb/lib/raster/rastpcl/BI.12 /opt/dwb/lib/raster/rastpcl/BI.14 /opt/dwb/lib/raster/rastpcl/BI.16 /opt/dwb/lib/raster/rastpcl/BI.18 /opt/dwb/lib/raster/rastpcl/BI.20 /opt/dwb/lib/raster/rastpcl/BI.22 /opt/dwb/lib/raster/rastpcl/BI.24 /opt/dwb/lib/raster/rastpcl/BI.28 /opt/dwb/lib/raster/rastpcl/BI.36 /opt/dwb/lib/raster/rastpcl/BI.6 /opt/dwb/lib/raster/rastpcl/BI.7 /opt/dwb/lib/raster/rastpcl/BI.8 /opt/dwb/lib/raster/rastpcl/BI.9 /opt/dwb/lib/raster/rastpcl/CW.10 /opt/dwb/lib/raster/rastpcl/CW.11 /opt/dwb/lib/raster/rastpcl/CW.12 /opt/dwb/lib/raster/rastpcl/CW.14 /opt/dwb/lib/raster/rastpcl/CW.16 /opt/dwb/lib/raster/rastpcl/CW.18 /opt/dwb/lib/raster/rastpcl/CW.20 /opt/dwb/lib/raster/rastpcl/CW.22 /opt/dwb/lib/raster/rastpcl/CW.24 /opt/dwb/lib/raster/rastpcl/CW.28 /opt/dwb/lib/raster/rastpcl/CW.36 /opt/dwb/lib/raster/rastpcl/CW.6 /opt/dwb/lib/raster/rastpcl/CW.7 /opt/dwb/lib/raster/rastpcl/CW.8 /opt/dwb/lib/raster/rastpcl/CW.9 /opt/dwb/lib/raster/rastpcl/GR.10 /opt/dwb/lib/raster/rastpcl/GR.11 /opt/dwb/lib/raster/rastpcl/GR.12 /opt/dwb/lib/raster/rastpcl/GR.14 /opt/dwb/lib/raster/rastpcl/GR.16 /opt/dwb/lib/raster/rastpcl/GR.18 /opt/dwb/lib/raster/rastpcl/GR.20 /opt/dwb/lib/raster/rastpcl/GR.22 /opt/dwb/lib/raster/rastpcl/GR.24 /opt/dwb/lib/raster/rastpcl/GR.28 /opt/dwb/lib/raster/rastpcl/GR.36 /opt/dwb/lib/raster/rastpcl/GR.6 /opt/dwb/lib/raster/rastpcl/GR.7 /opt/dwb/lib/raster/rastpcl/GR.8 /opt/dwb/lib/raster/rastpcl/GR.9 /opt/dwb/lib/raster/rastpcl/H.10 /opt/dwb/lib/raster/rastpcl/H.11 /opt/dwb/lib/raster/rastpcl/H.12 /opt/dwb/lib/raster/rastpcl/H.14 /opt/dwb/lib/raster/rastpcl/H.16 /opt/dwb/lib/raster/rastpcl/H.18 /opt/dwb/lib/raster/rastpcl/H.20 /opt/dwb/lib/raster/rastpcl/H.22 /opt/dwb/lib/raster/rastpcl/H.24 /opt/dwb/lib/raster/rastpcl/H.28 /opt/dwb/lib/raster/rastpcl/H.36 /opt/dwb/lib/raster/rastpcl/H.6 /opt/dwb/lib/raster/rastpcl/H.7 /opt/dwb/lib/raster/rastpcl/H.8 /opt/dwb/lib/raster/rastpcl/H.9 /opt/dwb/lib/raster/rastpcl/HI.10 /opt/dwb/lib/raster/rastpcl/HI.11 /opt/dwb/lib/raster/rastpcl/HI.12 /opt/dwb/lib/raster/rastpcl/HI.14 /opt/dwb/lib/raster/rastpcl/HI.16 /opt/dwb/lib/raster/rastpcl/HI.18 /opt/dwb/lib/raster/rastpcl/HI.20 /opt/dwb/lib/raster/rastpcl/HI.22 /opt/dwb/lib/raster/rastpcl/HI.24 /opt/dwb/lib/raster/rastpcl/HI.28 /opt/dwb/lib/raster/rastpcl/HI.36 /opt/dwb/lib/raster/rastpcl/HI.6 /opt/dwb/lib/raster/rastpcl/HI.7 /opt/dwb/lib/raster/rastpcl/HI.8 /opt/dwb/lib/raster/rastpcl/HI.9 /opt/dwb/lib/raster/rastpcl/I.10 /opt/dwb/lib/raster/rastpcl/I.11 /opt/dwb/lib/raster/rastpcl/I.12 /opt/dwb/lib/raster/rastpcl/I.14 /opt/dwb/lib/raster/rastpcl/I.16 /opt/dwb/lib/raster/rastpcl/I.18 /opt/dwb/lib/raster/rastpcl/I.20 /opt/dwb/lib/raster/rastpcl/I.22 /opt/dwb/lib/raster/rastpcl/I.24 /opt/dwb/lib/raster/rastpcl/I.28 /opt/dwb/lib/raster/rastpcl/I.36 /opt/dwb/lib/raster/rastpcl/I.6 /opt/dwb/lib/raster/rastpcl/I.7 /opt/dwb/lib/raster/rastpcl/I.8 /opt/dwb/lib/raster/rastpcl/I.9 /opt/dwb/lib/raster/rastpcl/LO.36 /opt/dwb/lib/raster/rastpcl/PA.10 /opt/dwb/lib/raster/rastpcl/PA.11 /opt/dwb/lib/raster/rastpcl/PA.12 /opt/dwb/lib/raster/rastpcl/PA.14 /opt/dwb/lib/raster/rastpcl/PA.16 /opt/dwb/lib/raster/rastpcl/PA.18 /opt/dwb/lib/raster/rastpcl/PA.20 /opt/dwb/lib/raster/rastpcl/PA.22 /opt/dwb/lib/raster/rastpcl/PA.24 /opt/dwb/lib/raster/rastpcl/PA.28 /opt/dwb/lib/raster/rastpcl/PA.36 /opt/dwb/lib/raster/rastpcl/PA.6 /opt/dwb/lib/raster/rastpcl/PA.7 /opt/dwb/lib/raster/rastpcl/PA.8 /opt/dwb/lib/raster/rastpcl/PA.9 /opt/dwb/lib/raster/rastpcl/PI.10 /opt/dwb/lib/raster/rastpcl/PI.11 /opt/dwb/lib/raster/rastpcl/PI.12 /opt/dwb/lib/raster/rastpcl/PI.14 /opt/dwb/lib/raster/rastpcl/PI.16 /opt/dwb/lib/raster/rastpcl/PI.18 /opt/dwb/lib/raster/rastpcl/PI.20 /opt/dwb/lib/raster/rastpcl/PI.22 /opt/dwb/lib/raster/rastpcl/PI.24 /opt/dwb/lib/raster/rastpcl/PI.28 /opt/dwb/lib/raster/rastpcl/PI.36 /opt/dwb/lib/raster/rastpcl/PI.6 /opt/dwb/lib/raster/rastpcl/PI.7 /opt/dwb/lib/raster/rastpcl/PI.8 /opt/dwb/lib/raster/rastpcl/PI.9 /opt/dwb/lib/raster/rastpcl/R.10 /opt/dwb/lib/raster/rastpcl/R.11 /opt/dwb/lib/raster/rastpcl/R.12 /opt/dwb/lib/raster/rastpcl/R.14 /opt/dwb/lib/raster/rastpcl/R.16 /opt/dwb/lib/raster/rastpcl/R.18 /opt/dwb/lib/raster/rastpcl/R.20 /opt/dwb/lib/raster/rastpcl/R.22 /opt/dwb/lib/raster/rastpcl/R.24 /opt/dwb/lib/raster/rastpcl/R.28 /opt/dwb/lib/raster/rastpcl/R.36 /opt/dwb/lib/raster/rastpcl/R.6 /opt/dwb/lib/raster/rastpcl/R.7 /opt/dwb/lib/raster/rastpcl/R.8 /opt/dwb/lib/raster/rastpcl/R.9 /opt/dwb/lib/raster/rastpcl/RASTERDATA /opt/dwb/lib/raster/rastpcl/RASTERLIST /opt/dwb/lib/raster/rastpcl/S.10 /opt/dwb/lib/raster/rastpcl/S.11 /opt/dwb/lib/raster/rastpcl/S.12 /opt/dwb/lib/raster/rastpcl/S.14 /opt/dwb/lib/raster/rastpcl/S.16 /opt/dwb/lib/raster/rastpcl/S.18 /opt/dwb/lib/raster/rastpcl/S.20 /opt/dwb/lib/raster/rastpcl/S.22 /opt/dwb/lib/raster/rastpcl/S.24 /opt/dwb/lib/raster/rastpcl/S.28 /opt/dwb/lib/raster/rastpcl/S.36 /opt/dwb/lib/raster/rastpcl/S.6 /opt/dwb/lib/raster/rastpcl/S.7 /opt/dwb/lib/raster/rastpcl/S.8 /opt/dwb/lib/raster/rastpcl/S.9 /opt/dwb/lib/raster/rastpcl/S1.10 /opt/dwb/lib/raster/rastpcl/S1.11 /opt/dwb/lib/raster/rastpcl/S1.12 /opt/dwb/lib/raster/rastpcl/S1.14 /opt/dwb/lib/raster/rastpcl/S1.16 /opt/dwb/lib/raster/rastpcl/S1.18 /opt/dwb/lib/raster/rastpcl/S1.20 /opt/dwb/lib/raster/rastpcl/S1.22 /opt/dwb/lib/raster/rastpcl/S1.24 /opt/dwb/lib/raster/rastpcl/S1.28 /opt/dwb/lib/raster/rastpcl/S1.36 /opt/dwb/lib/raster/rastpcl/S1.6 /opt/dwb/lib/raster/rastpcl/S1.7 /opt/dwb/lib/raster/rastpcl/S1.8 /opt/dwb/lib/raster/rastpcl/S1.9 /opt/dwb/lib/raster/rastpcl/S2.10 /opt/dwb/lib/raster/rastpcl/S2.11 /opt/dwb/lib/raster/rastpcl/S2.12 /opt/dwb/lib/raster/rastpcl/S2.14 /opt/dwb/lib/raster/rastpcl/S2.16 /opt/dwb/lib/raster/rastpcl/S2.18 /opt/dwb/lib/raster/rastpcl/S2.20 /opt/dwb/lib/raster/rastpcl/S2.22 /opt/dwb/lib/raster/rastpcl/S2.24 /opt/dwb/lib/raster/rastpcl/S2.28 /opt/dwb/lib/raster/rastpcl/S2.36 /opt/dwb/lib/raster/rastpcl/S2.6 /opt/dwb/lib/raster/rastpcl/S2.7 /opt/dwb/lib/raster/rastpcl/S2.8 /opt/dwb/lib/raster/rastpcl/S2.9 /opt/dwb/lib/raster/rastpcl/S3.10 /opt/dwb/lib/raster/rastpcl/S3.11 /opt/dwb/lib/raster/rastpcl/S3.12 /opt/dwb/lib/raster/rastpcl/S3.14 /opt/dwb/lib/raster/rastpcl/S3.16 /opt/dwb/lib/raster/rastpcl/S3.18 /opt/dwb/lib/raster/rastpcl/S3.20 /opt/dwb/lib/raster/rastpcl/S3.22 /opt/dwb/lib/raster/rastpcl/S3.24 /opt/dwb/lib/raster/rastpcl/S3.28 /opt/dwb/lib/raster/rastpcl/S3.36 /opt/dwb/lib/raster/rastpcl/S3.6 /opt/dwb/lib/raster/rastpcl/S3.7 /opt/dwb/lib/raster/rastpcl/S3.8 /opt/dwb/lib/raster/rastpcl/S3.9 /opt/dwb/lib/term /opt/dwb/lib/tmac /opt/dwb/lib/tmac/hyphen.tex /opt/dwb/lib/tmac/tmac.an /opt/dwb/lib/tmac/tmac.color /opt/dwb/lib/tmac/tmac.cs /opt/dwb/lib/tmac/tmac.m /opt/dwb/lib/tmac/tmac.pictures /opt/dwb/lib/tmac/tmac.ps /opt/dwb/lib/tmac/tmac.s /opt/dwb/lib/tmac/tmac.safe /opt/dwb/lib/tmac/tmac.scover /opt/dwb/lib/tmac/tmac.sdisp /opt/dwb/lib/tmac/tmac.skeep /opt/dwb/lib/tmac/tmac.srefs /opt/dwb/lib/tmac/tmac.v /opt/dwb/lib/tmac/tmac.view /opt/dwb/man/ /opt/dwb/man/man1 /opt/dwb/man/man1/atoL1.1 /opt/dwb/man/man1/atoL1sim.1 /opt/dwb/man/man1/buildtables.1 /opt/dwb/man/man1/checkdoc.1 /opt/dwb/man/man1/col.1 /opt/dwb/man/man1/cropmarks.1 /opt/dwb/man/man1/diffmk.1 /opt/dwb/man/man1/download.1 /opt/dwb/man/man1/dpost.1 /opt/dwb/man/man1/dsplit.1 /opt/dwb/man/man1/dwbv.1 /opt/dwb/man/man1/eqn.1 /opt/dwb/man/man1/gc2pic.1 /opt/dwb/man/man1/grabit.1 /opt/dwb/man/man1/grap.1 /opt/dwb/man/man1/hardcopy.1 /opt/dwb/man/man1/hyphen.1 /opt/dwb/man/man1/L1toa.1 /opt/dwb/man/man1/laserbar.1 /opt/dwb/man/man1/mm.1 /opt/dwb/man/man1/mmt.1 /opt/dwb/man/man1/mvt.1 /opt/dwb/man/man1/neqn.1 /opt/dwb/man/man1/nroff.1 /opt/dwb/man/man1/otbl.1 /opt/dwb/man/man1/pic.1 /opt/dwb/man/man1/picasso.1 /opt/dwb/man/man1/picpack.1 /opt/dwb/man/man1/postbgi.1 /opt/dwb/man/man1/postdaisy.1 /opt/dwb/man/man1/postdmd.1 /opt/dwb/man/man1/postgif.1 /opt/dwb/man/man1/postio.1 /opt/dwb/man/man1/postmd.1 /opt/dwb/man/man1/postnprint.1 /opt/dwb/man/man1/postplot.1 /opt/dwb/man/man1/postprint.1 /opt/dwb/man/man1/postreverse.1 /opt/dwb/man/man1/posttek.1 /opt/dwb/man/man1/printfont.1 /opt/dwb/man/man1/psencoding.1 /opt/dwb/man/man1/tbl.1 /opt/dwb/man/man1/tc.1 /opt/dwb/man/man1/troff.1 /opt/dwb/man/man1/trofftable.1 /opt/dwb/man/man5 /opt/dwb/man/man5/eqnchar.5 /opt/dwb/man/man5/font.5 /opt/dwb/man/man5/man.5 /opt/dwb/man/man5/mcolor.5 /opt/dwb/man/man5/mcs.5 /opt/dwb/man/man5/mm.5 /opt/dwb/man/man5/mpictures.5 /opt/dwb/man/man5/mpm.5 /opt/dwb/man/man5/mps.5 /opt/dwb/man/man5/ms.5 /opt/dwb/man/man5/msafe.5 /opt/dwb/man/man5/mv.5 /opt/dwb/man/man5/mview.5 /opt/dwb/man/man5/nterm.5 /opt/dwb/man/man5/troff.5 /opt/dwb/man/man5/xpand.5 /opt/dwb/pub/ /opt/dwb/pub/cateqnchar /opt/dwb/pub/DWB3.3.ps /opt/dwb/pub/eqnchar /opt/dwb/pub/i300eqnchar /opt/dwb/pub/latin1.add.ps /opt/dwb/pub/mm.notes.ps /opt/dwb/pub/post.add.ps /opt/dwb/pub/posteqnchar /opt/dwb/pub/tbl.notes.ps /opt/dwb/pub/terminals --------------040209070908030303010506 Content-Type: text/plain; name="faucet.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="faucet.txt" CgoKICAgICAgIEYIRghGCEZBCEEIQQhBVQhVCFUIVUMIQwhDCENFCEUIRQhFVAhUCFQIVCgI KAgoCCgxCDEIMQgxKQgpCCkIKSAgICAgICBVCFUIVQhVTghOCE4ITkkISQhJCElYCFgIWAhY IFMIUwhTCFN5CHkIeQh5cwhzCHMIc3QIdAh0CHRlCGUIZQhlbQhtCG0IbSBWCFYIVghWICgI KAgoCChPCE8ITwhPYwhjCGMIY3QIdAh0CHRvCG8IbwhvYghiCGIIYmUIZQhlCGVyCHIIcghy IDIIMggyCDI4CDgIOAg4LAgsCCwILCAxCDEIMQgxOQg5CDkIOTkIOQg5CDk4CDgIOAg4KQgp CCkIKQkgICAgICAgRghGCEYIRkEIQQhBCEFVCFUIVQhVQwhDCEMIQ0UIRQhFCEVUCFQIVAhU KAgoCCgIKDEIMQgxCDEpCCkIKQgpCgoKCiAgICAgICBOCE4ITghOQQhBCEEIQU0ITQhNCE1F CEUIRQhFCgkgICAgZmF1Y2V0IC0gYSBmaXh0dXJlIGZvciBhIEJTRCBuZXR3b3JrIHBpcGUK CgkgICAgbmV0cGlwZXMgNC4yCgoKICAgICAgIFMIUwhTCFNZCFkIWQhZTghOCE4ITk8ITwhP CE9QCFAIUAhQUwhTCFMIU0kISQhJCElTCFMIUwhTCgkgICAgZghmCGYIZmEIYQhhCGF1CHUI dQh1YwhjCGMIY2UIZQhlCGV0CHQIdAh0IF8IcF8Ib18Icl8IdAkoLQgtCC0ILS0ILQgtCC1p CGkIaQhpbghuCG4IbnwtCC0ILQgtLQgtCC0ILW8IbwhvCG91CHUIdQh1dAh0CHQIdHwtCC0I LQgtLQgtCC0ILWUIZQhlCGVyCHIIcghycghyCHIIcnwtCC0ILQgtLQgtCC0ILWYIZghmCGZk CGQIZAhkIF8IbikrIFstCC0ILQgtLQgtCC0ILW8IbwhvCG9uCG4IbghuYwhjCGMIY2UIZQhl CGVdIFstCC0ILQgtLQgtCC0ILXYIdgh2CHZlCGUIZQhlcghyCHIIcmIIYghiCGJvCG8Ibwhv cwhzCHMIc2UIZQhlCGVdCgkgICAgWy0ILQgtCC0tCC0ILQgtcQhxCHEIcXUIdQh1CHVpCGkI aQhpZQhlCGUIZXQIdAh0CHRdIFstCC0ILQgtLQgtCC0ILXUIdQh1CHVuCG4IbghuaQhpCGkI aXgIeAh4CHhdIFstCC0ILQgtLQgtCC0ILWYIZghmCGZvCG8IbwhvcghyCHIIcmUIZQhlCGVp CGkIaQhpZwhnCGcIZ24IbghuCG5oCGgIaAhobwhvCG8Ib3MIcwhzCHN0CHQIdAh0IF8IYV8I ZF8IZF8Icl0gWy0ILQgtCC0tCC0ILQgtZghmCGYIZm8IbwhvCG9yCHIIcghyZQhlCGUIZWkI aQhpCGlnCGcIZwhnbghuCG4IbnAIcAhwCHBvCG8IbwhvcghyCHIIcnQIdAh0CHQgXwhwXwhv XwhyXwh0XQoJICAgIFstCC0ILQgtLQgtCC0ILWwIbAhsCGxvCG8IbwhvYwhjCGMIY2EIYQhh CGFsCGwIbAhsaAhoCGgIaG8IbwhvCG9zCHMIcwhzdAh0CHQIdCBfCGFfCGRfCGRfCHJdIFst CC0ILQgtLQgtCC0ILXMIcwhzCHNlCGUIZQhlcghyCHIIcmkIaQhpCGlhCGEIYQhhbAhsCGwI bF0gWy0ILQgtCC0tCC0ILQgtZAhkCGQIZGEIYQhhCGFlCGUIZQhlbQhtCG0IbW8IbwhvCG9u CG4IbghuXSBbLQgtCC0ILS0ILQgtCC1zCHMIcwhzaAhoCGgIaHUIdQh1CHV0CHQIdAh0ZAhk CGQIZG8IbwhvCG93CHcIdwh3bghuCG4IbiAocnx3KSBdCgkgICAgWy0ILQgtCC0tCC0ILQgt cAhwCHAIcGkIaQhpCGlkCGQIZAhkZghmCGYIZmkIaQhpCGlsCGwIbAhsZQhlCGUIZSBfCGZf CGlfCGxfCGVfCG5fCGFfCG1fCGVdIFstCC0ILQgtLQgtCC0ILW4IbghuCG5vCG8Ibwhvcghy CHIIcmUIZQhlCGV1CHUIdQh1cwhzCHMIc2UIZQhlCGVhCGEIYQhhZAhkCGQIZGQIZAhkCGRy CHIIcghyXSBbLQgtCC0ILS0ILQgtCC1iCGIIYghiYQhhCGEIYWMIYwhjCGNrCGsIawhrbAhs CGwIbG8IbwhvCG9nCGcIZwhnIF8Ibl0KCSAgICBbLQgtCC0ILVtpCGkIaQhpXVtvCG8Ibwhv XVtlCGUIZQhlXVsjCCMIIwgjXwgzWyxfCDRbLF8INS4uLl1dXVt2CHYIdgh2XVsxCDEIMQgx XVtxCHEIcQhxXVt1CHUIdQh1XVtkCGQIZAhkXVtzCHMIcwhzXV0gWy0ILQgtCC1wCHAIcAhw CgkgICAgXwhmXwhvXwhyXwhlXwhpXwhnXwhuLV8IcF8Ib18Icl8IdF0gWy0ILQgtCC1oCGgI aAhoIF8IZl8Ib18Icl8IZV8IaV8IZ18Ibi1fCGhfCG9fCHNfCHRdIFstCC0ILQgtSAhICEgI SAlfCGxfCG9fCGNfCGFfCGwtXwhoXwhvXwhzXwh0XSBfCGNfCG9fCG1fCG1fCGFfCG5fCGQg XwhhXwhyXwhnXwhzCgoKICAgICAgIEQIRAhECERFCEUIRQhFUwhTCFMIU0MIQwhDCENSCFII UghSSQhJCEkISVAIUAhQCFBUCFQIVAhUSQhJCEkISU8ITwhPCE9OCE4ITghOCgkgICAgZghm CGYIZmEIYQhhCGF1CHUIdQh1YwhjCGMIY2UIZQhlCGV0CHQIdAh0IGF0dGVtcHRzIHRvIHBy b3ZpZGUgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgcGlwZXMgb3ZlcgoJICAgIHRoZQluZXR3b3Jr LiAgSXQgYmVoYXZlcyBhcwl0aGUgc2VydmVyIGVuZCBvZiBhCgkgICAgc2VydmVyLWNsaWVu dCBjb25uZWN0aW9uLiAgV2hlbiB1c2VkIHdpdGggaAhoCGgIaG8IbwhvCG9zCHMIcwhzZQhl CGUIZSgIKAgoCCgxCDEIMQgxKQgpCCkIKSBpdCBjYW4KCSAgICBmdW5jdGlvbiBhcwlhIHJl cGxhY2VtZW50IGZvcgoKCSAgICB0YXIJLWNmIC0gLgl8IHJzaCBvdGhlciAiY2QJZGVzdGRp cjsgdGFyIC14ZiAtIgoKCSAgICBmCGYIZghmYQhhCGEIYXUIdQh1CHVjCGMIYwhjZQhlCGUI ZXQIdAh0CHQgYW5kIGgIaAhoCGhvCG8IbwhvcwhzCHMIc2UIZQhlCGUgYXJlCWVzcGVjaWFs bHkgdXNlZnVsIHdoZW4geW91IGRvbid0IGhhdmUKCSAgICBlYXN5IG5vbi1pbnRlcmFjdGl2 ZSBhY2Nlc3MJdG8gdGhlIGRlc3RpbmF0aW9uIGFjY291bnQgKHN1Y2gKCSAgICBhcyBhIHJv b3QgYWNjb3VudCB3aGVyZSAucmhvc3RzIGFyZQlhIGJhZCBpZGVhKS4KCgkgICAgZghmCGYI ZmEIYQhhCGF1CHUIdQh1YwhjCGMIY2UIZQhlCGV0CHQIdAh0IGNyZWF0ZXMgYSBCU0Qgc29j a2V0LCBiaW5kcyBpdCB0byB0aGUgXwhwXwhvXwhyXwh0IHNwZWNpZmllZAoJICAgIG9uIHRo ZSBjb21tYW5kIGxpbmUsIGFuZCBsaXN0ZW5zIGZvciBjb25uZWN0aW9ucy4KCgkgICAgRXZl cnkgdGltZSBmCGYIZghmYQhhCGEIYXUIdQh1CHVjCGMIYwhjZQhlCGUIZXQIdAh0CHQgZ2V0 cyBhIGNvbm5lY3Rpb24JaXQgZXhlYygyKXMgXwhjXwhvXwhtXwhtXwhhXwhuXwhkIGFuZAoJ ICAgIGl0cwlfCGFfCHJfCGdfCHMgd2l0aCBzdGRpbiwgc3Rkb3V0LCBzdGRlcnIsIGFuZC9v cglhcmJpdHJhcnkgZmlsZQoJICAgIGRlc2NyaXB0b3JzCXJlZGlyZWN0ZWQgYWNjb3JkaW5n IHRvCXRoZSAtCC0ILQgtLQgtCC0ILWkIaQhpCGluCG4IbghuIC0ILQgtCC0tCC0ILQgtbwhv CG8Ib3UIdQh1CHV0CHQIdAh0IC0ILQgtCC0tCC0ILQgtZQhlCGUIZXIIcghyCHJyCHIIcghy CgkgICAgLQgtCC0ILS0ILQgtCC1mCGYIZghmZAhkCGQIZCBfCG4gZmxhZ3MuICBmCGYIZghm YQhhCGEIYXUIdQh1CHVjCGMIYwhjZQhlCGUIZXQIdAh0CHQgYWxzbyBhdXRvbWFnaWNhbGx5 IHNodXRzIGRvd24JdGhlCgkgICAgdW51c2VkIGhhbGYJb2YgdGhlIGNvbm5lY3Rpb24gaWYg b25seSAtCC0ILQgtLQgtCC0ILWkIaQhpCGluCG4IbghuIGlzIHNwZWNpZmllZCBvcgoJICAg IGlmIG9ubHkgLQgtCC0ILS0ILQgtCC1vCG8IbwhvdQh1CHUIdXQIdAh0CHQgYW5kL29yIC0I LQgtCC0tCC0ILQgtZQhlCGUIZXIIcghyCHJyCHIIcghyIGFyZSBzcGVjaWZpZWQuICBTZWUg dGhlIC0ILQgtCC0tCC0ILQgtcwhzCHMIc2gIaAhoCGh1CHUIdQh1dAh0CHQIdC0ILQgtCC0K CSAgICBkCGQIZAhkbwhvCG8Ib3cIdwh3CHduCG4IbghuIG9wdGlvbglmb3IgbW9yZSBpbmZv cm1hdGlvbi4KCgogICAgICAgTwhPCE8IT1AIUAhQCFBUCFQIVAhUSQhJCEkISU8ITwhPCE9O CE4ITghOUwhTCFMIUwoJICAgIElmIHRoZSAtCC0ILQgtLQgtCC0ILW8IbwhvCG9uCG4Ibghu YwhjCGMIY2UIZQhlCGUgZmxhZyBpcyBzcGVjaWZpZWQsIGYIZghmCGZhCGEIYQhhdQh1CHUI dWMIYwhjCGNlCGUIZQhldAh0CHQIdCB3aWxsIGV4ZWMoMikgdGhlCgkgICAgXwhjXwhvXwht XwhtXwhhXwhuXwhkIGluc3RlYWQgb2YgZm9yaygyKWluZyBhbmQgZXhlYygyKWluZy4gLQgt CC0ILS0ILQgtCC1vCG8IbwhvbghuCG4IbmMIYwhjCGNlCGUIZQhlIG1lYW5zCgkgICAgdGhh dCB0aGUgbmV0d29yayBwaXBlIGlzIG9ubHkgZ29vZCBmb3Igb25lIHNob3QuCgoJICAgIFRo ZQktCC0ILQgtLQgtCC0ILXYIdgh2CHZlCGUIZQhlcghyCHIIcmIIYghiCGJvCG8Ibwhvcwhz CHMIc2UIZQhlCGUgZmxhZyBzcGVjaWZpZXMgdGhhdCBmCGYIZghmYQhhCGEIYXUIdQh1CHVj CGMIYwhjZQhlCGUIZXQIdAh0CHQgc2hvdWxkIHByaW50IGluZm9yLQoJICAgIG1hdGlvbiBh Ym91dCBjb25uZWN0aW5nIGhvc3RzLiAgVGhpcyBpbmZvcm1hdGlvbiBpbmNsdWRlcwoJICAg IHRoZQludW1lcmljCWhvc3QgYWRkcmVzcywgaG9zdCBuYW1lcywgYW5kIGZvcmVpZ24gcG9y dCBudW0tCgkgICAgYmVycy4gIFRoZSAtCC0ILQgtLQgtCC0ILXEIcQhxCHF1CHUIdQh1aQhp CGkIaWUIZQhlCGV0CHQIdAh0IGZsYWcgc3BlY2lmaWVzIHRoYXQgZghmCGYIZmEIYQhhCGF1 CHUIdQh1YwhjCGMIY2UIZQhlCGV0CHQIdAh0IHNob3VsZCBOT1QKCSAgICBwcmludCBzdWNo IGluZm8uICAtCC0ILQgtLQgtCC0ILXEIcQhxCHF1CHUIdQh1aQhpCGkIaWUIZQhlCGV0CHQI dAh0IGlzIHRoZSBkZWZhdWx0LgoKCSAgICBUaGUJLQgtCC0ILS0ILQgtCC11CHUIdQh1bghu CG4IbmkIaQhpCGl4CHgIeAh4IGZsYWcgc3BlY2lmaWVzIHRoYXQgdGhlIF8IcF8Ib18Icl8I dCBpcyBub3QgYW4gaW50ZXJuZXQKCSAgICBwb3J0IG51bWJlcglvciBzZXJ2aWNlIG5hbWUs IGJ1dCBpbnN0ZWFkIGl0CWlzIGEgZmlsZSBuYW1lCgoKCiAgICAgICBQYWdlIDEJCQkJCSAg ICAgIChsYXN0IG1vZC4gMi80LzkzKQoKCgoKCgogICAgICAgRghGCEYIRkEIQQhBCEFVCFUI VQhVQwhDCEMIQ0UIRQhFCEVUCFQIVAhUKAgoCCgIKDEIMQgxCDEpCCkIKQgpICAgICAgIFUI VQhVCFVOCE4ITghOSQhJCEkISVgIWAhYCFggUwhTCFMIU3kIeQh5CHlzCHMIcwhzdAh0CHQI dGUIZQhlCGVtCG0IbQhtIFYIVghWCFYgKAgoCCgIKE8ITwhPCE9jCGMIYwhjdAh0CHQIdG8I bwhvCG9iCGIIYghiZQhlCGUIZXIIcghyCHIgMggyCDIIMjgIOAg4CDgsCCwILAgsIDEIMQgx CDE5CDkIOQg5OQg5CDkIOTgIOAg4CDgpCCkIKQgpCSAgICAgICBGCEYIRghGQQhBCEEIQVUI VQhVCFVDCEMIQwhDRQhFCEUIRVQIVAhUCFQoCCgIKAgoMQgxCDEIMSkIKQgpCCkKCgoKCSAg ICBmb3IJYSBVTklYIGRvbWFpbiBzb2NrZXQuCgoJICAgIFRoZQktCC0ILQgtLQgtCC0ILWYI ZghmCGZvCG8IbwhvcghyCHIIcmUIZQhlCGVpCGkIaQhpZwhnCGcIZ24IbghuCG5oCGgIaAho bwhvCG8Ib3MIcwhzCHN0CHQIdAh0IG9wdGlvbiBzcGVjaWZpZXMgdGhhdCBmYXVjZXQgc2hv dWxkIHJlamVjdAoJICAgIGFsbAljb25uZWN0aW9ucyB0aGF0IGRvIG5vdAljb21lIGZyb20g dGhlIF8IaF8Ib18Ic18IdCBtYWNoaW5lLgoJICAgIFNpbWlsYXJseSAtCC0ILQgtLQgtCC0I LWYIZghmCGZvCG8IbwhvcghyCHIIcmUIZQhlCGVpCGkIaQhpZwhnCGcIZ24IbghuCG5wCHAI cAhwbwhvCG8Ib3IIcghyCHJ0CHQIdAh0IHNwZWNpZmllcyB0aGF0IGZhdWNldCBzaG91bGQg cmVqZWN0CgkgICAgYWxsCWNvbm5lY3Rpb25zIHRoYXQgYXJlIG5vdCBib3VuZCBvbiB0aGVp cglsb2NhbCBtYWNoaW5lIHRvCgkgICAgdGhlCV8IcF8Ib18Icl8IdCBhcmd1bWVudC4JVGhl IGFib3ZlIHR3byBvcHRpb25zIGFsbG93IGEgY3J1ZGUgZm9ybQoJICAgIG9mIGF1dGhlbnRp Y2F0aW9uLglOb3RlIHRoYXQgb24gVU5JWCBzeXN0ZW1zIG9ubHkgcm9vdCBjYW4KCSAgICBi aW5kIGEgc29ja2V0IHRvIGEgcG9ydCBudW1iZXIgYmVsb3cgMTAyNC4KCgkgICAgUAhQCFAI UGwIbAhsCGxlCGUIZQhlYQhhCGEIYXMIcwhzCHNlCGUIZQhlIGRvIG5vdCBiZSBmb29sZWQg aW50byB0aGlua2luZyB0aGlzIG1ha2VzIGZhdWNldAoJICAgIHNlY3VyZS4gIFRoZXJlIGFy ZSB3YXlzIHRvIHNwb29mIElQCW51bWJlcnMJdGhhdCBoYXZlIGJlZW4KCSAgICBrbm93biBm b3IgeWVhcnMgKGJ1dCBvbmx5IHB1YmxpY2l6ZWQgcmVjZW50bHkpLiAgSSBkbyB0aGluawoJ ICAgIHRoYXQgdGhpcyBtZXRob2QgaXMJc2FmZSBmcm9tIEROUyBzcG9vZnMsIGJ1dCB5b3Ug cHJvYmFibHkKCSAgICBzaG91bGQgaGF2ZQkgbghuCG4Ibm8IbwhvCG9zCHMIcwhzcAhwCHAI cG8IbwhvCG9vCG8IbwhvZghmCGYIZiBvCG8IbwhvbghuCG4IbiBpbiAvZXRjL2hvc3QuY29u ZiBhbnl3YXkuCgoJICAgIC0ILQgtCC0tCC0ILQgtbAhsCGwIbG8IbwhvCG9jCGMIYwhjYQhh CGEIYWwIbAhsCGxoCGgIaAhobwhvCG8Ib3MIcwhzCHN0CHQIdAh0CXNwZWNpZmllcyB0aGF0 IHRoZSBsaXN0ZW5pbmcgc29ja2V0IHNob3VsZCBiZQoJICAgIGJvdW5kIHRvIGEgc3BlY2lm aWMJaW50ZXJuZXQgYWRkcmVzcyBvbiB0aGlzIGhvc3QuCVRoaXMgaXMKCSAgICBvbmx5IHVz ZWZ1bAlvbiBob3N0cyB3aXRoIHNldmVyYWwgaW50ZXJuZXQgbnVtYmVycy4KCgkgICAgLQgt CC0ILS0ILQgtCC1kCGQIZAhkYQhhCGEIYWUIZQhlCGVtCG0IbQhtbwhvCG8Ib24IbghuCG4g c3BlY2lmaWVzIHRoYXQgdGhlCWZhdWNldCBzaG91bGQgZGlzYXNzb2NpYXRlIGZyb20KCSAg ICB0aGUJY29udHJvbGxpbmcgdGVybWluYWwgb25jZSBpdCBoYXMgc3RhcnRlZCBsaXN0ZW5p bmcgb24KCSAgICB0aGUJc29ja2V0LgkgVGhpcyBpcyBkb25lIHVzaW5nIHRoZQlzZXRzaWQo KSBzeXN0ZW0JY2FsbC4KCSAgICBJZiB5b3UgZG9uJ3QgaGF2ZSBzZXRzaWQgb24JeW91ciBz eXN0ZW0sIGl0CXVzZXMgdGhlIHN0YW4tCgkgICAgZGFyZCBgYGNsb3NlIGFsbCBmaWxlIGRl c2NyaXB0b3JzLCBpb2N0bCBUSU9DTk9UVFksCWZvcmsoKQoJICAgIGFuZAlwYXJlbnQgZXhp dCcnIHNlcXVlbmNlLgoKCSAgICAtCC0ILQgtLQgtCC0ILXMIcwhzCHNoCGgIaAhodQh1CHUI dXQIdAh0CHRkCGQIZAhkbwhvCG8Ib3cIdwh3CHduCG4IbghuIGlzIHVzZWQgdG8gdHVybiB0 aGUgKG5vcm1hbGx5KSBiaS1kaXJlY3Rpb25hbAoJICAgIHNvY2tldCBpbnRvCWEgdW5pLWRp cmVjdGlvbmFsIG9uZSBJZiB0aGUgYHInIGlzIHByZXNlbnQsCgkgICAgdGhlbiBmCGYIZghm YQhhCGEIYXUIdQh1CHVjCGMIYwhjZQhlCGUIZXQIdAh0CHQJd2lsbCBjbG9zZSBoYWxmCXRo ZSBjb25uZWN0aW9uIHRvIG1ha2UgaXQgYQoJICAgIHJlYWQtb25seSBzb2NrZXQuICBJZiB3 ZSB0cnkgdG8gd3JpdGUsIGl0IHdpbGwgZmFpbC4gIElmIHRoZQoJICAgIHJlbW90ZSBjb25u ZWN0aW9uIHRyaWVzIHRvIHJlYWQsIGl0CXdpbGwgcGVyY2lldmUgdGhlIHNvY2tldAoJICAg IGFzIGNsb3NlZC4JSWYgaW5zdGVhZCB0aGUgYHcnIGlzIHByZXNlbnQsIHRoZW4gZghmCGYI ZmEIYQhhCGF1CHUIdQh1YwhjCGMIY2UIZQhlCGV0CHQIdAh0IHdpbGwKCSAgICBjbG9zZSB0 aGUgb3RoZXIgaGFsZiBvZiB0aGUJY29ubmVjdGlvbiB0byBtYWtlIGl0IGEKCSAgICB3cml0 ZS1vbmx5IHNvY2tldC4JSWYgd2UgdHJ5IHRvIHJlYWQsIHdlIHdpbGwgcGVyY2lldmUgdGhl CgkgICAgc29ja2V0IGFzIGNsb3NlZC4gIElmIHRoZSByZW1vdGUgY29ubmVjdGlvbgl0cmll cyB0byB3cml0ZSwKCSAgICBpdCB3aWxsIGZhaWwuICBUaGUgZGVmYXVsdCBiZWhhdmlvcglp cyB0byBsZWF2ZSBib3RoIGhhbHZlcwoJICAgIG9wZW4sIGhvd2V2ZXIgdGhlIHNodXRkb3du IG9mIGhhbGYgb2YgdGhlIGNvbm5lY3Rpb24gaXMKCSAgICBhdXRvbWFnaWNhbGx5IGRvbmUg YnkgY2VydGFpbiBjb21iaW5hdGlvbnMgb2YgdGhlIC0ILQgtCC0tCC0ILQgtaQhpCGkIaW4I bghuCG4sCgkgICAgLQgtCC0ILS0ILQgtCC1vCG8IbwhvdQh1CHUIdXQIdAh0CHQsIGFuZCAt CC0ILQgtLQgtCC0ILWUIZQhlCGVyCHIIcghycghyCHIIciBmbGFncy4gIFRvCXN1cHByZXNz IHRoZWlyIGF1dG9tYWdpYyBiZWhhdi0KCSAgICBpb3IJeW91IGNhbgl1c2UgKHJlc3BlY3Rp dmVseSkgLS1mZAkwLCAtLWZkCTEsIGFuZCAtLWZkIDIuCgoJICAgIC0ILQgtCC0tCC0ILQgt cwhzCHMIc2gIaAhoCGh1CHUIdQh1dAh0CHQIdGQIZAhkCGRvCG8Ibwhvdwh3CHcId24Ibghu CG4gbWF5IG5vdCBiZSB1c2VkIHdpdGggc29tZSBpbnRlcm5ldCBzZXJ2ZXJzIChzdWNoCgkg ICAgYXMgY2VydGFpbiBodHRwZHMpIGJlY2F1c2UgdGhleSBpbnRlcnByZXQgdGhlIGNsb3Np bmcgb2Ygb25lCgkgICAgaGFsZiBvZiB0aGUJY29ubmVjdGlvbiBhcyBhCWNsb3NlIG9uIHRo ZSBlbnRpcmUgY29ubmVjdGlvbi4KCSAgICBUaGlzIHdhcm5pbmcgYXBwbGllcyB0byAtCC0I LQgtLQgtCC0ILWkIaQhpCGluCG4IbghuLCAtCC0ILQgtLQgtCC0ILW8IbwhvCG91CHUIdQh1 dAh0CHQIdCwgYW5kIC0ILQgtCC0tCC0ILQgtZQhlCGUIZXIIcghyCHJyCHIIcghyLgoKCSAg ICAtCC0ILQgtLQgtCC0ILXMIcwhzCHNlCGUIZQhlcghyCHIIcmkIaQhpCGlhCGEIYQhhbAhs CGwIbCBjYXVzZXMgZmF1Y2V0IHRvIHdhaXQgZm9yIG9uZSBjaGlsZCB0byBmaW5pc2gKCSAg ICBiZWZvcmUgYWNjZXB0aW5nIGFueSBtb3JlIGNvbm5lY3Rpb25zLiAgU2VyaWFsaXphdGlv biBpcyBhCgkgICAgdmVyeSBjcnVkZSBmb3JtIG9mIGNyaXRpY2FsLXNlY3Rpb24JbWFuYWdl bWVudC4KCgkgICAgLQgtCC0ILS0ILQgtCC1wCHAIcAhwaQhpCGkIaWQIZAhkCGRmCGYIZghm aQhpCGkIaWwIbAhsCGxlCGUIZQhlIF8IZl8IaV8IbF8IZV8Ibl8IYV8IbV8IZSBjb21tYW5k cwlmCGYIZghmYQhhCGEIYXUIdQh1CHVjCGMIYwhjZQhlCGUIZXQIdAh0CHQgdG8gd3JpdGUJ aXRzIHByb2Nlc3MgaWQKCgoKICAgICAgIFBhZ2UgMgkJCQkJICAgICAgKGxhc3QgbW9kLiAy LzQvOTMpCgoKCgoKCiAgICAgICBGCEYIRghGQQhBCEEIQVUIVQhVCFVDCEMIQwhDRQhFCEUI RVQIVAhUCFQoCCgIKAgoMQgxCDEIMSkIKQgpCCkgICAgICAgVQhVCFUIVU4ITghOCE5JCEkI SQhJWAhYCFgIWCBTCFMIUwhTeQh5CHkIeXMIcwhzCHN0CHQIdAh0ZQhlCGUIZW0IbQhtCG0g VghWCFYIViAoCCgIKAgoTwhPCE8IT2MIYwhjCGN0CHQIdAh0bwhvCG8Ib2IIYghiCGJlCGUI ZQhlcghyCHIIciAyCDIIMggyOAg4CDgIOCwILAgsCCwgMQgxCDEIMTkIOQg5CDk5CDkIOQg5 OAg4CDgIOCkIKQgpCCkJICAgICAgIEYIRghGCEZBCEEIQQhBVQhVCFUIVUMIQwhDCENFCEUI RQhFVAhUCFQIVCgIKAgoCCgxCDEIMQgxKQgpCCkIKQoKCgoJICAgIGludG8gXwhmXwhpXwhs XwhlXwhuXwhhXwhtXwhlLiAgVGhpcyBpcyB1c2VmdWwgd2hlbglmYXVjZXQgaXMgcGFydCBv ZiBhCgkgICAgbGFyZ2VyIHN5c3RlbSBhbmQgYQljb250cm9sbGluZyBwcm9jZXNzIG1pZ2h0 IHdhbnQgdG8ga2lsbAoJICAgIHRoZQlmYXVjZXQuCSAtCC0ILQgtLQgtCC0ILXAIcAhwCHBp CGkIaQhpZAhkCGQIZGYIZghmCGZpCGkIaQhpbAhsCGwIbGUIZQhlCGUgZnVuY3Rpb25zIHBy b3Blcmx5IHdoZW4gdXNpbmcgdGhlCgkgICAgLQgtCC0ILS0ILQgtCC1kCGQIZAhkYQhhCGEI YWUIZQhlCGVtCG0IbQhtbwhvCG8Ib24IbghuCG4gIG9wdGlvbi4KCgkgICAgQnkgZGVmYXVs dCwJZghmCGYIZmEIYQhhCGF1CHUIdQh1YwhjCGMIY2UIZQhlCGV0CHQIdAh0IHBlcmZvcm1z CWEKCgkgICAgc2V0c29ja29wdChmZCwgU09MX1NPQ0tFVCwgU09fUkVVU0VBRERSLi4uKQoK CSAgICB3aGljaCBwcmV2ZW50cyB0aGUgYGBBZGRyZXNzIGluIHVzZScnIHByb2JsZW0gdGhh dAoJICAgIGBgcGxhZ3VlZCcnCW5ldHBpcGVzIHZlcnNpb25zIDQuMCBhbmQgZWFybGllci4g IC0ILQgtCC0tCC0ILQgtbghuCG4Ibm8IbwhvCG9yCHIIcghyZQhlCGUIZXUIdQh1CHVzCHMI cwhzZQhlCGUIZS0ILQgtCC0KCSAgICBhCGEIYQhhZAhkCGQIZGQIZAhkCGRyCHIIcghyIHRl bGxzIGZhdWNldCB0byBza2lwIHRoYXQgc3lzdGVtIGNhbGwsCWFuZCByZXZlcnQgdG8KCSAg ICBwcmUtNC4xIGJlaGF2aW9yLiAgV2l0aG91dCB0aGlzIGNhbGwsIHRoZSBzb2NrZXQgaXMJ bm90CgkgICAgYWx3YXlzIGF2YWlsYWJsZSBmb3IgaW1tZWRpYXRlIHJldXNlIGFmdGVyIHRo ZSBmYXVjZXQgZXhpdHMuCgoJICAgIC0ILQgtCC0tCC0ILQgtYghiCGIIYmEIYQhhCGFjCGMI YwhjawhrCGsIa2wIbAhsCGxvCG8IbwhvZwhnCGcIZyBfCG4JYWxsb3dzIHlvdSB0byBzcGVj aWZ5IHRoZSBzZWNvbmQgcGFyYW1ldGVyIHRvCgkgICAgdGhlCWxpc3RlbigyKSBzeXN0ZW0g Y2FsbC4JVGhlIGRlZmF1bHQgaXMgNS4KCgogICAgICAgUwhTCFMIU0gISAhICEhPCE8ITwhP UghSCFIIUlQIVAhUCFQgRghGCEYIRkwITAhMCExBCEEIQQhBRwhHCEcIR1MIUwhTCFMKCSAg ICBUbyByZWR1Y2UgdGhlIHR5cGluZyByZXF1aXJlbWVudHMgZm9yIGFyZ3VtZW50cyAoYW5k IHRvIHBheQoJICAgIGhvbWFnZSB0byB0aGUgYWdlLW9sZCB0cmFkaXRpb24gb2YgVU5JWCBj cnlwdG90YXhvbm9teSkgSQoJICAgIGhhdmUgYWRkZWQgc29tZSBzaG9ydCBmb3JtcwlvZiB0 aGUgZmxhZ3MuICBIZXJlIGlzIGEgY29ycmUtCgkgICAgc3BvbmRlbmNlIGNoYXJ0OgoKCSAg ICBib3g7IHxsdygwLjRpKXxsdygxLjJpKXwgfGNCdygwLjRpKXxsQncoMS4yaSl8LgoJICAg IFNob3J0ICAgICBMb25nIGkIaQhpCGkJaQhpCGkIaW4IbghuCG4gbwhvCG8IbwlvCG8Ibwhv dQh1CHUIdXQIdAh0CHQgZQhlCGUIZQkgZQhlCGUIZXIIcghyCHJyCHIIcghyICMIIwgjCCNf CG4JICBmCGYIZghmZAhkCGQIZF8IbgoJICAgIHYIdgh2CHYJIHYIdgh2CHZlCGUIZQhlcghy CHIIcmIIYghiCGJvCG8IbwhvcwhzCHMIc2UIZQhlCGUgMQgxCDEIMSAgICBvCG8Ibwhvbghu CG4IbmMIYwhjCGNlCGUIZQhlIHEIcQhxCHEJcQhxCHEIcXUIdQh1CHVpCGkIaQhpZQhlCGUI ZXQIdAh0CHQgdQh1CHUIdQkgICB1CHUIdQh1bghuCG4IbmkIaQhpCGl4CHgIeAh4CWQIZAhk CGQgICAgZAhkCGQIZGEIYQhhCGFlCGUIZQhlbQhtCG0IbW8IbwhvCG9uCG4IbghuCgkgICAg cwhzCHMIcwkgcwhzCHMIc2UIZQhlCGVyCHIIcghyaQhpCGkIaWEIYQhhCGFsCGwIbAhsCXAI cAhwCHAgICAgZghmCGYIZm8IbwhvCG9yCHIIcghyZQhlCGUIZWkIaQhpCGlnCGcIZwhnbghu CG4IbnAIcAhwCHBvCG8IbwhvcghyCHIIcnQIdAh0CHQgaAhoCGgIaCAgICBmCGYIZghmbwhv CG8Ib3IIcghyCHJlCGUIZQhlaQhpCGkIaWcIZwhnCGduCG4IbghuaAhoCGgIaG8IbwhvCG9z CHMIcwhzdAh0CHQIdCBICEgISAhIICAgIGwIbAhsCGxvCG8IbwhvYwhjCGMIY2EIYQhhCGFs CGwIbAhsaAhoCGgIaG8IbwhvCG9zCHMIcwhzdAh0CHQIdAoKCSAgICBGb3IJZXhhbXBsZSwg dGhlIGZvbGxvd2luZyBjb21tYW5kCgoJICAgIGV4YW1wbGUkIGZhdWNldCAzMDAwIC0tb3V0 IC0tdmVyYm9zZSAtLW9uY2UJLS1mb3JlaWduaG9zdCBjbGllbnQgZWNobyBibGFoCgoJICAg IGNvdWxkIGJlIHdyaXR0ZW4KCgkgICAgZXhhbXBsZSQgZmF1Y2V0IDMwMDAgLW92MWggY2xp ZW50IGVjaG8gYmxhaAoKCSAgICBUaGUJLQgtCC0ILXAIcAhwCHAsIC0ILQgtCC1oCGgIaAho LAlhbmQgLQgtCC0ILUgISAhICEggZmxhZ3MgdGFrZSBhbiBhcmd1bWVudCwgYnV0IHRoZSBm bGFncyBtYXkKCSAgICBiZSBncm91cGVkIGludG8gb25lCWFyZ3VtZW50LiAgVGhleQl0aGVu IGdyYWIgdGhlIGFyZ3VtZW50cwoJICAgIHRoZXkgbmVlZCBmcm9tIHRoZSBjb21tYW5kIGxp bmUgaW4gdGhlIG9yZGVyIHRoZSBmbGFncwoJICAgIGFwcGVhci4KCgkgICAgZXhhbXBsZSQg ZmF1Y2V0IDMwMDAgLWhwSG92MSBjbGllbnQJMjk5OSBleGFtcGxlLWxlMiBlY2hvIGJsYWgK CgkgICAgV2hlcmVhcyBlYWNoIC0ILQgtCC0tCC0ILQgtZghmCGYIZmQIZAhkCGQgd29yZCBm bGFnCXJlcXVpcmVkIGFuIGluZGl2aWR1YWwgZGVzY3JpcC0KCSAgICB0b3IsIHRoZSAtCC0I LQgtIwgjCCMIIwljaGFyYWN0ZXIgZmxhZyBjYW4gdGFrZQltdWx0aXBsZSBkZXNjcmlwdG9y cy4KCSAgICBUaGUJZm9sbG93aW5nIGFyZSBlcXVpdmFsZW50OgoKCSAgICBleGFtcGxlJCBm YXVjZXQgMzAwMCAtLWZkIDAJLS1mZCAxIC0tdmVyYm9zZSAtLW9uY2UJZWNobyBibGFoCgkg ICAgZXhhbXBsZSQgZmF1Y2V0IDMwMDAgLSMwLDF2CS0tb25jZSBlY2hvIGJsYWgKCSAgICBl eGFtcGxlJCBmYXVjZXQgMzAwMCAtdjEjMCwxIGVjaG8gYmxhaAoKCgogICAgICAgUGFnZSAz CQkJCQkgICAgICAobGFzdCBtb2QuIDIvNC85MykKCgoKCgoKICAgICAgIEYIRghGCEZBCEEI QQhBVQhVCFUIVUMIQwhDCENFCEUIRQhFVAhUCFQIVCgIKAgoCCgxCDEIMQgxKQgpCCkIKSAg ICAgICBVCFUIVQhVTghOCE4ITkkISQhJCElYCFgIWAhYIFMIUwhTCFN5CHkIeQh5cwhzCHMI c3QIdAh0CHRlCGUIZQhlbQhtCG0IbSBWCFYIVghWICgIKAgoCChPCE8ITwhPYwhjCGMIY3QI dAh0CHRvCG8IbwhvYghiCGIIYmUIZQhlCGVyCHIIcghyIDIIMggyCDI4CDgIOAg4LAgsCCwI LCAxCDEIMQgxOQg5CDkIOTkIOQg5CDk4CDgIOAg4KQgpCCkIKQkgICAgICAgRghGCEYIRkEI QQhBCEFVCFUIVQhVQwhDCEMIQ0UIRQhFCEVUCFQIVAhUKAgoCCgIKDEIMQgxCDEpCCkIKQgp CgoKCgkgICAgZXhhbXBsZSQgZmF1Y2V0IDMwMDAgLSMwLDF2MSBlY2hvIGJsYWgKCgkgICAg Tm90ZSB0aGF0IHlvdSBoYXZlIHRvIHBheSBhdHRlbnRpb24Jd2hlbiB1c2luZyB0aGUgLQgt CC0ILSMIIwgjCCMgY2hhci0KCSAgICBhY3RlciBmbGFnIGFuZCB0aGUgLQgtCC0ILTEIMQgx CDEgY2hhcmFjdGVyIGZsYWcgaW4gdGhlCXNhbWUgYXJndW1lbnQuCgkgICAgQWxzbywgcmVt ZW1iZXIgdGhlIHNwZWNpYWwgc2h1dGRvd24oMikgc2VtYW50aWNzIG9mCS0ILQgtCC1pCGkI aQhpbghuCG4IbiBhbmQKCSAgICAtCC0ILQgtbwhvCG8Ib3UIdQh1CHV0CHQIdAh0LgoKCiAg ICAgICBFCEUIRQhFWAhYCFgIWEEIQQhBCEFNCE0ITQhNUAhQCFAIUEwITAhMCExFCEUIRQhF UwhTCFMIUwoJICAgIFRoaXMgY3JlYXRlcyBhIFRDUC1JUCBzb2NrZXQgb24gdGhlCWxvY2Fs IG1hY2hpbmUgYm91bmQgdG8KCSAgICBwb3J0IDMwMDAuCgoJICAgIGV4YW1wbGUkIGZhdWNl dCAzMDAwIC0tb3V0IC0tdmVyYm9zZSB0YXIgLWNmIC0gLgoKCSAgICBFdmVyeSB0aW1lIHNv bWUgcHJvY2VzcyAoZnJvbSBhbnkgbWFjaGluZSkgYXR0ZW1wdHMJdG8gY29uLQoJICAgIG5l Y3QgdG8gcG9ydCAzMDAwIG9uIHRoaXMgbWFjaGluZSB0aGUgZghmCGYIZmEIYQhhCGF1CHUI dQh1YwhjCGMIY2UIZQhlCGV0CHQIdAh0IHByb2dyYW0gd2lsbAoJICAgIGZvcmsoMikgYSBw cm9jZXNzIGFuZCB0aGUgY2hpbGQgd2lsbCBleGVjKDIpIGEKCgkgICAgdGFyCS1jZiAtIC4K CgkgICAgVGhlCS0ILQgtCC0tCC0ILQgtbwhvCG8Ib3UIdQh1CHV0CHQIdAh0IG9wdGlvbiBt ZWFucyB0aGF0CXRoZSBvdXRwdXQgb2YgdGhlIGNoaWxkCXByb2Nlc3MKCSAgICB3aWxsIGhh dmUgYmVlbiByZWRpcmVjdGVkIGludG8gdGhlIG5ldyBzb2NrZXQgcmV0cmlldmVkIGJ5Cgkg ICAgdGhlCWFjY2VwdCgyKSBjYWxsLgkgLQgtCC0ILS0ILQgtCC12CHYIdgh2ZQhlCGUIZXII cghyCHJiCGIIYghibwhvCG8Ib3MIcwhzCHNlCGUIZQhlIG1lYW5zIHRoYXQgZmF1Y2V0IHdp bGwgcHJpbnQKCSAgICBpbmZvcm1hdGlvbglhYm91dCBlYWNoIG5ldyBjb25uZWN0aW9uLgoK CSAgICBUaGlzIGNyZWF0ZXMgYSBVTklYCWRvbWFpbiBzb2NrZXQgaW4gdGhlIGN1cnJlbnQg ZGlyZWN0b3J5CgoJICAgIGV4YW1wbGUkIGZhdWNldCB1LXNvY2tldCAtLW91dCAtLWVyciAt LW9uY2UJLS11bml4IGNzaCAtYyBcCgkJICJkZCBpZj1hbmdpby5wZ20gfCBmdW5reS5wZXJs LnNjcmlwdCIKCgkgICAgVGhlCS0ILQgtCC0tCC0ILQgtbwhvCG8Ib3UIdQh1CHV0CHQIdAh0 IC0ILQgtCC0tCC0ILQgtZQhlCGUIZXIIcghyCHJyCHIIcghyIG9wdGlvbiBtZWFucyB0aGF0 IHN0ZG91dCBhbmQgc3RkZXJyCXdpbGwgYmUKCSAgICByZWRpcmVjdGVkIGluIHRoZSBjaGls ZCBwcm9jZXNzLiAgVGhlIC0ILQgtCC0tCC0ILQgtbwhvCG8Ib24IbghuCG5jCGMIYwhjZQhl CGUIZSBvcHRpb24JbWVhbnMKCSAgICB0aGF0IHRoZSBmYXVjZXQgd2lsbCBub3QgZm9yaygy KSwgYnV0IGV4ZWMoMikgdGhlIHByb2Nlc3Mgc28KCSAgICB0aGF0IG9ubHkgdGhlIGZpcnN0 CXByb2Nlc3MJY2FuIGNvbm5lY3QgdG8gdGhlIHUtc29ja2V0CgkgICAgYmVmb3JlIHRoZSBm YXVjZXQgYmVjb21lcyB1bmF2YWlsYWJsZS4KCgkgICAgVGhpcyBleGFtcGxlIGxpc3RlbnMg b24gYSBzb2NrZXQgdW50aWwgdGhlIGZpcnN0IGNvbm5lY3Rpb24KCSAgICBjb21lcyB0aHJv dWdoLiAgSXQgdGhlbiBzcGF3bnMgYSBiaWRpcmVjdGlvbmFsIGNvcHkJdGhhdCBpcwoJICAg IHNpbWlsYXIgdG8gaG9zZSAtc2xhdmUuCgoJICAgIGZhdWNldCAzMDAwCS0xdiAtLWZkIDMg c2ggLWMgJ2NhdCA8JjMgJiBjYXQJPiYzIDsgc29ja2Rvd24gMycKCgogICAgICAgUwhTCFMI U0UIRQhFCEVFCEUIRQhFIEEIQQhBCEFMCEwITAhMUwhTCFMIU08ITwhPCE8KCSAgICBuZXRw aXBlcyAoMSksIGhvc2UgKDEpLCBzb2NrZG93biAoMSksIGdldHBlZXJuYW1lICgxKSwKCSAg ICBzb2NrZXQgKDIpLAliaW5kICgyKSwgbGlzdGVuICgyKSwgYWNjZXB0ICgyKSwgc2h1dGRv d24gKDIpLAoJICAgIHNlcnZpY2VzICg1KSwgZ2V0aG9zdGJ5YWRkcgkoMykKCgogICAgICAg QghCCEIIQlUIVQhVCFVHCEcIRwhHUwhTCFMIUwoJICAgIFRoZXJlIGlzIGEgcHJvYmxlbSB3 aXRoIGFsbW9zdCBldmVyeSBPUyBJIGhhdmUgdXNlZAlmYXVjZXQKCSAgICBvbi4JIFBvcnRz IGFyZSBzb21ldGltZXMgbm90IHJlY3ljbGVkIHN3aWZ0bHkgZW5vdWdoLiAgSWYKCgoKICAg ICAgIFBhZ2UgNAkJCQkJICAgICAgKGxhc3QgbW9kLiAyLzQvOTMpCgoKCgoKCiAgICAgICBG CEYIRghGQQhBCEEIQVUIVQhVCFVDCEMIQwhDRQhFCEUIRVQIVAhUCFQoCCgIKAgoMQgxCDEI MSkIKQgpCCkgICAgICAgVQhVCFUIVU4ITghOCE5JCEkISQhJWAhYCFgIWCBTCFMIUwhTeQh5 CHkIeXMIcwhzCHN0CHQIdAh0ZQhlCGUIZW0IbQhtCG0gVghWCFYIViAoCCgIKAgoTwhPCE8I T2MIYwhjCGN0CHQIdAh0bwhvCG8Ib2IIYghiCGJlCGUIZQhlcghyCHIIciAyCDIIMggyOAg4 CDgIOCwILAgsCCwgMQgxCDEIMTkIOQg5CDk5CDkIOQg5OAg4CDgIOCkIKQgpCCkJICAgICAg IEYIRghGCEZBCEEIQQhBVQhVCFUIVUMIQwhDCENFCEUIRQhFVAhUCFQIVCgIKAgoCCgxCDEI MQgxKQgpCCkIKQoKCgoJICAgIHlvdQlraWxsIG9uZSBmYXVjZXQJYW5kIHRyeQl0byBzdGFy dCBhbm90aGVyIHRoYXQgd2FudHMgdG8KCSAgICBsaXN0ZW4gb24gdGhlIHNhbWUgcG9ydCB5 b3UJd2lsbCBvZnRlbiBzZWUgcHJlLTQuMSBmYXVjZXRzCgkgICAgcHJpbnQgdGhlIGZvbGxv d2luZwl3YXJuaW5nCW92ZXIgYW5kIG92ZXIgYWdhaW46CgoJICAgIGZhdWNldDogQWRkcmVz cyAzMDAwIGluIHVzZSwgc2xlZXBpbmcgMTAuCgkgICAgZmF1Y2V0OiBUcnlpbmcgYWdhaW4g LiAuIC4KCgkgICAgYnV0CXlvdSB3b24ndCBhY3R1YWxseSBiZSBhYmxlIHRvIGNvbm5lY3Qo MikgdG8gdGhhdCBwb3J0CgkgICAgKHdpdGggaAhoCGgIaG8IbwhvCG9zCHMIcwhzZQhlCGUI ZSgxKSwgZm9yIGV4YW1wbGUpCWJlY2F1c2UJeW91J2xsIGdldCBhIGBgY29ubmVjLQoJICAg IHRpb24gcmVmdXNlZCcnLgoKCSAgICBUaGVyZSB3YXMgYWxzbyBhbiBleHBlcmltZW50YWwg TGludXgga2VybmVsCXRoYXQgTkVWRVIgcmVjeS0KCSAgICBjbGVkIHBvcnRzIChJIHF1aWNr bHkgc3dpdGNoZWQgYmFjawl0byBteSBvbGQga2VybmVsKS4KCgkgICAgSSBoYXZlIGJlZW4J aW5mb3JtZWQgdGhhdCB0aGlzIGlzIGEJc2lkZS1lZmZlY3Qgb2YgdGhlIFRDUAoJICAgIHNw ZWNpZmljYXRpb24gYW5kIHRoYXQgSSBzaG91bGQgdXNlCXRoZSBTT19SRVVTRUFERFIgb3B0 aW9uCgkgICAgdG8gd29yayBhcm91bmQgaXQsIHNvIEkgZG8uCgoKICAgICAgIE4ITghOCE5P CE8ITwhPVAhUCFQIVEUIRQhFCEVTCFMIUwhTCgkgICAgRG91YnRsZXNzIHRoZXJlIGFyZQli dWdzIGluCXRoaXMgcHJvZ3JhbSwgZXNwZWNpYWxseSBpbiB0aGUKCSAgICB1bml4IGRvbWFp bglzb2NrZXQgcG9ydGlvbnMuICBJIHdlbGNvbWUgcHJvYmxlbSByZXBvcnRzIGFuZAoJICAg IHdvdWxkIGxpa2UgdG8gbWFrZSB0aGVzZSBwcm9ncmFtcyBhcyAiY2xlYW4iIChubyBsZWZ0 b3ZlcgoJICAgIGZpbGVzLCBzb2NrZXRzKSBhcyBwb3NzaWJsZS4KCgkgICAgNC4xCWFkZGVk IC0ILQgtCC0tCC0ILQgtYghiCGIIYmEIYQhhCGFjCGMIYwhjawhrCGsIa2wIbAhsCGxvCG8I bwhvZwhnCGcIZwlhbmQgLQgtCC0ILS0ILQgtCC1uCG4IbghubwhvCG8Ib3IIcghyCHJlCGUI ZQhldQh1CHUIdXMIcwhzCHNlCGUIZQhlYQhhCGEIYWQIZAhkCGRkCGQIZAhkcghyCHIIci4g IC0ILQgtCC0tCC0ILQgtbghuCG4Ibm8IbwhvCG9yCHIIcghyZQhlCGUIZXUIdQh1CHVzCHMI cwhzZQhlCGUIZWEIYQhhCGFkCGQIZAhkZAhkCGQIZHIIcghyCHIKCSAgICByZWZsZWN0cyB0 aGUgZmFjdCB0aGF0IDQuMSBhbHNvIGFkZGVkIHRoZSBTT19SRVVTRUFERFIKCSAgICBzb2Nr ZXQgb3B0aW9uIGFzIHRoZSBkZWZhdWx0LgoKCSAgICA0LjAJbWFkZSB0aGUgZnVsbC13b3Jk IGFyZ3VtZW50cyB1c2UgLS0gbGlrZSBtYW55IEdOVSBwcm8tCgkgICAgZ3JhbXMuICBUaGV5 IGFyZSBzdGlsbCBhdmFpbGFibGUgd2l0aCBhIHNpbmdsZSAtIGZvcgoJICAgIGJhY2t3YXJk LWNvbXBhdGliaWxpdHkuCgoJICAgIDMuMQlhZGRlZCB0aGUgc2luZ2xlLWNoYXJhY3RlciBm bGFncyBhbmQgdGhlIC1waWRmaWxlCgkgICAgb3B0aW9uLiAgSXQJYWxzbyBzd2l0Y2hlZCB0 byB0aGUgc2V0c2lkKDIpIHN5c3RlbSBjYWxsIHRvCgkgICAgZGV0YWNoIGl0c2VsZiBmcm9t IHRoZSBwcm9jZXNzIGdyb3VwIGZvciB0aGUgLWRhZW1vbiBmbGFnLgoJICAgIEkndmUgYmVl biBoYWNraW5nIGF0IFVOSVggZm9yIHllYXJzLCBidXQgdGhlcmUgYXJlIHN0aWxsCgkgICAg c29tZSB0aGluZ3MJdGhhdCBJIG5ldmVyIHJlYWxseSBsZWFybmVkLCBhbmQgb3RoZXJzCXRo YXQKCSAgICBoYXZlIGJlZW4gY2hhbmdpbmcuCSBJIG5lZWQJdG8gYnV5IGEgYm9vay4KCgkg ICAgUmVsZWFzZSAyLjMJYWRkZWQgc3VwcG9ydCBmb3IgbXVsdGktaG9tZWQgaG9zdHM6IGhv c3RzIHdpdGgKCSAgICBtdWx0aXBsZSBpbnRlcm5ldCBudW1iZXJzIChzdWNoIGFzIGdhdGV3 YXlzKS4gIEJlZm9yZSB0aGlzCgkgICAgZmF1Y2V0IGFzc3VtZWQgdGhhdAl0aGUgZmlyc3Qg aW50ZXJuZXQgbnVtYmVyIHRoYXQgZ2V0aG9zdC0KCSAgICBieW5hbWUgcmV0dXJuZWQgd2Fz CXRoZSBvbmx5IG9uZS4gIC0ILQgtCC0tCC0ILQgtZghmCGYIZm8IbwhvCG9yCHIIcghyZQhl CGUIZWkIaQhpCGlnCGcIZwhnbghuCG4IbmgIaAhoCGhvCG8IbwhvcwhzCHMIc3QIdAh0CHQg YXV0aGVudGljYS0KCSAgICB0aW9uIHdhcyB3ZWFrZW5lZCBieSB0aGlzIGluYWRlcXVhY3kg c28gSSBiZWVmZWQgdXAJdGhlCgkgICAgYWxnb3JpdGhtcy4JIC0ILQgtCC0tCC0ILQgtZghm CGYIZm8IbwhvCG9yCHIIcghyZQhlCGUIZWkIaQhpCGlnCGcIZwhnbghuCG4IbmgIaAhoCGhv CG8IbwhvcwhzCHMIc3QIdAh0CHQgd2lsbCBhY2NlcHQgYSBjb25uZWN0aW9uCWZyb20gYW55 CgkgICAgb2YgdGhlIGludGVybmV0IG51bWJlcnMgYXNzb2NpYXRlZCB3aXRoIHRoZQlob3N0 IG5hbWUuCgoKICAgICAgIEMIQwhDCENSCFIIUghSRQhFCEUIRUQIRAhECERJCEkISQhJVAhU CFQIVFMIUwhTCFMKCSAgICBUaGFua3MgdG8gU3RldmUgQ2xpZnQgPGNsaWZ0QG1sLmNzaXJv LmF1PiBmb3IgU0dJIChTeXNWKQoJICAgIHBhdGNoZXMuCgoKCiAgICAgICBQYWdlIDUJCQkJ CSAgICAgIChsYXN0IG1vZC4gMi80LzkzKQoKCgoKCgogICAgICAgRghGCEYIRkEIQQhBCEFV CFUIVQhVQwhDCEMIQ0UIRQhFCEVUCFQIVAhUKAgoCCgIKDEIMQgxCDEpCCkIKQgpICAgICAg IFUIVQhVCFVOCE4ITghOSQhJCEkISVgIWAhYCFggUwhTCFMIU3kIeQh5CHlzCHMIcwhzdAh0 CHQIdGUIZQhlCGVtCG0IbQhtIFYIVghWCFYgKAgoCCgIKE8ITwhPCE9jCGMIYwhjdAh0CHQI dG8IbwhvCG9iCGIIYghiZQhlCGUIZXIIcghyCHIgMggyCDIIMjgIOAg4CDgsCCwILAgsIDEI MQgxCDE5CDkIOQg5OQg5CDkIOTgIOAg4CDgpCCkIKQgpCSAgICAgICBGCEYIRghGQQhBCEEI QVUIVQhVCFVDCEMIQwhDRQhFCEUIRVQIVAhUCFQoCCgIKAgoMQgxCDEIMSkIKQgpCCkKCgoK CSAgICBNYW55IHBlb3BsZQljb21wbGFpbmVkIGFib3V0IHRoZSBvbGQgd2F5IG9mCXNwZWNp ZnlpbmcgdGhlCgkgICAgY29tbWFuZC4gIFRoYW5rcyB0bwl3aG9ldmVyCWdhdmUgbWUJdGhl IGFsdGVybmF0aXZlCXdoaWNoIGlzCgkgICAgbm93CWltcGxlbWVudGVkLiAgSXQgaXMgbXVj aCBiZXR0ZXIuCgoJICAgIFJhbmR5IEZpc2NoZXIgPGZpc2NoZXJAdWNldC51ZmwuZWR1PiBm aW5hbGx5IHByb2RkZWQgbWUgaW50bwoJICAgIGZpeGluZyB0aGUgb2xkIGxhbWUJbm9uLWhh bmRsaW5nIG9mCW11bHRpLWhvbWVkIGhvc3QuCgoJICAgIFRoYW5rcyB0byBhbGwgd2hvIHN1 Z2dlc3RlZAlJIHVzZSBzZXRzaWQoKSBmb3IgLWRhZW1vbiBtb2RlLgoKCSAgICBUaGFua3Mg dG8gdGhlIFNwcmluZyAxOTk2IFVGIENJUyBjb25zdWx0aW5nCXN0YWZmCgkgICAgPGNvbnN1 bHRAY2lzLnVmbC5lZHU+IGZvciBwb2ludGluZyBvdXQgdGhlIHN5c19lcnJsaXN0W10KCSAg ICBkZWNsYXJhdGlvbgljb25mbGljdCBvbiBGcmVlQlNELiAgU29tZXRpbWVzCUkgaGF0ZSBT dW4KCSAgICBNaWNyb3N5c3RlbXMuCgoJICAgIFRoYW5rcyB0byBEYW5pZWwgTydDb25ub3IK CSAgICA8ZG9jb25ub3JAYWRhbS5pc3QuZmxpbmRlcnMuZWR1LmF1Pglmb3Igc3VnZ2VzdGlu ZyB0aGUgLXBpZC0KCSAgICBmaWxlIGZsYWcuCgoJICAgIEJpZwl0aGFua3MgdG8gSm9lIFRy YWlzdGVyIDx0cmFpc3RlckBnYXRlLm5ldD4gZm9yIGhpcyBzaWctCgkgICAgbmFsCWhhbmRs aW5nIHBhdGNoZXMsIHN0cmVycm9yIHN1cnJvZ2F0ZSwgYW5kIG90aGVyCWFzc29ydGVkCgkg ICAgaGFja3MuCgoJICAgIFRoYW5rcyB0byBUaG9tYXMgQS4JRW5kbyA8dGVuZG9AbmV0Y29t LmNvbT4JZm9yIGRyb3BwaW5nIGFuCgkgICAgU09fUkVVU0VBRERSIHBhdGNoIGluIG15IGxh cC4gIE90aGVyd2lzZSBJIHdvdWxkbid0CWhhdmUKCSAgICBnb3R0ZW4gdG8gaXQgdGlsbCAy MDAxLgoKCiAgICAgICBDCEMIQwhDTwhPCE8IT1AIUAhQCFBZCFkIWQhZUghSCFIIUkkISQhJ CElHCEcIRwhHSAhICEgISFQIVAhUCFQKCSAgICBDb3B5cmlnaHQgKEMpIDE5OTItOTggUm9i ZXJ0IEZvcnNtYW4KCgkgICAgVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBj YW4gcmVkaXN0cmlidXRlCWl0CgkgICAgYW5kL29yIG1vZGlmeSBpdCB1bmRlciB0aGUgdGVy bXMgb2YJdGhlIEdOVQlHZW5lcmFsCVB1YmxpYwoJICAgIExpY2Vuc2UgYXMgcHVibGlzaGVk IGJ5IHRoZQlGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlcgoJICAgIHZlcnNpb24g MiBvZiB0aGUgTGljZW5zZSwgb3IgKGF0IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyLQoJ ICAgIHNpb24uCgoJICAgIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZAlpbiB0aGUgaG9w ZSB0aGF0IGl0IHdpbGwgYmUgdXNlLQoJICAgIGZ1bCwgYnV0IFdJVEhPVVQgQU5ZIFdBUlJB TlRZOyB3aXRob3V0IGV2ZW4JdGhlIGltcGxpZWQgd2FyLQoJICAgIHJhbnR5IG9mIE1FUkNI QU5UQUJJTElUWSBvcglGSVRORVNTCUZPUiBBIFBBUlRJQ1VMQVIgUFVSLQoJICAgIFBPU0Uu ICBTZWUgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMu CgoJICAgIFlvdQlzaG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5l cmFsIFB1YmxpYwoJICAgIExpY2Vuc2UgYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmCW5v dCwgd3JpdGUgdG8gdGhlIEZyZWUKCSAgICBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuLCA2 NzUgTWFzcwlBdmUsIENhbWJyaWRnZSwJTUEKCSAgICAwMjEzOSwgVVNBLgoKCiAgICAgICBB CEEIQQhBVQhVCFUIVVQIVAhUCFRICEgISAhITwhPCE8IT1IIUghSCFIKCSAgICBSb2JlcnQg Rm9yc21hbgoJICAgICB0aG90aEBwdXJwbGVmcm9nLmNvbQoJICAgICBQdXJwbGUgRnJvZyBT b2Z0d2FyZQoJICAgICBodHRwOi8vd2ViLnB1cnBsZWZyb2cuY29tL350aG90aC8KCgoKICAg ICAgIFBhZ2UgNgkJCQkJICAgICAgKGxhc3QgbW9kLiAyLzQvOTMpCgoKCg== --------------040209070908030303010506-- From owner-freebsd-arch@FreeBSD.ORG Fri Jul 2 03:07:23 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D99EE106566C for ; Fri, 2 Jul 2010 03:07:23 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id B91858FC08 for ; Fri, 2 Jul 2010 03:07:23 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o6237GHD045527; Thu, 1 Jul 2010 20:07:16 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o6237FaF045526; Thu, 1 Jul 2010 20:07:15 -0700 (PDT) (envelope-from sgk) Date: Thu, 1 Jul 2010 20:07:15 -0700 From: Steve Kargl To: Cyrille Lefevre Message-ID: <20100702030715.GA45486@troutmask.apl.washington.edu> References: <201006302100.o5UL0L5X058705@fire.js.berklix.net> <4C2C1408.6080703@laposte.net> <4C2D5441.9020408@laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C2D5441.9020408@laposte.net> User-Agent: Mutt/1.4.2.3i Cc: "Julian H. Stacey" , Julian Elischer , Erik Cederstrand , freebsd-arch@freebsd.org Subject: Re: dwb : groff replacement proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 03:07:23 -0000 On Fri, Jul 02, 2010 at 04:51:45AM +0200, Cyrille Lefevre wrote: > Hi, > > it works w/ a little change for now. What is 'it'? If 'it' refers to DWB as distributed in http://www.research.att.com/~gsf/download/tgz/dwb.1993-02-04.tgz You might want to read the thread that includes http://mail-index.netbsd.org/tech-userlevel/2009/03/14/msg001839.html -- steve From owner-freebsd-arch@FreeBSD.ORG Fri Jul 2 12:46:38 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6F23106566B; Fri, 2 Jul 2010 12:46: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 8ABE98FC0A; Fri, 2 Jul 2010 12:46: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 o62CjwOP009613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Jul 2010 15:45:58 +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 o62CjwZ3008063; Fri, 2 Jul 2010 15:45:58 +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 o62CjwLW008062; Fri, 2 Jul 2010 15:45:58 +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: Fri, 2 Jul 2010 15:45:58 +0300 From: Kostik Belousov To: David Xu Message-ID: <20100702124555.GR13238@deviant.kiev.zoral.com.ua> References: <20100701134217.GM13238@deviant.kiev.zoral.com.ua> <201007011705.26173.john@baldwin.cx> <20100701212710.GP13238@deviant.kiev.zoral.com.ua> <4C2D4B65.8080708@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BVBPRygDtbGal1Jh" Content-Disposition: inline In-Reply-To: <4C2D4B65.8080708@freebsd.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: John Baldwin , freebsd-arch@freebsd.org Subject: Re: Access to siginfo for the signal from debugger X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 12:46:38 -0000 --BVBPRygDtbGal1Jh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 02, 2010 at 10:13:57AM +0800, David Xu wrote: > Kostik Belousov wrote: > >On Thu, Jul 01, 2010 at 05:05:26PM -0400, John Baldwin wrote: > >>On Thursday 01 July 2010 09:42:17 am Kostik Belousov wrote: > >>>Hi, > >>>below is the patch that provides the debugger with access to siginfo > >>>of the signal that stopped the debuggee. This allows to see a lot more > >>>details for the cause of the process stop. E.g. you can see a fault > >>>address if process get SIGSEGV or SIGBUS, you can distinguish between > >>>breakpoint-generated SIGTRAP and non-breakpoint, whether the signal > >>>was send due to external event etc. > >>> > >>>The change to struct ptrace_lwpinfo is backward-compatible in the sense > >>>that programs that were compiled with old definition for the struct wi= ll > >>>work on new kernels. > >>Nice! Does gdb "just work" with these changes or does it need patching= =20 > >>as well? > >It should "just work", and my testing seems to confirm this. gdb uses > >PT_LWPINFO to enumerate the thread ids, and I checked it on mt process. > > > >As I said, the change is ABI backward-compatible, i.e. you do not need > >even to recompile the old program for new kernel. > > > >Sure, gdb cannot show additional available information without > >modifications. >=20 > Yes, you can add new fields to ptrace_lwpinfo without any problem. > To print new fields, you should change the function > fbsd_thread_signal_cmd in file > src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c > after change, you just type 'thread signal' command in gdb to > show thread's signal info. The command is freebsd specific, > others may or may not have it. I did what you suggested. The drawback there is that "thread signal" only works for the threaded processes. diff --git a/gnu/usr.bin/gdb/libgdb/fbsd-threads.c b/gnu/usr.bin/gdb/libgdb= /fbsd-threads.c index eb83f2e..6b424bc 100644 --- a/gnu/usr.bin/gdb/libgdb/fbsd-threads.c +++ b/gnu/usr.bin/gdb/libgdb/fbsd-threads.c @@ -1299,6 +1299,7 @@ fbsd_thread_signal_cmd (char *exp, int from_tty) td_thrhandle_t th; td_thrinfo_t ti; td_err_e err; + const char *code; =20 if (!fbsd_thread_active || !IS_THREAD(inferior_ptid)) return; @@ -1315,6 +1316,40 @@ fbsd_thread_signal_cmd (char *exp, int from_tty) fbsd_print_sigset(&ti.ti_sigmask); printf_filtered("signal pending:\n"); fbsd_print_sigset(&ti.ti_pending); + if (ti.ti_siginfo.si_signo !=3D 0) { + printf_filtered("si_signo %d\n", ti.ti_siginfo.si_signo); + printf_filtered("si_errno %d (%s)\n", ti.ti_siginfo.si_errno, + strerror(ti.ti_siginfo.si_errno)); + switch (ti.ti_siginfo.si_code) { + case SI_NOINFO: + code =3D "NOINFO"; + break; + case SI_USER: + code =3D "USER"; + break; + case SI_QUEUE: + code =3D "QUEUE"; + break; + case SI_TIMER: + code =3D "TIMER"; + break; + case SI_ASYNCIO: + code =3D "ASYNCIO"; + break; + case SI_MESGQ: + code =3D "MESGQ"; + break; + case SI_KERNEL: + code =3D "KERNEL"; + break; + default: + code =3D "UNKNOWN"; + break; + } + printf_filtered("si_code %s si_pid %d si_uid %d si_status %x si_addr %= p\n", + code, ti.ti_siginfo.si_pid, ti.ti_siginfo.si_uid, ti.ti_siginfo.si_s= tatus, + ti.ti_siginfo.si_addr); + } } =20 static int diff --git a/lib/libthread_db/Symbol.map b/lib/libthread_db/Symbol.map index 65e78d4..4e690f9 100644 --- a/lib/libthread_db/Symbol.map +++ b/lib/libthread_db/Symbol.map @@ -19,7 +19,6 @@ FBSD_1.0 { td_thr_dbsuspend; td_thr_event_enable; td_thr_event_getmsg; - td_thr_get_info; td_thr_getfpregs; td_thr_getgregs; #if defined(i386) @@ -33,3 +32,7 @@ FBSD_1.0 { td_thr_tls_get_addr; td_thr_validate; }; + +FBSD_1.2 { + td_thr_get_info; +}; diff --git a/lib/libthread_db/libpthread_db.c b/lib/libthread_db/libpthread= _db.c index 65478a7..31ea15d 100644 --- a/lib/libthread_db/libpthread_db.c +++ b/lib/libthread_db/libpthread_db.c @@ -570,7 +570,7 @@ pt_thr_validate(const td_thrhandle_t *th) } =20 static td_err_e -pt_thr_get_info(const td_thrhandle_t *th, td_thrinfo_t *info) +pt_thr_old_get_info(const td_thrhandle_t *th, td_old_thrinfo_t *info) { const td_thragent_t *ta =3D th->th_ta; struct ptrace_lwpinfo linfo; @@ -659,6 +659,16 @@ pt_thr_get_info(const td_thrhandle_t *th, td_thrinfo_t= *info) return (0); } =20 +static td_err_e +pt_thr_get_info(const td_thrhandle_t *th, td_thrinfo_t *info) +{ + td_err_e e; + + e =3D pt_thr_old_get_info(th, (td_old_thrinfo_t *)info); + bzero(&info->ti_siginfo, sizeof(info->ti_siginfo)); + return (e); +} + #ifdef __i386__ static td_err_e pt_thr_getxmmregs(const td_thrhandle_t *th, char *fxsave) @@ -1114,6 +1124,7 @@ struct ta_ops libpthread_db_ops =3D { .to_thr_dbsuspend =3D pt_thr_dbsuspend, .to_thr_event_enable =3D pt_thr_event_enable, .to_thr_event_getmsg =3D pt_thr_event_getmsg, + .to_thr_old_get_info =3D pt_thr_old_get_info, .to_thr_get_info =3D pt_thr_get_info, .to_thr_getfpregs =3D pt_thr_getfpregs, .to_thr_getgregs =3D pt_thr_getgregs, diff --git a/lib/libthread_db/libthr_db.c b/lib/libthread_db/libthr_db.c index f79facb..33225f4 100644 --- a/lib/libthread_db/libthr_db.c +++ b/lib/libthread_db/libthr_db.c @@ -453,7 +453,7 @@ pt_thr_validate(const td_thrhandle_t *th) } =20 static td_err_e -pt_thr_get_info(const td_thrhandle_t *th, td_thrinfo_t *info) +pt_thr_get_info_common(const td_thrhandle_t *th, td_thrinfo_t *info, int o= ld) { const td_thragent_t *ta =3D th->th_ta; struct ptrace_lwpinfo linfo; @@ -489,6 +489,13 @@ pt_thr_get_info(const td_thrhandle_t *th, td_thrinfo_t= *info) if (ret =3D=3D PS_OK) { info->ti_sigmask =3D linfo.pl_sigmask; info->ti_pending =3D linfo.pl_siglist; + if (!old) { + if ((linfo.pl_flags & PL_FLAG_SI) !=3D 0) + info->ti_siginfo =3D linfo.pl_siginfo; + else + bzero(&info->ti_siginfo, + sizeof(info->ti_siginfo)); + } } else return (ret); if (state =3D=3D ta->thread_state_running) @@ -501,6 +508,20 @@ pt_thr_get_info(const td_thrhandle_t *th, td_thrinfo_t= *info) return (0); } =20 +static td_err_e +pt_thr_old_get_info(const td_thrhandle_t *th, td_old_thrinfo_t *info) +{ + + return (pt_thr_get_info_common(th, (td_thrinfo_t *)info, 1)); +} + +static td_err_e +pt_thr_get_info(const td_thrhandle_t *th, td_thrinfo_t *info) +{ + + return (pt_thr_get_info_common(th, info, 0)); +} + #ifdef __i386__ static td_err_e pt_thr_getxmmregs(const td_thrhandle_t *th, char *fxsave) @@ -761,6 +782,7 @@ struct ta_ops libthr_db_ops =3D { .to_thr_dbsuspend =3D pt_thr_dbsuspend, .to_thr_event_enable =3D pt_thr_event_enable, .to_thr_event_getmsg =3D pt_thr_event_getmsg, + .to_thr_old_get_info =3D pt_thr_old_get_info, .to_thr_get_info =3D pt_thr_get_info, .to_thr_getfpregs =3D pt_thr_getfpregs, .to_thr_getgregs =3D pt_thr_getgregs, diff --git a/lib/libthread_db/thread_db.c b/lib/libthread_db/thread_db.c index dc8195d..121855b 100644 --- a/lib/libthread_db/thread_db.c +++ b/lib/libthread_db/thread_db.c @@ -176,6 +176,14 @@ td_thr_event_getmsg(const td_thrhandle_t *th, td_event= _msg_t *msg) } =20 td_err_e +td_thr_old_get_info(const td_thrhandle_t *th, td_old_thrinfo_t *info) +{ + const td_thragent_t *ta =3D th->th_ta; + return (ta->ta_ops->to_thr_old_get_info(th, info)); +} +__sym_compat(td_thr_get_info, td_thr_old_get_info, FBSD_1.0); + +td_err_e td_thr_get_info(const td_thrhandle_t *th, td_thrinfo_t *info) { const td_thragent_t *ta =3D th->th_ta; diff --git a/lib/libthread_db/thread_db.h b/lib/libthread_db/thread_db.h index 44ddea4..8c30812 100644 --- a/lib/libthread_db/thread_db.h +++ b/lib/libthread_db/thread_db.h @@ -191,6 +191,7 @@ typedef struct { psaddr_t ti_startfunc; psaddr_t ti_stkbase; size_t ti_stksize; + siginfo_t ti_siginfo; } td_thrinfo_t; =20 /* diff --git a/lib/libthread_db/thread_db_int.h b/lib/libthread_db/thread_db_= int.h index 3b03062..92ba6e5 100644 --- a/lib/libthread_db/thread_db_int.h +++ b/lib/libthread_db/thread_db_int.h @@ -32,6 +32,25 @@ #include #include =20 +typedef struct { + const td_thragent_t *ti_ta_p; + thread_t ti_tid; + psaddr_t ti_thread; + td_thr_state_e ti_state; + td_thr_type_e ti_type; + td_thr_events_t ti_events; + int ti_pri; + lwpid_t ti_lid; + char ti_db_suspended; + char ti_traceme; + sigset_t ti_sigmask; + sigset_t ti_pending; + psaddr_t ti_tls; + psaddr_t ti_startfunc; + psaddr_t ti_stkbase; + size_t ti_stksize; +} td_old_thrinfo_t; + #define TD_THRAGENT_FIELDS \ struct ta_ops *ta_ops; \ TAILQ_ENTRY(td_thragent) ta_next; \ @@ -65,6 +84,8 @@ struct ta_ops { td_err_e (*to_thr_event_enable)(const td_thrhandle_t *, int); td_err_e (*to_thr_event_getmsg)(const td_thrhandle_t *, td_event_msg_t *); + td_err_e (*to_thr_old_get_info)(const td_thrhandle_t *, + td_old_thrinfo_t *); td_err_e (*to_thr_get_info)(const td_thrhandle_t *, td_thrinfo_t *); td_err_e (*to_thr_getfpregs)(const td_thrhandle_t *, prfpregset_t *); td_err_e (*to_thr_getgregs)(const td_thrhandle_t *, prgregset_t); @@ -103,4 +124,6 @@ int thr_pwrite_int(const struct td_thragent *, psaddr_t= , uint32_t); int thr_pwrite_long(const struct td_thragent *, psaddr_t, uint64_t); int thr_pwrite_ptr(const struct td_thragent *, psaddr_t, psaddr_t); =20 +td_err_e td_thr_old_get_info(const td_thrhandle_t *th, td_old_thrinfo_t *i= nfo); + #endif /* _THREAD_DB_INT_H_ */ diff --git a/sys/compat/freebsd32/freebsd32_misc.c b/sys/compat/freebsd32/f= reebsd32_misc.c index f0fde2b..1d60ed4 100644 --- a/sys/compat/freebsd32/freebsd32_misc.c +++ b/sys/compat/freebsd32/freebsd32_misc.c @@ -2208,7 +2208,7 @@ freebsd32_thr_suspend(struct thread *td, struct freeb= sd32_thr_suspend_args *uap) } =20 void -siginfo_to_siginfo32(siginfo_t *src, struct siginfo32 *dst) +siginfo_to_siginfo32(const siginfo_t *src, struct siginfo32 *dst) { bzero(dst, sizeof(*dst)); dst->si_signo =3D src->si_signo; diff --git a/sys/compat/freebsd32/freebsd32_signal.h b/sys/compat/freebsd32= /freebsd32_signal.h index ba0922a..2669581 100644 --- a/sys/compat/freebsd32/freebsd32_signal.h +++ b/sys/compat/freebsd32/freebsd32_signal.h @@ -96,6 +96,6 @@ struct sigevent32 { } _sigev_un; }; =20 -void siginfo_to_siginfo32(siginfo_t *src, struct siginfo32 *dst); +void siginfo_to_siginfo32(const siginfo_t *src, struct siginfo32 *dst); =20 #endif /* !_COMPAT_FREEBSD32_SIGNAL_H_ */ diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 04c2ba7..af3c7da 100644 --- a/sys/kern/kern_sig.c +++ b/sys/kern/kern_sig.c @@ -2522,7 +2522,6 @@ issignal(struct thread *td, int stop_allowed) struct sigacts *ps; struct sigqueue *queue; sigset_t sigpending; - ksiginfo_t ksi; int sig, prop, newsig; =20 p =3D td->td_proc; @@ -2565,10 +2564,10 @@ issignal(struct thread *td, int stop_allowed) * be thrown away. */ queue =3D &td->td_sigqueue; - ksi.ksi_signo =3D 0; - if (sigqueue_get(queue, sig, &ksi) =3D=3D 0) { + td->td_dbgksi.ksi_signo =3D 0; + if (sigqueue_get(queue, sig, &td->td_dbgksi) =3D=3D 0) { queue =3D &p->p_sigqueue; - sigqueue_get(queue, sig, &ksi); + sigqueue_get(queue, sig, &td->td_dbgksi); } =20 mtx_unlock(&ps->ps_mtx); @@ -2595,13 +2594,13 @@ issignal(struct thread *td, int stop_allowed) continue; signotify(td); } else { - if (ksi.ksi_signo !=3D 0) { - ksi.ksi_flags |=3D KSI_HEAD; + if (td->td_dbgksi.ksi_signo !=3D 0) { + td->td_dbgksi.ksi_flags |=3D KSI_HEAD; if (sigqueue_add(&td->td_sigqueue, sig, - &ksi) !=3D 0) - ksi.ksi_signo =3D 0; + &td->td_dbgksi) !=3D 0) + td->td_dbgksi.ksi_signo =3D 0; } - if (ksi.ksi_signo =3D=3D 0) + if (td->td_dbgksi.ksi_signo =3D=3D 0) sigqueue_add(&td->td_sigqueue, sig, NULL); } diff --git a/sys/kern/sys_process.c b/sys/kern/sys_process.c index 40c861b..525c0e2 100644 --- a/sys/kern/sys_process.c +++ b/sys/kern/sys_process.c @@ -64,6 +64,7 @@ __FBSDID("$FreeBSD$"); =20 #ifdef COMPAT_FREEBSD32 #include +#include =20 struct ptrace_io_desc32 { int piod_op; @@ -85,6 +86,15 @@ struct ptrace_vm_entry32 { uint32_t pve_path; }; =20 +struct ptrace_lwpinfo32 { + lwpid_t pl_lwpid; /* LWP described. */ + int pl_event; /* Event that stopped the LWP. */ + int pl_flags; /* LWP flags. */ + sigset_t pl_sigmask; /* LWP signal mask */ + sigset_t pl_siglist; /* LWP pending signal */ + struct siginfo32 pl_siginfo; /* siginfo for signal */ +}; + #endif =20 /* @@ -498,6 +508,19 @@ ptrace_vm_entry32(struct thread *td, struct proc *p, pve32->pve_pathlen =3D pve.pve_pathlen; return (error); } + +static void +ptrace_lwpinfo_to32(const struct ptrace_lwpinfo *pl, + struct ptrace_lwpinfo32 *pl32) +{ + + pl32->pl_lwpid =3D pl->pl_lwpid; + pl32->pl_event =3D pl->pl_event; + pl32->pl_flags =3D pl->pl_flags; + pl32->pl_sigmask =3D pl->pl_sigmask; + pl32->pl_siglist =3D pl->pl_siglist; + siginfo_to_siginfo32(&pl->pl_siginfo, &pl32->pl_siginfo); +} #endif /* COMPAT_FREEBSD32 */ =20 /* @@ -552,6 +575,7 @@ ptrace(struct thread *td, struct ptrace_args *uap) struct fpreg32 fpreg32; struct reg32 reg32; struct ptrace_io_desc32 piod32; + struct ptrace_lwpinfo32 pl32; struct ptrace_vm_entry32 pve32; #endif } r; @@ -662,6 +686,8 @@ kern_ptrace(struct thread *td, int req, pid_t pid, void= *addr, int data) #ifdef COMPAT_FREEBSD32 int wrap32 =3D 0, safe =3D 0; struct ptrace_io_desc32 *piod32 =3D NULL; + struct ptrace_lwpinfo32 *pl32 =3D NULL; + struct ptrace_lwpinfo plr; #endif =20 curp =3D td->td_proc; @@ -1103,15 +1129,44 @@ kern_ptrace(struct thread *td, int req, pid_t pid, = void *addr, int data) break; =20 case PT_LWPINFO: - if (data <=3D 0 || data > sizeof(*pl)) { + if (data <=3D 0 || +#ifdef COMPAT_FREEBSD32 + (!wrap32 && data > sizeof(*pl)) || + (wrap32 && data > sizeof(*pl32))) { +#else + data > sizeof(*pl)) { +#endif error =3D EINVAL; break; } +#ifdef COMPAT_FREEBSD32 + if (wrap32) { + pl =3D &plr; + pl32 =3D addr; + } else +#endif pl =3D addr; pl->pl_lwpid =3D td2->td_tid; - if (td2->td_dbgflags & TDB_XSIG) - pl->pl_event =3D PL_EVENT_SIGNAL; pl->pl_flags =3D 0; + if (td2->td_dbgflags & TDB_XSIG) { + pl->pl_event =3D PL_EVENT_SIGNAL; + if (td2->td_dbgksi.ksi_signo !=3D 0 && +#ifdef COMPAT_FREEBSD32 + ((!wrap32 && data >=3D offsetof(struct ptrace_lwpinfo, + pl_siginfo) + sizeof(pl->pl_siginfo)) || + (wrap32 && data >=3D offsetof(struct ptrace_lwpinfo32, + pl_siginfo) + sizeof(struct siginfo32))) +#else + data >=3D offsetof(struct ptrace_lwpinfo, pl_siginfo) + + sizeof(pl->pl_siginfo) +#endif + ){ + pl->pl_flags |=3D PL_FLAG_SI; + pl->pl_siginfo =3D td2->td_dbgksi.ksi_info; + } + } + if ((pl->pl_flags & PL_FLAG_SI) =3D=3D 0) + bzero(&pl->pl_siginfo, sizeof(pl->pl_siginfo)); if (td2->td_dbgflags & TDB_SCE) pl->pl_flags |=3D PL_FLAG_SCE; else if (td2->td_dbgflags & TDB_SCX) @@ -1120,6 +1175,10 @@ kern_ptrace(struct thread *td, int req, pid_t pid, v= oid *addr, int data) pl->pl_flags |=3D PL_FLAG_EXEC; pl->pl_sigmask =3D td2->td_sigmask; pl->pl_siglist =3D td2->td_siglist; +#ifdef COMPAT_FREEBSD32 + if (wrap32) + ptrace_lwpinfo_to32(pl, pl32); +#endif break; =20 case PT_GETNUMLWPS: diff --git a/sys/sys/proc.h b/sys/sys/proc.h index 3c9a2de..cd00550 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -259,6 +259,7 @@ struct thread { char td_name[MAXCOMLEN + 1]; /* (*) Thread name. */ struct file *td_fpop; /* (k) file referencing cdev under op */ int td_dbgflags; /* (c) Userland debugger flags */ + struct ksiginfo td_dbgksi; /* (c) ksi reflected to debugger. */ int td_ng_outbound; /* (k) Thread entered ng from above. */ struct osd td_osd; /* (k) Object specific data. */ #define td_endzero td_base_pri diff --git a/sys/sys/ptrace.h b/sys/sys/ptrace.h index a6dbe2c..f4b25d4 100644 --- a/sys/sys/ptrace.h +++ b/sys/sys/ptrace.h @@ -33,7 +33,7 @@ #ifndef _SYS_PTRACE_H_ #define _SYS_PTRACE_H_ =20 -#include +#include #include =20 #define PT_TRACE_ME 0 /* child declares it's being traced */ @@ -102,8 +102,10 @@ struct ptrace_lwpinfo { #define PL_FLAG_SCE 0x04 /* syscall enter point */ #define PL_FLAG_SCX 0x08 /* syscall leave point */ #define PL_FLAG_EXEC 0x10 /* exec(2) succeeded */ +#define PL_FLAG_SI 0x20 /* siginfo is valid */ sigset_t pl_sigmask; /* LWP signal mask */ sigset_t pl_siglist; /* LWP pending signal */ + struct __siginfo pl_siginfo; /* siginfo for signal */ }; =20 /* Argument structure for PT_VM_ENTRY. */ --BVBPRygDtbGal1Jh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwt34MACgkQC3+MBN1Mb4joeACg7pW50dhj6VJydth3NzvYokkc 2AEAoMzQHDtP0Y0PdOIFhoGLFWdweaNa =1YSI -----END PGP SIGNATURE----- --BVBPRygDtbGal1Jh-- From owner-freebsd-arch@FreeBSD.ORG Sat Jul 3 02:28:05 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from alona.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 4761B106566C; Sat, 3 Jul 2010 02:28:01 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <4C2EA02A.70900@freebsd.org> Date: Sat, 03 Jul 2010 10:27:54 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.21 (X11/20090522) MIME-Version: 1.0 To: Kostik Belousov References: <20100701134217.GM13238@deviant.kiev.zoral.com.ua> <201007011705.26173.john@baldwin.cx> <20100701212710.GP13238@deviant.kiev.zoral.com.ua> <4C2D4B65.8080708@freebsd.org> <20100702124555.GR13238@deviant.kiev.zoral.com.ua> In-Reply-To: <20100702124555.GR13238@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John Baldwin , freebsd-arch@freebsd.org Subject: Re: Access to siginfo for the signal from debugger X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 02:28:05 -0000 Kostik Belousov wrote: > On Fri, Jul 02, 2010 at 10:13:57AM +0800, David Xu wrote: > >> Kostik Belousov wrote: >> >>> On Thu, Jul 01, 2010 at 05:05:26PM -0400, John Baldwin wrote: >>> >>>> On Thursday 01 July 2010 09:42:17 am Kostik Belousov wrote: >>>> >>>>> Hi, >>>>> below is the patch that provides the debugger with access to siginfo >>>>> of the signal that stopped the debuggee. This allows to see a lot more >>>>> details for the cause of the process stop. E.g. you can see a fault >>>>> address if process get SIGSEGV or SIGBUS, you can distinguish between >>>>> breakpoint-generated SIGTRAP and non-breakpoint, whether the signal >>>>> was send due to external event etc. >>>>> >>>>> The change to struct ptrace_lwpinfo is backward-compatible in the sense >>>>> that programs that were compiled with old definition for the struct will >>>>> work on new kernels. >>>>> >>>> Nice! Does gdb "just work" with these changes or does it need patching >>>> as well? >>>> >>> It should "just work", and my testing seems to confirm this. gdb uses >>> PT_LWPINFO to enumerate the thread ids, and I checked it on mt process. >>> >>> As I said, the change is ABI backward-compatible, i.e. you do not need >>> even to recompile the old program for new kernel. >>> >>> Sure, gdb cannot show additional available information without >>> modifications. >>> >> Yes, you can add new fields to ptrace_lwpinfo without any problem. >> To print new fields, you should change the function >> fbsd_thread_signal_cmd in file >> src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c >> after change, you just type 'thread signal' command in gdb to >> show thread's signal info. The command is freebsd specific, >> others may or may not have it. >> > > I did what you suggested. The drawback there is that "thread signal" > only works for the threaded processes. > I have tested it, it works fine. yes, it only works for threaded target. The only problem is strerror(0) returns 'Unknown error', this is a bit strange. --- Program received signal ?, Unknown signal. [Switching to Thread 800c07700 (LWP 100165)] 0x00000008008bd1ac in sigwaitinfo () from /lib/libc.so.7 (gdb) thread signal signal mask: hup int quit ill trap abrt emt fpe bus segv sys pipe alrm term urg tstp cont chl d ttin ttou io xcpu xfsz vtalrm prof winch info usr1 usr2 signal pending: si_signo 33 si_errno 0 (Unknown error: 0) si_code TIMER si_pid 0 si_uid 0 si_status 0 si_addr 0x0 (gdb) --- Thanks, From owner-freebsd-arch@FreeBSD.ORG Sat Jul 3 03:51:50 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFEA31065676 for ; Sat, 3 Jul 2010 03:51:50 +0000 (UTC) (envelope-from yanegomi@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 6243E8FC08 for ; Sat, 3 Jul 2010 03:51:50 +0000 (UTC) Received: by iwn35 with SMTP id 35so1956622iwn.13 for ; Fri, 02 Jul 2010 20:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=GMTuLf4cukpj6P69TlUmgWCBtEKuDXmZxlV5Bq+3uKU=; b=jU5UB0gQF9yQHALMv0O6cL5cjpOkKaz2KCUF/fQFNv+VPLOcubTRZqrCbpLpujVzqw K2Rx/wXZSabtOHvWIDrgsgeoH0PRdFrIJapxPQKJzDs/ckWq/jf6PLzdvT8fbfPolNAk OVD2dY7aMe6N47ED2/L6F5Mv89JurMlcb904w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.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=kGw1jHykPbjC3NNfEqnta6X7JUNbQveKFCF2CiSTQLs5md0b5xLqk1dICJTrnn98Ty c0w2pT8gQDqw50mDH2WNLqLC69WbmMwSH9W+R2fOdSvIq74MCTEkraNMKGMhv1ofwZPh hSga39XJWUG2JlITTLsm2UGo/gj5UmZQmKGRM= MIME-Version: 1.0 Received: by 10.231.33.76 with SMTP id g12mr1837520ibd.199.1278129109577; Fri, 02 Jul 2010 20:51:49 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.214.145 with HTTP; Fri, 2 Jul 2010 20:51:49 -0700 (PDT) In-Reply-To: <4C2EA02A.70900@freebsd.org> References: <20100701134217.GM13238@deviant.kiev.zoral.com.ua> <201007011705.26173.john@baldwin.cx> <20100701212710.GP13238@deviant.kiev.zoral.com.ua> <4C2D4B65.8080708@freebsd.org> <20100702124555.GR13238@deviant.kiev.zoral.com.ua> <4C2EA02A.70900@freebsd.org> Date: Fri, 2 Jul 2010 20:51:49 -0700 X-Google-Sender-Auth: dNNyMRP3N3aSFhqH42DIVB89OjU Message-ID: From: Garrett Cooper To: David Xu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , John Baldwin , freebsd-arch@freebsd.org Subject: Re: Access to siginfo for the signal from debugger X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 03:51:50 -0000 On Fri, Jul 2, 2010 at 7:27 PM, David Xu wrote: > Kostik Belousov wrote: >> >> On Fri, Jul 02, 2010 at 10:13:57AM +0800, David Xu wrote: >> >>> >>> Kostik Belousov wrote: >>> >>>> >>>> On Thu, Jul 01, 2010 at 05:05:26PM -0400, John Baldwin wrote: >>>> >>>>> >>>>> On Thursday 01 July 2010 09:42:17 am Kostik Belousov wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> below is the patch that provides the debugger with access to siginfo >>>>>> of the signal that stopped the debuggee. This allows to see a lot mo= re >>>>>> details for the cause of the process stop. E.g. you can see a fault >>>>>> address if process get SIGSEGV or SIGBUS, you can distinguish betwee= n >>>>>> breakpoint-generated SIGTRAP and non-breakpoint, whether the signal >>>>>> was send due to external event etc. >>>>>> >>>>>> The change to struct ptrace_lwpinfo is backward-compatible in the >>>>>> sense >>>>>> that programs that were compiled with old definition for the struct >>>>>> will >>>>>> work on new kernels. >>>>>> >>>>> >>>>> Nice! =A0Does gdb "just work" with these changes or does it need patc= hing >>>>> as well? >>>>> >>>> >>>> It should "just work", and my testing seems to confirm this. gdb uses >>>> PT_LWPINFO to enumerate the thread ids, and I checked it on mt process= . >>>> >>>> As I said, the change is ABI backward-compatible, i.e. you do not need >>>> even to recompile the old program for new kernel. >>>> >>>> Sure, gdb cannot show additional available information without >>>> modifications. >>>> >>> >>> Yes, you can add new fields to ptrace_lwpinfo without any problem. >>> To print new fields, you should change the function >>> fbsd_thread_signal_cmd in file >>> src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c >>> after change, you just type 'thread signal' command in gdb to >>> show thread's signal info. The command is freebsd specific, >>> others may or may not have it. >>> >> >> I did what you suggested. The drawback there is that "thread signal" >> only works for the threaded processes. >> > > I have tested it, it works fine. yes, it only works for threaded target. > The only problem is strerror(0) returns 'Unknown error', this is =A0a bit > strange. > > --- > Program received signal ?, Unknown signal. > [Switching to Thread 800c07700 (LWP 100165)] > 0x00000008008bd1ac in sigwaitinfo () from /lib/libc.so.7 > (gdb) thread signal > signal mask: > hup int quit ill trap abrt emt fpe bus segv sys pipe alrm term urg tstp c= ont > chl > d ttin ttou io xcpu xfsz vtalrm prof winch info usr1 usr2 > signal pending: > > si_signo 33 > si_errno 0 (Unknown error: 0) > si_code TIMER si_pid 0 si_uid 0 si_status 0 si_addr 0x0 > (gdb) strerror(EOK) is ok, if signal doesn't return SIG_ERR and sigaction doesn't return -1. -Garrett From owner-freebsd-arch@FreeBSD.ORG Sat Jul 3 07:15:26 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FA0E106566B; Sat, 3 Jul 2010 07:15:26 +0000 (UTC) (envelope-from yanegomi@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 309EA8FC0A; Sat, 3 Jul 2010 07:15:26 +0000 (UTC) Received: by gxk7 with SMTP id 7so2470324gxk.13 for ; Sat, 03 Jul 2010 00:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=GMTuLf4cukpj6P69TlUmgWCBtEKuDXmZxlV5Bq+3uKU=; b=jU5UB0gQF9yQHALMv0O6cL5cjpOkKaz2KCUF/fQFNv+VPLOcubTRZqrCbpLpujVzqw K2Rx/wXZSabtOHvWIDrgsgeoH0PRdFrIJapxPQKJzDs/ckWq/jf6PLzdvT8fbfPolNAk OVD2dY7aMe6N47ED2/L6F5Mv89JurMlcb904w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.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=kGw1jHykPbjC3NNfEqnta6X7JUNbQveKFCF2CiSTQLs5md0b5xLqk1dICJTrnn98Ty c0w2pT8gQDqw50mDH2WNLqLC69WbmMwSH9W+R2fOdSvIq74MCTEkraNMKGMhv1ofwZPh hSga39XJWUG2JlITTLsm2UGo/gj5UmZQmKGRM= MIME-Version: 1.0 Received: by 10.231.33.76 with SMTP id g12mr1837520ibd.199.1278129109577; Fri, 02 Jul 2010 20:51:49 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.214.145 with HTTP; Fri, 2 Jul 2010 20:51:49 -0700 (PDT) In-Reply-To: <4C2EA02A.70900@freebsd.org> References: <20100701134217.GM13238@deviant.kiev.zoral.com.ua> <201007011705.26173.john@baldwin.cx> <20100701212710.GP13238@deviant.kiev.zoral.com.ua> <4C2D4B65.8080708@freebsd.org> <20100702124555.GR13238@deviant.kiev.zoral.com.ua> <4C2EA02A.70900@freebsd.org> Date: Fri, 2 Jul 2010 20:51:49 -0700 X-Google-Sender-Auth: dNNyMRP3N3aSFhqH42DIVB89OjU Message-ID: From: Garrett Cooper To: David Xu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , John Baldwin , freebsd-arch@freebsd.org Subject: Re: Access to siginfo for the signal from debugger X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 07:15:26 -0000 On Fri, Jul 2, 2010 at 7:27 PM, David Xu wrote: > Kostik Belousov wrote: >> >> On Fri, Jul 02, 2010 at 10:13:57AM +0800, David Xu wrote: >> >>> >>> Kostik Belousov wrote: >>> >>>> >>>> On Thu, Jul 01, 2010 at 05:05:26PM -0400, John Baldwin wrote: >>>> >>>>> >>>>> On Thursday 01 July 2010 09:42:17 am Kostik Belousov wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> below is the patch that provides the debugger with access to siginfo >>>>>> of the signal that stopped the debuggee. This allows to see a lot mo= re >>>>>> details for the cause of the process stop. E.g. you can see a fault >>>>>> address if process get SIGSEGV or SIGBUS, you can distinguish betwee= n >>>>>> breakpoint-generated SIGTRAP and non-breakpoint, whether the signal >>>>>> was send due to external event etc. >>>>>> >>>>>> The change to struct ptrace_lwpinfo is backward-compatible in the >>>>>> sense >>>>>> that programs that were compiled with old definition for the struct >>>>>> will >>>>>> work on new kernels. >>>>>> >>>>> >>>>> Nice! =A0Does gdb "just work" with these changes or does it need patc= hing >>>>> as well? >>>>> >>>> >>>> It should "just work", and my testing seems to confirm this. gdb uses >>>> PT_LWPINFO to enumerate the thread ids, and I checked it on mt process= . >>>> >>>> As I said, the change is ABI backward-compatible, i.e. you do not need >>>> even to recompile the old program for new kernel. >>>> >>>> Sure, gdb cannot show additional available information without >>>> modifications. >>>> >>> >>> Yes, you can add new fields to ptrace_lwpinfo without any problem. >>> To print new fields, you should change the function >>> fbsd_thread_signal_cmd in file >>> src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c >>> after change, you just type 'thread signal' command in gdb to >>> show thread's signal info. The command is freebsd specific, >>> others may or may not have it. >>> >> >> I did what you suggested. The drawback there is that "thread signal" >> only works for the threaded processes. >> > > I have tested it, it works fine. yes, it only works for threaded target. > The only problem is strerror(0) returns 'Unknown error', this is =A0a bit > strange. > > --- > Program received signal ?, Unknown signal. > [Switching to Thread 800c07700 (LWP 100165)] > 0x00000008008bd1ac in sigwaitinfo () from /lib/libc.so.7 > (gdb) thread signal > signal mask: > hup int quit ill trap abrt emt fpe bus segv sys pipe alrm term urg tstp c= ont > chl > d ttin ttou io xcpu xfsz vtalrm prof winch info usr1 usr2 > signal pending: > > si_signo 33 > si_errno 0 (Unknown error: 0) > si_code TIMER si_pid 0 si_uid 0 si_status 0 si_addr 0x0 > (gdb) strerror(EOK) is ok, if signal doesn't return SIG_ERR and sigaction doesn't return -1. -Garrett From owner-freebsd-arch@FreeBSD.ORG Sat Jul 3 11:31:20 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D8D51065675; Sat, 3 Jul 2010 11:31:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 347718FC0C; Sat, 3 Jul 2010 11:31:19 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o63BVDa2018615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Jul 2010 14:31:13 +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 o63BVDPl028356; Sat, 3 Jul 2010 14:31:13 +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 o63BVDqd028355; Sat, 3 Jul 2010 14:31:13 +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:31:13 +0300 From: Kostik Belousov To: David Xu Message-ID: <20100703113113.GF13238@deviant.kiev.zoral.com.ua> References: <20100701134217.GM13238@deviant.kiev.zoral.com.ua> <201007011705.26173.john@baldwin.cx> <20100701212710.GP13238@deviant.kiev.zoral.com.ua> <4C2D4B65.8080708@freebsd.org> <20100702124555.GR13238@deviant.kiev.zoral.com.ua> <4C2EA02A.70900@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i0lx7FdJFH1KG+55" Content-Disposition: inline In-Reply-To: <4C2EA02A.70900@freebsd.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: John Baldwin , freebsd-arch@freebsd.org Subject: Re: Access to siginfo for the signal from debugger X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 11:31:20 -0000 --i0lx7FdJFH1KG+55 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 03, 2010 at 10:27:54AM +0800, David Xu wrote: > Kostik Belousov wrote: > >On Fri, Jul 02, 2010 at 10:13:57AM +0800, David Xu wrote: > > =20 > >>Kostik Belousov wrote: > >> =20 > >>>On Thu, Jul 01, 2010 at 05:05:26PM -0400, John Baldwin wrote: > >>> =20 > >>>>On Thursday 01 July 2010 09:42:17 am Kostik Belousov wrote: > >>>> =20 > >>>>>Hi, > >>>>>below is the patch that provides the debugger with access to siginfo > >>>>>of the signal that stopped the debuggee. This allows to see a lot mo= re > >>>>>details for the cause of the process stop. E.g. you can see a fault > >>>>>address if process get SIGSEGV or SIGBUS, you can distinguish between > >>>>>breakpoint-generated SIGTRAP and non-breakpoint, whether the signal > >>>>>was send due to external event etc. > >>>>> > >>>>>The change to struct ptrace_lwpinfo is backward-compatible in the se= nse > >>>>>that programs that were compiled with old definition for the struct= =20 > >>>>>will > >>>>>work on new kernels. > >>>>> =20 > >>>>Nice! Does gdb "just work" with these changes or does it need patchi= ng=20 > >>>>as well? > >>>> =20 > >>>It should "just work", and my testing seems to confirm this. gdb uses > >>>PT_LWPINFO to enumerate the thread ids, and I checked it on mt process. > >>> > >>>As I said, the change is ABI backward-compatible, i.e. you do not need > >>>even to recompile the old program for new kernel. > >>> > >>>Sure, gdb cannot show additional available information without > >>>modifications. > >>> =20 > >>Yes, you can add new fields to ptrace_lwpinfo without any problem. > >>To print new fields, you should change the function > >>fbsd_thread_signal_cmd in file > >>src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c > >>after change, you just type 'thread signal' command in gdb to > >>show thread's signal info. The command is freebsd specific, > >>others may or may not have it. > >> =20 > > > >I did what you suggested. The drawback there is that "thread signal" > >only works for the threaded processes. > > =20 >=20 > I have tested it, it works fine. yes, it only works for threaded target. > The only problem is strerror(0) returns 'Unknown error', this is a bit > strange. >=20 > --- > Program received signal ?, Unknown signal. > [Switching to Thread 800c07700 (LWP 100165)] > 0x00000008008bd1ac in sigwaitinfo () from /lib/libc.so.7 > (gdb) thread signal > signal mask: > hup int quit ill trap abrt emt fpe bus segv sys pipe alrm term urg tstp= =20 > cont chl > d ttin ttou io xcpu xfsz vtalrm prof winch info usr1 usr2 > signal pending: >=20 > si_signo 33 > si_errno 0 (Unknown error: 0) > si_code TIMER si_pid 0 si_uid 0 si_status 0 si_addr 0x0 > (gdb) > --- Thank you. The strerror(0) behaviour seems to be introduced in r108044: strerror()'s semantics have changed slightly such that an argument of 0 is now considered invalid and errno is set to EINVAL. We indeed do not have defined symbol for errno value of 0, I might just special-case the 0 in si_errno for aestetic purpose. Another small nit in the patch is that I do not fetch siginfo for the signal delivered to system-scoped kse thread, but I think that this is acceptable. I am going to commit this, with the modification mentioned above. --i0lx7FdJFH1KG+55 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwvH4EACgkQC3+MBN1Mb4gn3gCg5sytrvcWL+MQy3r+UDKASk3b qr8AoLp5A8HGbd1lpHVRCnBZYa8vbemp =hbHS -----END PGP SIGNATURE----- --i0lx7FdJFH1KG+55--