From owner-freebsd-ia64 Mon Nov 11 4:37:34 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8160937B401 for ; Mon, 11 Nov 2002 04:37:30 -0800 (PST) Received: from bored.com (lb.bannerservers.com [209.61.181.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7543943E77 for ; Mon, 11 Nov 2002 04:37:29 -0800 (PST) (envelope-from vdhjupedrt@opus.com.br) Received: from smtp.prv.pl ([4.64.63.190]) by bored.com ; Mon, 11 Nov 2002 06:36:24 -0600 Message-ID: <000025711249$00000ef3$00005a65@mail.autoedu.co.kr> To: Cc: , , , , , , , , , , , , , , , , From: "Dick Wetz" Subject: Opting6235 Date: Mon, 11 Nov 2002 04:36:13 -2000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Frustrated With Your Internet Marketing Efforts? Have you tried: FREE Classifieds? (Don't work) Web Site? (Good for closing but you have to have visitors) Banners? (Expensive and Iffy) E-Zine? (They're great, but only with thousands of members) Search Engines (Easy to be buried with thousands of others) E -MAIL MARKETING IS THE ANSWER! It is a proven fact that your best chance of attracting new business is through Direct E-mail. The secret to an effective bulk E-mail marketing campaign on the internet is directly related to the freshness of the lists used. To ensure that our customers receive the freshest mailing addresses, we are constantly updating and revising our mailing lists. Our Sixth release provides you with 15 MILLION E-mail Addresses taken from our own database of opporunity seekers and businesses. THE MASTER MARKETERS CD VOL. 6 consists of 15 Million E-mail addresses that were cleaned and verified. You can start mailing these addresses immediately. We have removed all the following domains: THESE DOMAINS ARE ABSOLUTELY NOT INCLUDED: Compuserve.com Genie.com Delphi.com MCI.com And all domains ending with .edu, .mil, .org, and .us. There are no International domains in this CD. All addresses are pure .COM AND .NET. There are ABSOLUTELY NO DUPICATE ADDRESSES! Our CD does not contain any of those bogus and filled addresses used by other companies to ad inflated numbers to their lists. We pay full time employees to perform hundreds of hours of list verification and deduping of our lists. REMEMBER, our business is mailing for individuals and companies. We mail over 20 million direct E-mails per Day for our clients and the addresses contained in the Master Marketers Cd are the same fresh, clean lists we use. We maintain a huge database of anti-commerce radicals who want the net for themselves. We run our lists against this database and remove all E-mail addresses these radicals use to trap you into mailing to them so they can cause you trouble. Over 30,000 BUSINESSES come on the Internet EVERY single day...If you don't send out Broadcast Email... YOUR COMPETITON WILL! SPECIAL BONUS OFFER! For those who order The Address CD Vol. 6 before 11/30/02 we are going to include our Professional Email Marketing Book. This Book Explains Exactly how Bulk Email operates. The author, Paul Willis has 8 years of Bulk Email Advertising experience and operates a very successful Internet Email Advertising Company. If you have any questions or would like to discuss how we can help you to effectively market your business via Direct E-mail advertising please call 818-743-7507. We offer several affordable Marketing packages for those who need their E-mail ads sent through our servers. We accept payment by Check - Visa - Mastercard - Discover. TO ORDER our CD, simply print out the EZ ORDER FORM below and fax your Check or Credit Card Information to our office today. Fax to: 661-244-4903. Or Call 818-743-7507 to order by phone. E-Z ORDER FORM ______ Yes! I would like to order MASTER MARKETING CD with 15 MILLION Email addresses for $229.00. *Price includes shipping and handling with the U.S. DATE___________ NAME_____________________________________________________ Name and address must match credit card. COMPANY NAME_____________________________________________ ADDRESS__________________________________________________ CITY, STATE, ZIP_________________________________________ PHONE NUMBERS____________________________________________ FAX NUMBERS______________________________________________ EMAIL ADDRESS____________________________________________ Must have a valid e-mail address for credit card orders. You will receive receipt of credit card charges by e-mail. CHECKS BY FAX SERVICES! 24 HOUR FAX SERVICES If you would like to fax a check, paste your check below and fax it to: 661-244-4903. You do not have to mail the original check we will simply make a draft from the copy you fax. Make all checks payable to P.W. MARKETING LLC ****************************************************** Paste or Tape your check here and fax along with this order form to 661-244-4903 ****************************************************** If you fax a check, there is no need for you to send the original. To be talem off our mailing list please click on the link below that will send us a email and we will permanently remove you from our mailing list. MailTo:ksnnj@yahoo.com?subject=take-out To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Mon Nov 11 11: 7:11 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7B4137B401 for ; Mon, 11 Nov 2002 11:07:10 -0800 (PST) Received: from kayak.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FA5C43E6E for ; Mon, 11 Nov 2002 11:07:06 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from kayak.xcllnt.net (localhost [127.0.0.1]) by kayak.xcllnt.net (8.12.6/8.12.6) with ESMTP id gABJ700N022138 for ; Mon, 11 Nov 2002 11:07:00 -0800 (PST) (envelope-from marcel@kayak.xcllnt.net) Received: (from marcel@localhost) by kayak.xcllnt.net (8.12.6/8.12.6/Submit) id gABJ70Dw022137 for ia64@FreeBSD.org; Mon, 11 Nov 2002 11:07:00 -0800 (PST) Date: Mon, 11 Nov 2002 11:07:00 -0800 From: Marcel Moolenaar To: ia64@FreeBSD.org Subject: HEADS UP: ABI change Message-ID: <20021111110700.A22124@kayak.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22.1i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Gang, Yesterday I changed the way the setjmp functions handle alignment of the jmp_buf. In short: they don't do that anymore. The jmp_buf is now defined to be aligned on a 16-byte boundary at compile time. No runtime enforcement is being done now. Overall, the effect of the change is that programs compiled before this change could pass a jmp_buf to the setjmp functions that is not properly aligned. This will cause a sig10. The fix is to recompile the program in question (or any shared libaries it uses). BTW: I can't remember seeing the commit log being sent out, but that's probablyjust me. In any case: FYI, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Nov 12 3:17:43 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 236AA37B4C1; Tue, 12 Nov 2002 03:17:27 -0800 (PST) Received: from mail4.caramail.com (mail4.caramail.com [213.193.13.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9619743E75; Tue, 12 Nov 2002 03:17:26 -0800 (PST) (envelope-from kseseko@caramail.com) Received: from caramail.com (www14.caramail.com [213.193.13.24]) by mail4.caramail.com (Postfix) with SMTP id 2B88B154F1; Tue, 12 Nov 2002 11:41:38 +0100 (MET) From: kseseko seko To: kseseko@caramail.com Message-ID: <1037097359002000@caramail.com> X-Mailer: Caramail - www.caramail.com X-Originating-IP: [216.139.169.154] Mime-Version: 1.0 Subject: Greetings Date: Tue, 12 Nov 2002 11:35:59 GMT+1 Content-Type: multipart/mixed; boundary="=_NextPart_Caramail_0020001037097359_ID" Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Caramail_0020001037097359_ID Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: Kuzo M. Seseko Alternative Email Address: suun4us@yahoo.com My name is Kuzo Mobutu Seseko, the daughter of the late President of Republic of Zaire, now living in exile in South Africa. The circumstances that led to my living in South Africa at the moment cannot be new to you , I know you must know the history of my family. However , during the days of my father=92s reign we were into solid minerals exploration and mining which was the soul base of our family business, mostly diamond and gold. But unfortunately, before my father passed on, he was on exile in Europe which made it impossible for us to organize our businesses especially mining before the political hostility which saw him out of office began. Last year a security company in our country wrote me informing me of a deposit made by my father in my name which is still with them. I intended leaving the deposit with them sequel to my return home so that I can fall on that to start up a business ,but unfortunately, the rebel hostilities at home which have refused to stop up till this moment has made me to think otherwise. Hence I am considering asking the security company to transfer the sum to an oversea country with a stable economy and favorable political condition, so that I can find an indigenous business man / investor in that country to work with in partnership and invest this money. I know your country is an advanced democracy with a more stable economy than that of African countries. Hence I would want us to seek how to invest this sum agreeing on a working percentage.However due to my living status here in South Africa I would want you to keep this offer confidential. Get back to me suggesting what we are to do, while I will furnish you with my contact telephone numbers and fax in South Africa and that of my lawyers. I wish you strength. K. Seseko. _________________________________________________________ Gagne une PS2 ! Envoie un SMS avec le code PS au 61166 (0,35€ Hors co=FBt du SMS) --=_NextPart_Caramail_0020001037097359_ID-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Wed Nov 13 11:10:38 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54B1837B401; Wed, 13 Nov 2002 11:10:36 -0800 (PST) Received: from net2.gendyn.com (gate2.gendyn.com [204.60.171.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C0C343E4A; Wed, 13 Nov 2002 11:10:34 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from [153.11.11.3] (helo=ebnext01) by net2.gendyn.com with esmtp (Exim 2.12 #1) id 18C2u8-0001Mg-00; Wed, 13 Nov 2002 14:10:24 -0500 Received: from clcrtr.gdeb.com ([153.11.109.11]) by ebnext01 with SMTP id gADJANLQ030462; Wed, 13 Nov 2002 14:10:23 -0500 Received: from vigrid.com (gpz.clc.gdeb.com [192.168.3.12]) by clcrtr.gdeb.com (8.11.4/8.11.4) with ESMTP id gACLhLl39632; Tue, 12 Nov 2002 16:43:23 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <3DD2A3AD.D6ECFD0@vigrid.com> Date: Wed, 13 Nov 2002 14:10:37 -0500 From: Daniel Eischen X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: alpha@FreeBSD.org Cc: sparc@FreeBSD.org Subject: [PATCH] *context() as syscalls Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've got a patch that makes {get,set,swap}context() system calls, removing them from libc. I've built and tested an i386 kernel, but can only build an alpha kernel (a buildworld is in progress now). Can someone test an alpha kernel with this patch? For sparc, ia64, and powerpc, I just returned ENOSYS for now. It shouldn't break any builds and can be implemented later. Thanks, -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Wed Nov 13 11:13:18 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2260E37B401; Wed, 13 Nov 2002 11:13:16 -0800 (PST) Received: from net2.gendyn.com (gate2.gendyn.com [204.60.171.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5123F43E4A; Wed, 13 Nov 2002 11:13:14 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from [153.11.11.3] (helo=ebnext01) by net2.gendyn.com with esmtp (Exim 2.12 #1) id 18C2wj-0001hz-00; Wed, 13 Nov 2002 14:13:05 -0500 Received: from clcrtr.gdeb.com ([153.11.109.11]) by ebnext01 with SMTP id gADJD4LQ029432; Wed, 13 Nov 2002 14:13:04 -0500 Received: from vigrid.com (gpz.clc.gdeb.com [192.168.3.12]) by clcrtr.gdeb.com (8.11.4/8.11.4) with ESMTP id gACLk4l39640; Tue, 12 Nov 2002 16:46:04 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <3DD2A44F.95F9DD30@vigrid.com> Date: Wed, 13 Nov 2002 14:13:19 -0500 From: Daniel Eischen X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: alpha@FreeBSD.org Cc: sparc@FreeBSD.org Subject: [PATCH] *context() as syscalls Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Oops, forgot to include URL. http://people.freebsd.org/~deischen/uc-sys.diffs > I've got a patch that makes {get,set,swap}context() system calls, > removing them from libc. I've built and tested an i386 kernel, > but can only build an alpha kernel (a buildworld is in progress > now). > > Can someone test an alpha kernel with this patch? > > For sparc, ia64, and powerpc, I just returned ENOSYS for now. > It shouldn't break any builds and can be implemented later. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Wed Nov 13 13:13:50 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4507737B401 for ; Wed, 13 Nov 2002 13:13:47 -0800 (PST) Received: from lsanca2-ar24-4-62-185-211.lsanca2.dsl-verizon.net (lsanca2-ar24-4-62-185-211.lsanca2.dsl-verizon.net [4.62.185.211]) by mx1.FreeBSD.org (Postfix) with SMTP id 84B5543E6E for ; Wed, 13 Nov 2002 13:13:44 -0800 (PST) (envelope-from adrcdir@delphi.com) Received: from hotmail.com (compuserve.com [56.164.239.189]) by compuserve.com (8.11.6/8.11.6) with ESMTP id 17914 for ; Wed, 13 Nov 2002 21:13:53 +0000 From: "gottstein" To: "" Subject: Bullet proof bulk email friendly hosting & cheap mass email campaigns. X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: The Bat! (v1.60c) Personal Date: Wed, 13 Nov 2002 21:13:53 +0000 Message-ID: <179734769ld97Ciuhhevg1ruj@mailexcite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org We are the marketing specialists www.host4bulk.com that provide cheap bullet proof bulk email friendly hosting for your website ($400 for one month of bullet proof hosting) and cheap bulk email campaigns ($200 for 1 million emails sent) As you may already know, many web hosting companies have Terms of Service (TOS) or Acceptable Use Policies (AUP) against the delivery of emails advertising or promoting your web site. If your web site host receives complaints or discovers that your web site has been advertised in email broadcasts, they may disconnect your account and shut down your web site. Our mission is to solve your problem and provide you with bulk email friendly hosting. You don't have to worry about your website being closed again. Adult and gambling sites welcomed. No set up fee. You may advertise your website by using your own resources or using 3rd party's service. However we can do all the advertising for your business. You just sit, relax and see how your income grows constantly. We guarantee the lowest prices on the web for our web hosting and bulk email campaigns. We only ask $200 us dollars for 1 million emails sent with your ad. We don't use duplicate emails. Our email base is up to date and it is updated weekly. Our current email data base contains over 50.000.000 emails sorted by various parameters to meet your specific needs. No competitors may offer this price. The lowest price you can find on the net is well over $500 for 1 million Don't make the mistake of bulk emailing directly to your website without bulletproof web hosting. Your web host will close your account and shut your site down in no time! No matter how long you have been with them, how much you are paying them, or how beautiful your site is. There are companies charging thousands for bulletproof web hosting and they can't keep you up and running like we can. If you host with us, your site will NOT BE SHUT DOWN due to complaints! Bulk email campaign together with bullet proof hosting will bring your business to success. Just imagine how many people will learn about your business or product at a really low price. Bulk email is considered to be the most effective way to advertise on the net. It is hundreds times effective than banner, solo ad and other campaigns. Once people use our service they always come back for more. We can always provide websites that use bulk email campaigns with our new reliable way to accept credit cards on the net without the need to open merchant account. You can start accepting credit card payments in second. It is totally free. Visit our website at http://www.host4bulk.com for more information and to order your bulk email hosting or/and email campaign. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Thu Nov 14 14:38:13 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E17E437B401 for ; Thu, 14 Nov 2002 14:38:11 -0800 (PST) Received: from kayak.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 981C543E75 for ; Thu, 14 Nov 2002 14:38:10 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from kayak.xcllnt.net (localhost [127.0.0.1]) by kayak.xcllnt.net (8.12.6/8.12.6) with ESMTP id gAEMcA0N031735; Thu, 14 Nov 2002 14:38:10 -0800 (PST) (envelope-from marcel@kayak.xcllnt.net) Received: (from marcel@localhost) by kayak.xcllnt.net (8.12.6/8.12.6/Submit) id gAEMc9gK031734; Thu, 14 Nov 2002 14:38:09 -0800 (PST) Date: Thu, 14 Nov 2002 14:38:09 -0800 From: Marcel Moolenaar To: Doug Rabson Cc: ia64@FreeBSD.org Subject: setjmp/longjmp and libc_r [was: Re: cvs commit: src/lib/libc/ia64/gen _setjmp.S] Message-ID: <20021114143809.A31710@kayak.xcllnt.net> References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <1037298535.19149.8.camel@builder02.qubesoft.com> <20021114194057.GA856@dhcp01.pn.xcllnt.net> <200211141951.41202.dfr@nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211141951.41202.dfr@nlsystems.com> User-Agent: Mutt/1.3.22.1i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [moved to ia64@] On Thu, Nov 14, 2002 at 07:51:41PM +0000, Doug Rabson wrote: > > > > All you really need to achieve is that ar.bsp equals ar.bspstore > > > > before you set ar.bspstore, right? > > > > (note that the loadrs is missing a cover or an alloc) > > > > > > You would need a flushrs if you really wanted to use longjmp for > > > thread switching, otherwise you would lose the stacked registers of > > > the thread you were switching away from. > > > > But you need a setjmp to save that context, right? How would you > > otherwise return to the thread? > > I've managed to reload my memory from magtape :-). To use setjmp/longjmp > for thread switching, you would need to call flushrs from setjmp. That > would simplify longjmp at the cost of severely pessimising setjmp. This is exactly what we now have and what I'm willing to sacrificy at this time. It's easy enough to optimize setjmp/longjmp once we have the *context stuff. Note that I'm still not convinced that not doing a flushrs in setjmp will work when a signal handler on the alternate stack jumps to the saved context on the regular stack. You cannot compare the saved ar.bsp or ar.bspstore with the current ar.bspstore without taking into account that they may not be on the same register stack. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Thu Nov 14 18:35:52 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14AA637B401 for ; Thu, 14 Nov 2002 18:35:52 -0800 (PST) Received: from yahoo.samart.co.th (tidkeaw.samart.co.th [203.149.0.14]) by mx1.FreeBSD.org (Postfix) with SMTP id 3519443E42 for ; Thu, 14 Nov 2002 18:35:51 -0800 (PST) (envelope-from iddi@hotmail.com) Received: (qmail 19944 invoked from network); 15 Nov 2002 02:43:52 -0000 Received: from unknown (HELO ardency.samart.co.th) ([10.0.0.11]) (envelope-sender ) by 10.0.0.22 (qmail-ldap-1.03) with SMTP for ; 15 Nov 2002 02:43:52 -0000 Received: (qmail 16975 invoked from network); 15 Nov 2002 02:45:00 -0000 Received: from unknown (HELO yahoo.samart.co.th) ([203.149.32.130]) (envelope-sender ) by yahoo.samart.co.th (qmail-ldap-1.03) with SMTP for ; 15 Nov 2002 02:45:00 -0000 Message-Id: <1037327742.963@samart.co.th> Date: Fri, 15 Nov 2002 09:35:42 0700 To: freebsd-ia64@FreeBSD.org From: "getrich" Subject: มีของดีมาบอก.... MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Part-Time Job!! สำหรับนักเรียน นักศึกษา และผู้ทำงานประจำ คุณต้องการงานแบบนี้บ้างไหม…?? -งาน parttime ทำงานที่บ้านได้ ถ้าคุณใช้ Internet เป็น -ทำงานเพียงวันละ 2-3 ชม. -รายได้ 5,000 – 15,000 บาท ถ้าคุณเป็นคนหนึ่งที่ทำงานประจำหรือยังไม่มีงานทำ นักศึกษาที่กำลังศึกษาอยู่ ผู้ว่างงาน หรือผู้ที่ยังพอมีเวลาว่างจากงานประจำ มีคุณสมบัติเบื้องต้นดังนี้ 1. มีทัศนคติที่ดี 2. พร้อมที่จะเรียนรู้ เนื่องจากเป็นระบบใหม่จึงต้องให้มีการอบรมให้ตามความเหมาะสม 3. ต้องการที่จะทำงานอย่างจริงจัง อยากที่จะเปลี่ยนฐานะทางการเงินของตนเอง และอยากมีรายได้จากการทำงานตรงนี้จริงๆ ทุกอย่างเป็นไปได้ ใน สนใจรับข้อมูลเพิ่มเติมฟรี ได้ที่ http://ejobthailand.net/getrich อย่า !…………….. เป็นแค่เพียงคนที่นั่งรอโอกาส To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Fri Nov 15 1: 9:40 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 042A637B401 for ; Fri, 15 Nov 2002 01:09:38 -0800 (PST) Received: from herring.nlsystems.com (mailgate.nlsystems.com [62.49.251.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7436243E42 for ; Fri, 15 Nov 2002 01:09:36 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring [10.0.0.2]) by herring.nlsystems.com (8.12.6/8.12.6) with ESMTP id gAF99WDP091140; Fri, 15 Nov 2002 09:09:33 GMT (envelope-from dfr@nlsystems.com) Content-Type: text/plain; charset="iso-8859-1" From: Doug Rabson To: Marcel Moolenaar Subject: Re: setjmp/longjmp and libc_r [was: Re: cvs commit: src/lib/libc/ia64/gen _setjmp.S] Date: Fri, 15 Nov 2002 09:09:32 +0000 User-Agent: KMail/1.4.3 Cc: ia64@FreeBSD.ORG References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <200211141951.41202.dfr@nlsystems.com> <20021114143809.A31710@kayak.xcllnt.net> In-Reply-To: <20021114143809.A31710@kayak.xcllnt.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200211150909.32267.dfr@nlsystems.com> X-Spam-Status: No, hits=-8.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_KMAIL version=2.41 Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thursday 14 November 2002 10:38 pm, Marcel Moolenaar wrote: > [moved to ia64@] > > On Thu, Nov 14, 2002 at 07:51:41PM +0000, Doug Rabson wrote: > > > > > All you really need to achieve is that ar.bsp equals > > > > > ar.bspstore before you set ar.bspstore, right? > > > > > (note that the loadrs is missing a cover or an alloc) > > > > > > > > You would need a flushrs if you really wanted to use longjmp > > > > for thread switching, otherwise you would lose the stacked > > > > registers of the thread you were switching away from. > > > > > > But you need a setjmp to save that context, right? How would you > > > otherwise return to the thread? > > > > I've managed to reload my memory from magtape :-). To use > > setjmp/longjmp for thread switching, you would need to call flushrs > > from setjmp. That would simplify longjmp at the cost of severely > > pessimising setjmp. > > This is exactly what we now have and what I'm willing to sacrificy at > this time. It's easy enough to optimize setjmp/longjmp once we have > the *context stuff. This is totally wrong. Typical programs use setjmp for marking locations=20 for error recovery and they call setjmp many more times than longjmp.=20 Forcing the register stack to be flushed on setjmp is broken. The old=20 code worked well for this normal case. I completely disagree that its a=20 good idea to seriously pessimise the performance for most users just to=20 add support for a feature that setjmp was never designed for. > > Note that I'm still not convinced that not doing a flushrs in setjmp > will work when a signal handler on the alternate stack jumps to the > saved context on the regular stack. You cannot compare the saved > ar.bsp or ar.bspstore with the current ar.bspstore without taking > into account that they may not be on the same register stack. The signal trampoline performs the flushrs when it switches stacks. This=20 means that the register backing store will contain correct values for=20 both execution paths in longjmp. It doesn't actually matter whether=20 longjmp flushes in this case (i.e. both paths end up with the same=20 correct result). The only real problem with this case is finding the=20 right value for ar.rnat. That register should go into the jmp_buf and=20 the flushrs should be removed. The code in longjmp would then look=20 something like this: =09mov=09r17=3Dar.bspstore =09;; =09cmp.ltu=09p6,p7=3Dr17,r16=09=09// r16=3Dsaved ar.bsp (p6)=09flushrs=09=09=09=09// flush setjmp's dirty regs (p7)=09loadrs=09=09=09=09// setjmp's regs are clean This way would work correctly (and would perform well) for all normal=20 users of setjmp/longjmp. For libc_r with the code written this way, you can probably still do=20 thread switching without swapcontext(2) by adding an explicit flushrs=20 before the call to setjmp(3). It would be less effort to write the=20 support for userland or kernel swapcontext though. --=20 Doug Rabson=09=09=09=09Mail: dfr@nlsystems.com =09=09=09=09=09Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Fri Nov 15 1:16: 7 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97B0937B401 for ; Fri, 15 Nov 2002 01:16:04 -0800 (PST) Received: from herring.nlsystems.com (mailgate.nlsystems.com [62.49.251.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0AD443E77 for ; Fri, 15 Nov 2002 01:16:03 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring [10.0.0.2]) by herring.nlsystems.com (8.12.6/8.12.6) with ESMTP id gAF9G0DP091204; Fri, 15 Nov 2002 09:16:01 GMT (envelope-from dfr@nlsystems.com) Content-Type: text/plain; charset="iso-8859-1" From: Doug Rabson To: Marcel Moolenaar Subject: Re: setjmp/longjmp and libc_r [was: Re: cvs commit: src/lib/libc/ia64/gen _setjmp.S] Date: Fri, 15 Nov 2002 09:16:00 +0000 User-Agent: KMail/1.4.3 Cc: ia64@FreeBSD.ORG References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <20021114143809.A31710@kayak.xcllnt.net> <200211150909.32267.dfr@nlsystems.com> In-Reply-To: <200211150909.32267.dfr@nlsystems.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200211150916.00805.dfr@nlsystems.com> X-Spam-Status: No, hits=-6.4 required=5.0 tests=IN_REP_TO,MIME_LONG_LINE_QP,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_KMAIL version=2.41 Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Friday 15 November 2002 9:09 am, Doug Rabson wrote: > On Thursday 14 November 2002 10:38 pm, Marcel Moolenaar wrote: > > [moved to ia64@] > > > > On Thu, Nov 14, 2002 at 07:51:41PM +0000, Doug Rabson wrote: > > > > > > All you really need to achieve is that ar.bsp equals > > > > > > ar.bspstore before you set ar.bspstore, right? > > > > > > (note that the loadrs is missing a cover or an alloc) > > > > > > > > > > You would need a flushrs if you really wanted to use longjmp > > > > > for thread switching, otherwise you would lose the stacked > > > > > registers of the thread you were switching away from. > > > > > > > > But you need a setjmp to save that context, right? How would > > > > you otherwise return to the thread? > > > > > > I've managed to reload my memory from magtape :-). To use > > > setjmp/longjmp for thread switching, you would need to call > > > flushrs from setjmp. That would simplify longjmp at the cost of > > > severely pessimising setjmp. > > > > This is exactly what we now have and what I'm willing to sacrificy > > at this time. It's easy enough to optimize setjmp/longjmp once we > > have the *context stuff. > > This is totally wrong. Typical programs use setjmp for marking > locations for error recovery and they call setjmp many more times > than longjmp. Forcing the register stack to be flushed on setjmp is > broken. The old code worked well for this normal case. I completely > disagree that its a good idea to seriously pessimise the performance > for most users just to add support for a feature that setjmp was > never designed for. > > > Note that I'm still not convinced that not doing a flushrs in > > setjmp will work when a signal handler on the alternate stack jumps > > to the saved context on the regular stack. You cannot compare the > > saved ar.bsp or ar.bspstore with the current ar.bspstore without > > taking into account that they may not be on the same register > > stack. > > The signal trampoline performs the flushrs when it switches stacks. > This means that the register backing store will contain correct > values for both execution paths in longjmp. It doesn't actually > matter whether longjmp flushes in this case (i.e. both paths end up > with the same correct result). The only real problem with this case > is finding the right value for ar.rnat. That register should go into > the jmp_buf and the flushrs should be removed. The code in longjmp > would then look something like this: > > =09mov=09r17=3Dar.bspstore > =09;; > =09cmp.ltu=09p6,p7=3Dr17,r16=09=09// r16=3Dsaved ar.bsp > (p6)=09flushrs=09=09=09=09// flush setjmp's dirty regs > (p7)=09loadrs=09=09=09=09// setjmp's regs are clean > > This way would work correctly (and would perform well) for all normal > users of setjmp/longjmp. > > For libc_r with the code written this way, you can probably still do > thread switching without swapcontext(2) by adding an explicit flushrs > before the call to setjmp(3). It would be less effort to write the > support for userland or kernel swapcontext though. Following up with an (untested) patch: Index: _setjmp.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/lib/libc/ia64/gen/_setjmp.S,v retrieving revision 1.8 diff -u -r1.8 _setjmp.S --- _setjmp.S=0914 Nov 2002 06:40:23 -0000=091.8 +++ _setjmp.S=0915 Nov 2002 09:14:30 -0000 @@ -76,7 +76,6 @@ // mov r2 =3D ar.bsp // save backing store pointer mov r3 =3D pr // save predicates - flushrs ;; // // save user Unat register @@ -212,13 +211,18 @@ ld8 r2 =3D [r11], J_LC-J_NATS // get unat for spilled regs mov r31 =3D r32 ;; - loadrs mov ar.unat =3D r2 cmp.eq p6,p0=3D0,r8=09=09=09// Return value 0? + mov r18 =3D ar.bspstore ;; ld8 r16 =3D [r10], J_PREDS-J_BSP // get backing store pointer ld8 r17 =3D [r17]=09=09=09// ar.rnat mov ar.pfs =3D r15 + ;; + cmp.ltu p6,p7 =3D r18, r16=09=09// is bspstore within dirty region + ;; +(p6) flushrs=09=09=09=09// if so, flush setjmp's dirty regs +(p7) loadrs=09=09=09=09// otherwise just invalidate ;; mov ar.bspstore =3D r16 (p6) add r8 =3D 1, r0 --=20 Doug Rabson=09=09=09=09Mail: dfr@nlsystems.com =09=09=09=09=09Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Fri Nov 15 9:43:38 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42F5537B401 for ; Fri, 15 Nov 2002 09:43:37 -0800 (PST) Received: from kayak.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB00A43E3B for ; Fri, 15 Nov 2002 09:43:35 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.12.6/8.12.6) with ESMTP id gAFHhU0N034073; Fri, 15 Nov 2002 09:43:30 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id gAFHhTRM004359; Fri, 15 Nov 2002 09:43:29 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id gAFHhTc3004358; Fri, 15 Nov 2002 09:43:29 -0800 (PST) (envelope-from marcel) Date: Fri, 15 Nov 2002 09:43:29 -0800 From: Marcel Moolenaar To: Doug Rabson Cc: ia64@FreeBSD.ORG Subject: Re: setjmp/longjmp and libc_r [was: Re: cvs commit: src/lib/libc/ia64/gen _setjmp.S] Message-ID: <20021115174328.GA4288@dhcp01.pn.xcllnt.net> References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <200211141951.41202.dfr@nlsystems.com> <20021114143809.A31710@kayak.xcllnt.net> <200211150909.32267.dfr@nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211150909.32267.dfr@nlsystems.com> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Nov 15, 2002 at 09:09:32AM +0000, Doug Rabson wrote: > > > > > > I've managed to reload my memory from magtape :-). To use > > > setjmp/longjmp for thread switching, you would need to call flushrs > > > from setjmp. That would simplify longjmp at the cost of severely > > > pessimising setjmp. > > > > This is exactly what we now have and what I'm willing to sacrificy at > > this time. It's easy enough to optimize setjmp/longjmp once we have > > the *context stuff. > > This is totally wrong. No, it's a step in different direction than you would have chosen. Pick your words with care. See also below. > > Note that I'm still not convinced that not doing a flushrs in setjmp > > will work when a signal handler on the alternate stack jumps to the > > saved context on the regular stack. You cannot compare the saved > > ar.bsp or ar.bspstore with the current ar.bspstore without taking > > into account that they may not be on the same register stack. > > The signal trampoline performs the flushrs when it switches stacks. Ah, I see. You avoid having the dirty registers on the kernel stack by doing an exception restore to the original stack, do a flushrs and then switch to the alternate stack. I wondered about this hoop-jumping... > For libc_r with the code written this way, you can probably still do > thread switching without swapcontext(2) by adding an explicit flushrs > before the call to setjmp(3). It would be less effort to write the > support for userland or kernel swapcontext though. I've been looking at that. If by implementing the *context functions we speed-up the adoption of *context by libc_r, then I'm willing to spend time on it. What I don't want is spending time on *context and in the end not have libc_r, due to it not being changed to use it. Thus: I want people to sign-up for a libc_r that uses *context before 5.0-RELEASE, but preferrably tomorrow. A well-intended timeline would be very nice... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Fri Nov 15 11:55:27 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1040937B401 for ; Fri, 15 Nov 2002 11:55:25 -0800 (PST) Received: from herring.nlsystems.com (mailgate.nlsystems.com [62.49.251.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F26A43E42 for ; Fri, 15 Nov 2002 11:55:23 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring [10.0.0.2]) by herring.nlsystems.com (8.12.6/8.12.6) with ESMTP id gAFJtJDP002686; Fri, 15 Nov 2002 19:55:19 GMT (envelope-from dfr@nlsystems.com) Content-Type: text/plain; charset="iso-8859-1" From: Doug Rabson To: Marcel Moolenaar Subject: Re: setjmp/longjmp and libc_r [was: Re: cvs commit: src/lib/libc/ia64/gen _setjmp.S] Date: Fri, 15 Nov 2002 19:55:19 +0000 User-Agent: KMail/1.4.3 Cc: ia64@FreeBSD.ORG References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <200211150909.32267.dfr@nlsystems.com> <20021115174328.GA4288@dhcp01.pn.xcllnt.net> In-Reply-To: <20021115174328.GA4288@dhcp01.pn.xcllnt.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200211151955.19145.dfr@nlsystems.com> X-Spam-Status: No, hits=-7.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_KMAIL version=2.41 Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Friday 15 November 2002 5:43 pm, Marcel Moolenaar wrote: > On Fri, Nov 15, 2002 at 09:09:32AM +0000, Doug Rabson wrote: > > > > I've managed to reload my memory from magtape :-). To use > > > > setjmp/longjmp for thread switching, you would need to call > > > > flushrs from setjmp. That would simplify longjmp at the cost of > > > > severely pessimising setjmp. > > > > > > This is exactly what we now have and what I'm willing to > > > sacrificy at this time. It's easy enough to optimize > > > setjmp/longjmp once we have the *context stuff. > > > > This is totally wrong. > > No, it's a step in different direction than you would have chosen. > Pick your words with care. See also below. I didn't choose this direction, Intel recommends it. From the IA-64=20 System Architecture manual, section 15.5.1.1: =09This permits execution of a setjmp() without having to manipulate any =09register stack or RSE state. All register stack and RSE manipulation i= s =09postponed to the much less frequent longjmp(). > > > > Note that I'm still not convinced that not doing a flushrs in > > > setjmp will work when a signal handler on the alternate stack > > > jumps to the saved context on the regular stack. You cannot > > > compare the saved ar.bsp or ar.bspstore with the current > > > ar.bspstore without taking into account that they may not be on > > > the same register stack. > > > > The signal trampoline performs the flushrs when it switches stacks. > > Ah, I see. You avoid having the dirty registers on the kernel stack > by doing an exception restore to the original stack, do a flushrs and > then switch to the alternate stack. I wondered about this > hoop-jumping... This also allows the possibility of saving/restoring the high floating=20 point state in user-mode instead of kernel mode which might be a good=20 thing in some situations. > > > For libc_r with the code written this way, you can probably still > > do thread switching without swapcontext(2) by adding an explicit > > flushrs before the call to setjmp(3). It would be less effort to > > write the support for userland or kernel swapcontext though. > > I've been looking at that. If by implementing the *context functions > we speed-up the adoption of *context by libc_r, then I'm willing to > spend time on it. What I don't want is spending time on *context and > in the end not have libc_r, due to it not being changed to use it. > > Thus: I want people to sign-up for a libc_r that uses *context before > 5.0-RELEASE, but preferrably tomorrow. A well-intended timeline would > be very nice... I want to see a libc_r which uses *context too. Its trivial to write=20 thread switching this way and they are designed for it (i.e. no more MD=20 grovelling around in the jmp_buf to setup the stack etc). I've been=20 using makecontext/switchcontext in my own code and it works very well.=20 Changing libc_r to switch this way should be easy if Dan hasn't already=20 done it. --=20 Doug Rabson=09=09=09=09Mail: dfr@nlsystems.com =09=09=09=09=09Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Fri Nov 15 13: 5:44 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85A4D37B401 for ; Fri, 15 Nov 2002 13:05:42 -0800 (PST) Received: from kayak.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8194C43E4A for ; Fri, 15 Nov 2002 13:05:41 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from kayak.xcllnt.net (localhost [127.0.0.1]) by kayak.xcllnt.net (8.12.6/8.12.6) with ESMTP id gAFL5f0N034673; Fri, 15 Nov 2002 13:05:41 -0800 (PST) (envelope-from marcel@kayak.xcllnt.net) Received: (from marcel@localhost) by kayak.xcllnt.net (8.12.6/8.12.6/Submit) id gAFL5eBJ034672; Fri, 15 Nov 2002 13:05:40 -0800 (PST) Date: Fri, 15 Nov 2002 13:05:40 -0800 From: Marcel Moolenaar To: Doug Rabson Cc: ia64@FreeBSD.ORG Subject: Re: setjmp/longjmp and libc_r [was: Re: cvs commit: src/lib/libc/ia64/gen _setjmp.S] Message-ID: <20021115130540.A34636@kayak.xcllnt.net> References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <200211150909.32267.dfr@nlsystems.com> <20021115174328.GA4288@dhcp01.pn.xcllnt.net> <200211151955.19145.dfr@nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211151955.19145.dfr@nlsystems.com> User-Agent: Mutt/1.3.22.1i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Nov 15, 2002 at 07:55:19PM +0000, Doug Rabson wrote: > On Friday 15 November 2002 5:43 pm, Marcel Moolenaar wrote: > > On Fri, Nov 15, 2002 at 09:09:32AM +0000, Doug Rabson wrote: > > > > > I've managed to reload my memory from magtape :-). To use > > > > > setjmp/longjmp for thread switching, you would need to call > > > > > flushrs from setjmp. That would simplify longjmp at the cost of > > > > > severely pessimising setjmp. > > > > > > > > This is exactly what we now have and what I'm willing to > > > > sacrificy at this time. It's easy enough to optimize > > > > setjmp/longjmp once we have the *context stuff. > > > > > > This is totally wrong. > > > > No, it's a step in different direction than you would have chosen. > > Pick your words with care. See also below. > > I didn't choose this direction, Intel recommends it. That's not what I mean. I don't think it's beneficial to try to explain myself. See below. > > Ah, I see. You avoid having the dirty registers on the kernel stack > > by doing an exception restore to the original stack, do a flushrs and > > then switch to the alternate stack. I wondered about this > > hoop-jumping... > > This also allows the possibility of saving/restoring the high floating > point state in user-mode instead of kernel mode which might be a good > thing in some situations. I have to think about this angle. I've been thinking about the high FPs in the context of SMP. The goal being to avoid saving the high FP in cpu_switch altogether and deal with processes moving to a different CPU in a lazy way. The same principle as avoiding the flushrs in setjmp... > > Thus: I want people to sign-up for a libc_r that uses *context before > > 5.0-RELEASE, but preferrably tomorrow. A well-intended timeline would > > be very nice... > > I want to see a libc_r which uses *context too. Its trivial to write > thread switching this way and they are designed for it (i.e. no more MD > grovelling around in the jmp_buf to setup the stack etc). I've been > using makecontext/switchcontext in my own code and it works very well. > Changing libc_r to switch this way should be easy if Dan hasn't already > done it. Ok. I guess this is the best I can get. I'll work on it this weekend. I'll restore the previous behaviour of setjmp/longjmp while I'm at it. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Fri Nov 15 17:40:53 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35E9D37B401 for ; Fri, 15 Nov 2002 17:40:52 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05C6243E75 for ; Fri, 15 Nov 2002 17:40:48 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id E40AC2A88D for ; Fri, 15 Nov 2002 17:40:47 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ia64@freebsd.org Subject: Warning: time_t Date: Fri, 15 Nov 2002 17:40:47 -0800 From: Peter Wemm Message-Id: <20021116014047.E40AC2A88D@canning.wemm.org> Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I suspect that all 3 FreeBSD/ia64 users know about this already, but just in case there are some stealth users that I dont know about, beware of the 64 bit time_t in -current. In all, it should be pretty transparent. I recently upgraded a 6-month-old ia64 world to -current and did the time_t jump at the same time, and all things considered, it went pretty well. What ended up killing me was that I prematurely installed new /usr/include, without the corresponding libc.so.5 changes. Aside from that silly mistake (which broke install(8) when it used utime(3)), it goes fairly well. Expect 3 alignment fixes during 'installworld'. This is because the *old* dynamic /tmp/install.XXXXX/find is being run with the new /usr/lib/libc.so.5. 'make installworld' doesn't fail for me though. But to be safe, run a second 'installworld' to be sure. Aside from that, it should be pretty uneventful. Now to find out why sshd blows up with PrivSep turned on. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sat Nov 16 3: 1:49 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0489B37B401 for ; Sat, 16 Nov 2002 03:01:43 -0800 (PST) Received: from herring.nlsystems.com (mailgate.nlsystems.com [62.49.251.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4553943E4A for ; Sat, 16 Nov 2002 03:01:42 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring [10.0.0.2]) by herring.nlsystems.com (8.12.6/8.12.6) with ESMTP id gAGB1cDP006426; Sat, 16 Nov 2002 11:01:38 GMT (envelope-from dfr@nlsystems.com) Content-Type: text/plain; charset="iso-8859-1" From: Doug Rabson To: Marcel Moolenaar Subject: Re: setjmp/longjmp and libc_r [was: Re: cvs commit: src/lib/libc/ia64/gen _setjmp.S] Date: Sat, 16 Nov 2002 11:01:38 +0000 User-Agent: KMail/1.4.3 Cc: ia64@FreeBSD.ORG References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <200211151955.19145.dfr@nlsystems.com> <20021115130540.A34636@kayak.xcllnt.net> In-Reply-To: <20021115130540.A34636@kayak.xcllnt.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200211161101.38075.dfr@nlsystems.com> X-Spam-Status: No, hits=-8.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_KMAIL version=2.41 Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Friday 15 November 2002 9:05 pm, Marcel Moolenaar wrote: > On Fri, Nov 15, 2002 at 07:55:19PM +0000, Doug Rabson wrote: > > This also allows the possibility of saving/restoring the high > > floating point state in user-mode instead of kernel mode which > > might be a good thing in some situations. > > I have to think about this angle. I've been thinking about the high > FPs in the context of SMP. The goal being to avoid saving the high FP > in cpu_switch altogether and deal with processes moving to a > different CPU in a lazy way. The same principle as avoiding the > flushrs in setjmp... I thought that we already did this - we defer switching the FP state=20 until the thread takes a VEC_DISABLED_FP trap.=20 > > > > Thus: I want people to sign-up for a libc_r that uses *context > > > before 5.0-RELEASE, but preferrably tomorrow. A well-intended > > > timeline would be very nice... > > > > I want to see a libc_r which uses *context too. Its trivial to > > write thread switching this way and they are designed for it (i.e. > > no more MD grovelling around in the jmp_buf to setup the stack > > etc). I've been using makecontext/switchcontext in my own code and > > it works very well. Changing libc_r to switch this way should be > > easy if Dan hasn't already done it. > > Ok. I guess this is the best I can get. I'll work on it this weekend. > I'll restore the previous behaviour of setjmp/longjmp while I'm at > it. Thanks. Sorry if I've come over a bit dogmatic on the subject but I do=20 think that using longjmp to switch stacks is dubious on any=20 architecture and specially for ia64. At least switchcontext is designed=20 for the job :-). --=20 Doug Rabson=09=09=09=09Mail: dfr@nlsystems.com =09=09=09=09=09Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sat Nov 16 9:21: 6 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E279D37B401 for ; Sat, 16 Nov 2002 09:21:03 -0800 (PST) Received: from kayak.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id C110543E42 for ; Sat, 16 Nov 2002 09:21:02 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.12.6/8.12.6) with ESMTP id gAGHL20N039386; Sat, 16 Nov 2002 09:21:02 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id gAGHL3Uq000738; Sat, 16 Nov 2002 09:21:03 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id gAGHL2Ct000737; Sat, 16 Nov 2002 09:21:02 -0800 (PST) (envelope-from marcel) Date: Sat, 16 Nov 2002 09:21:02 -0800 From: Marcel Moolenaar To: Doug Rabson Cc: ia64@FreeBSD.ORG Subject: Re: libc_r: syscalls, epc and unwinding [was: Re: setjmp/longjmp and libc_r...] Message-ID: <20021116172102.GA618@dhcp01.pn.xcllnt.net> References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <200211151955.19145.dfr@nlsystems.com> <20021115130540.A34636@kayak.xcllnt.net> <200211161101.38075.dfr@nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211161101.38075.dfr@nlsystems.com> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Nov 16, 2002 at 11:01:38AM +0000, Doug Rabson wrote: > > > This also allows the possibility of saving/restoring the high > > > floating point state in user-mode instead of kernel mode which > > > might be a good thing in some situations. > > > > I have to think about this angle. I've been thinking about the high > > FPs in the context of SMP. The goal being to avoid saving the high FP > > in cpu_switch altogether and deal with processes moving to a > > different CPU in a lazy way. The same principle as avoiding the > > flushrs in setjmp... > > I thought that we already did this - we defer switching the FP state > until the thread takes a VEC_DISABLED_FP trap. We always save and drop the state in the SMP case. That is, if the CPU holds the high FP state of the thread being switched. > > > > Thus: I want people to sign-up for a libc_r that uses *context > > > > before 5.0-RELEASE, but preferrably tomorrow. A well-intended > > > > timeline would be very nice... > > > > > > I want to see a libc_r which uses *context too. Its trivial to > > > write thread switching this way and they are designed for it (i.e. > > > no more MD grovelling around in the jmp_buf to setup the stack > > > etc). I've been using makecontext/switchcontext in my own code and > > > it works very well. Changing libc_r to switch this way should be > > > easy if Dan hasn't already done it. > > > > Ok. I guess this is the best I can get. I'll work on it this weekend. > > I'll restore the previous behaviour of setjmp/longjmp while I'm at > > it. > > Thanks. Sorry if I've come over a bit dogmatic on the subject but I do > think that using longjmp to switch stacks is dubious on any > architecture and specially for ia64. At least switchcontext is designed > for the job :-). This whole situation has put me in a place where I didn't want to be: Dan has removed the userland *context functions and created syscalls. This we wanted of course, but we're not ready yet to have the syscalls. Ergo: progress on libc_r has been endangered :-( I have a couple of approaches: 1. Bite the bullet and implement EPC for syscalls. This is an ABI breaker and best be done before release, but has high impact. As a side-effect, I might be able to save the preserved registers as a special case to avoid having to depend on unwinding, which we don't have reliably yet for this purpose. Is almost a single- commit change, but very very attractive... 2. Finish the unwinding job I started and use it for the *context syscalls. High impact, but can be spread over many commits; 3. more? On the subject of unwinding: I talked to David Mosberger yesterday. He told me of a case where unwinding is being used to implement longjmp. It would be very interesting to find out in how many steps one can unwind to the context of setjmp and how much performance gain it gives. Also, David is willing to change the license of his libunwind library if he thinks that's beneficial (for him of course). I also talked to Cary Coutant and he also has something we might use, but chances are slimmer (HP internal source with an intention to open source it). In short: I'm looking into ways to avoid that we have to flesh out our own unwinder in the kernel, provided we can find code that is suitable for our use. In this light, doing EPC now helps because otherwise I would end up fleshing out our unwinder anyway. I'll give this some thought over coffee... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sat Nov 16 13:34: 2 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F42137B401 for ; Sat, 16 Nov 2002 13:34:02 -0800 (PST) Received: from kayak.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5789B43E3B for ; Sat, 16 Nov 2002 13:34:01 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.12.6/8.12.6) with ESMTP id gAGLY00N039868; Sat, 16 Nov 2002 13:34:00 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id gAGLY1Uq001380; Sat, 16 Nov 2002 13:34:01 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id gAGLY0dX001379; Sat, 16 Nov 2002 13:34:00 -0800 (PST) (envelope-from marcel) Date: Sat, 16 Nov 2002 13:34:00 -0800 From: Marcel Moolenaar To: Peter Wemm Cc: ia64@FreeBSD.ORG Subject: Re: Warning: time_t Message-ID: <20021116213400.GB1298@dhcp01.pn.xcllnt.net> References: <20021116014047.E40AC2A88D@canning.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021116014047.E40AC2A88D@canning.wemm.org> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Nov 15, 2002 at 05:40:47PM -0800, Peter Wemm wrote: > I suspect that all 3 FreeBSD/ia64 users know about this already, but just in > case there are some stealth users that I dont know about, beware of the 64 > bit time_t in -current. Before I forget: Thanks, Peter! I'm rebuilding world now. After I've rebuilt some ports (mkisofs) I'll start a release. I should have bootable ISOs by sunday with the 64-bit time_t... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message