From owner-freebsd-ia64 Sun Sep 9 0: 4:26 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id DBA0A37B408 for ; Sun, 9 Sep 2001 00:04:19 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.4/8.11.4) with ESMTP id f8974Jf43806 for ; Sun, 9 Sep 2001 00:04:19 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.3) id f8974Su33402 for ia64@freebsd.org; Sun, 9 Sep 2001 00:04:28 -0700 (PDT) (envelope-from marcel) Date: Sun, 9 Sep 2001 00:04:28 -0700 From: Marcel Moolenaar To: ia64@freebsd.org Subject: Ski port Message-ID: <20010909000427.A33296@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.21i 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 Guys, I started working on the ski port today. I have it compiling, but not linking. I have to implement the FreeBDS syscalls first. A thought struck me: what if I, instead of implementing most syscalls so that ski can be used for user processes, I implement an EFI interface first? We're currently not really interested in userland code, so we're going to run ski in "raw" mode anyway. I should be able to hack something together that allows us to work on a real EFI bootloader. With a combination of fake and real ACPI entries we should be able to boot a kernel as if it was running on real hardware, right? Thoughts? -- 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 Sun Sep 9 0:59:46 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from ns.sovintel.ru (ns.sovintel.ru [212.44.130.6]) by hub.freebsd.org (Postfix) with ESMTP id 104B737B40C for ; Sun, 9 Sep 2001 00:59:39 -0700 (PDT) Received: from ppp70-spb-213-221-48.sovintel.ru (ppp70-spb-213-221-48.sovintel.ru [213.221.48.70] (may be forged)) by ns.sovintel.ru (8.11.5/8.11.5) with SMTP id f897wGo66254 for ; Sun, 9 Sep 2001 11:58:30 +0400 (MSD) (envelope-from helprita@list.ru) Message-ID: <00de01c138d8$84c3cb40$1230ddd5@users.mns.ru> From: "alya radzik" To: freebsd-ia64@FreeBSD.org Subject: =?koi8-r?B?0M/Nz8fJ1MUg09DB09TJIM3BzMXO2MvVwCDExdfP3svV?= Date: Sun, 9 Sep 2001 06:38:32 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00DB_01C138FA.0B785720" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2417.2000 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 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 is a multi-part message in MIME format. ------=_NextPart_000_00DB_01C138FA.0B785720 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Моей дочери Рите 7 лет. 1 января 2001 года у нее начались спазмы почки, а на следующий день вылился почти литр крови. Маргарите поставили страшный диагноз - опухоль Вилмса правой почки с метастазами в правое легкое, 4-я стадия. С этого момента девочка перенесла курс интенсивной лучевой и химиотерапии, тяжелейшую операцию по удалению правой почки и опухолевого тромба длиной 8.5 см., заражение крови через катетер, химический ожог кишечника, гемаррагический синдром и падение зрения. Состояние и мучения девочки не передать никакими словами. Несмотря на полгода интенсивных процедур лечение Маргариты далеко от успешного завершения. А ведь Рита всего лишь семилетняя девочка, которая очень любит танцевать и много трудилась до болезни, чтобы стать балериной. Наши опытные врачи дают нам благоприятный прогноз, но чтобы вылечиться, нам необходимы лекарства для защиты и поддержания органов, время от времени нужна кровь для вливания. Лекарства очень дорогие, одна ампула нейпогена стоит 180 долларов, а ампул нужно много, перед каждым блоком химии. 50 мг. дифлюкана в растворе стоят 550 рублей - это нам на день, 7 капсул дифлюкана по 50 мг. - около 900 рублей, а в день нужно принимать 2 капсулы. Мы должны пить эссенциале, покупать противорвотные латран, зофрам, для защиты сердца от токсического воздействия химии и общей поддержки нужны кардиоксан, инозия-ф, коэнзим Q10 и т.д. Рита очень нежная девочка и плохо переносит жесткий протокол лечения по 4 стадии. Она была на грани гибели после лечения химиопрепаратом карбоплатина. Поэтому ее перевели на менее жесткий протокол лечения по 3 стадии, но остающийся метастаз в легком вероятно вынудит врачей снова провести курс карбоплатины, о чем нас заранее предупредили, и тогда нам будет нужен амбизом - самый эффективный на сегодняшний день противогрибковый препарат. Нам понадобится около 10 ампул амбизома, а цена одной ампулы около 220 долларов. Его более дешевые аналоги для нас непригодны из-за токсичности. Мы с Ритой, ее бабушкой и моей сестрой живем в одной комнате (14.2 м2) в коммуналке на первом этаже, под нами в подвале постоянно стоит вода. Квартира темная и сырая. Даже когда ход лечения позволяет нам возвращаться домой, мы с дочкой часто предпочитаем оставаться в больнице, где условия проживания гораздо лучше. Я не могу работать, так как постоянно нахожусь на отделении вместе с Маргаритой. Моя мама получает пенсию 780 рублей, сестра зарабатывает около 1500 рублей. Прошу помощи, очень трудно! Заранее спасибо всем, кто откликнется. С уважением, Алевтина Раздик тел: (812)272-92-18 helprita@list.ru http://helprita.boom.ru ------=_NextPart_000_00DB_01C138FA.0B785720 Content-Type: image/jpeg; name="homerita.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="homerita.jpg" /9j/4AAQSkZJRgABAgEASwBLAAD//gAmRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rvc2hvcKgg NS4w/+4AIUFkb2JlAGSAAAAAAQMAEAMCAwYAAAAAAAAAAAAAAAD/2wCEAAwICAgJCAwJCQwRCwoL ERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4N EA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DP/CABEIAGQAWgMBIgACEQEDEQH/xADLAAACAgMBAQAAAAAAAAAAAAAFBgMEAAcIAgEBAAIDAQAA AAAAAAAAAAAAAAIDAAQFARAAAgICAgEDAwMFAAAAAAAAAgMBBAAFERIGExQWICIVECEyMDEkBxcR AAIBAwEFBQMGCA8AAAAAAAECAwAREgQhMUEiE1EyQlIzciMUcbFigpKiEGHSU2NzNAUgMIGRodGy wuJDk8PjVDUSAAIBAwEFBQcFAAAAAAAAAAABETECEiEQQWFCEyBRcSIy8IGRobFSYoIDI1MU/9oA DAMBAQIRAxEAAAAcdUpMwmT2uScM+k2JHtZfghaa7aLHrS+NfYMCE3NCeJjyhxZjaEcoBAkxOiHm iSvxsDAuulUpSV+BCjNdVHLjQgUGCyy5IzEbJKFpor8mriVurXbbr1i2ETYmv2uteonuCNtG00ze TWJhFaK8dHgUJJ950BVvzZ82YLmWKcjalojpEx2lIjoLN+hN0R1F6PjEFUKUaaq+xRN8PRsjXxQ2 Bq1wpG9NYbBNJkTkU2dEavOeciRS0zmYXSBnlbNIeqs5Vwp1VnKuSdVZyrknVWcq5J//2gAIAQIA AQUAJSywlhMJUoSlHUuk8+nPHQeFLkiBa4yRjh0yI+4LgZKZV9sDMzBZZnhfeOoyMlEc5EzhRzHM SP8AkdhI3BTlkRE8yU/tyUZ1H1VJ65W4yI4zrHOdY5T/AHD+P0f/2gAIAQMAAQUAFpDkNnkRa0rC GpiYHjkOec5yTZEy9zBmOQ6jgliw7SQjGCQzgDzPSeRHnE4Y/tASElH3cIyJBZQYHBp+305iCkYn tPUmwWRyOTZLrJlP6s/l9P8A/9oACAEBAAEFANVsU1RR5RrRv3F+JbANd8c1y27vS6mhHkmyfbqe b3Eg7zixYVoPJqGqqV9/Qsq/OURj5TrsAGTMIvdVULtiT1ezWTKFrYtPx5ZHapQGuTZNpaW2rYVb Ba+Ned0vR9hGR40EiXjFuM+L3iHZ+PWwoAQamrdfcsuTetDYrqbT29DrWylo421hPiFxQfjNlkTz nM4fPHkHkJPdagvTlZNWWqZCS1fvagdhDxlNYrjNzTSHyFWespcPv1VzsPKKQVNTVtXV1tE1mR4f wIePWAyvpIrjv6xK2tQ1qr7qrUvo+O0csxYOHn1jbX2MLQFwGuBfUBGckB6lCO3l9IGN1IrsYjQr i76uWNTTdG+WmmgyWk/FEkNSu6lEqzpJRZUayv21LB+vKrl/QWhrfHdnkFzH+wFvrW68TaOprnPp fHdgTtQh80Hh5Im3VZccrd7NSb292iTqxvXVK/5irh2whWyTSvhvPHatJWjaoQu20RlUlkkwQZtg BDygjsb0qtloavYt1uy+cOw4cmke090CNnZhWjam4mNn6L0Xqq5sW1tYMtIb3jjatibCjzVvRqXe 8qZFol5Z1tCkes9ge1vQiqz2yrk1qVscmtMApXWOMVXrpnY6HWbJX/N62bOwNjHN2A5qNUTLWuoT Vojr6QEK+v12/Yezb8k9TTfifdf0f//aAAgBAgIGPwDK6JMZTtmhFqTuZrbBDfhBvOYiiWswUl94 4OJGbp3EE73s1Y25xS1aOl/ou6cZTHmy/ryLdyZuIgpBBjy5ermxElW3eY3vLF1PEagWjRl0/NGP UknW1Oto/wCOPyeydkwXeK9Qqe7s/wD/2gAIAQMCBj8AhNktVpCFbanLF1FGVDL4yU+eySU2o7hW /uN3K3W2RplR7KFB8aGfRWeUV5fuxGhktwVTQzLXKIifKaveNLSVREWy49vSWttrhdUbmZPXxwga xVzSqZZKXy2kfVEPaq/o7X//2gAIAQEBBj8AKyzTadggETqtyhvzt9LKo5Z9RPqIYwVJ6Vrk28r0 Ypv3trVheQyNE98Lk+HKPJcam08H7z1LpKCosiFlW3mwp5NFLqddqMBHH18QntOi9JOWgNRqmIBu FJ5N98V8lRxMFlixJ6rXy2fSqTSMuEc4Kl1UsTfZ2+WunrG5Cw9+l9g7q9SLvUJ9O5kiYlQQQBkO 93qu0gH4iy/11x324UcmIvuAFzs/u1ksbG/4t9ASpgRwJCV3DHGwuxBJOI8VR6aEHA5MwF74pUMT e6ji5mFiC39FLDpO/ECBnxBOVSQ3tNHdlI4Yml65w1KWs/A25sXqbJV00+nZmWSMOQxYKfTHI3NU aRR6d81F5cTG4uB4WeTmr/zYvR/OLv8Azu+jdYwbWUgC/wBakZNSqMl9yA/PWL6xbE5G0Sg39qtT qH1zySJA/JiLMArcn1q08/VL6uWEq8SixUnbi1B3lOQIsMiLL9WpIJJCyNsiLG6g/VOVM+oGOVyj C5Uljy1LGRZhNioO61+T7r1JGNQISFV+m3EHvL9qiTwUBABfYK3N6GHHf5a2fgNjapY4nxgiGC23 Mx8bezRdrtKF3ntJotuLAknibGutGpZSbbPlrpup60Numx4G1TFl9+JVyHYQwXl+zQ1MwvgjR7eN zfm9nGun1Stjytvt8teovZ/jqxYWoozAsNoUG9SFQ2RRgDs2bPlqReCG+R43rpyi6NYX7LGioIA4 bKWGNAEYjqtwuBytTAhWJWxvvv8AyUMUEaaghrdjLjnTtJIVBkBJ7BfmqGXTzpEyyBM1bYQ/sV+1 zbrd7727u00gZ+Xbv4eGlYSPcXMuR33pdMhxWVrADiPM3loRxD3YNjxJ9qtoFxWyjR2bbbajlQW6 JZieIvYVLGSmCg26gBB4feo6l36caOGRFC2BHnby14N+PfXu+agGBBtY22bKugGZZwLncoNua9Nq p1B3soubn2dtJLqAV6m2w27CaVBIEcjYrcpP2qt2UduyiwOy/wA9PFKmTMdhIvtqSf8AypkDAbrB ifCKhkjndpZZArCVjgqtl5e4qV6qbsPU4f8AY/U1s40kgGUUgYp2E27tGZx1B33v2LzKn0aQaeUw nHbiATt8uVO8v711DxLtjgkW4DbO89mXH2KvIecXFD4SODVLdrpNI62GzFss/wDbq2qgEEw3hWDo QPEj/l1NC7hWhnUpluKjBnWpAlimClLdjWf7uVL8LGsstgJkk5gUJ8KpXrj07em+/wDMd2thuwPh oQ6nGVg2cd96ipNbooTGCMZEFitjys6ighO2ukGGbdu6gUIIPZVrDMb+2rDh2Vq0iOWLNc9pDfk1 AGNhioIvwxWvidNEspQdEo635Se/HjzZ1/50Pq5f8v6ypnHK0RdhsFiL5f2a1McoTOUWgdmsN3d5 F8zU+nnkWQRozRglSthhnj4mxyrqJLjynau8OPDR00ukeZmBYPmtnt5cvFSxTaCdG2HGwcC/stSP pFcTIQJEZGXlP0mGH3qGW/srVa+aOZQGL2CEg3OXqJlHUzQWaMRjFHGRDEczNj3Fjp5dbAZInjLd Wys3iX3fkzev2eT1M949P8qg7IXlmtlBJsIVjz8jeFa14nUhHXPT47lBUIycv6RfG9QNJ7kalhE8 YGIUSgqzr5EyoRmIRIB6lrXP0seWrRlXZDssQbXoAgC1ua+2go2kWN+N6u21jvP4GMUaRltrFVAv 9mmSeFQzj1EGLfzjvfWr9tbfb007nlpdTp7LIimKQ7GLb+5ieZUenhn1SOsitiLWANkLe3IuNKdL pS2sQgmaQkociyzKmzuJ9Ol000jam17mU5mxPp5N3lTwUXjhVGbeVFvmrYT/AA0+Fy+Kybo4Wt3m y7vL08/r1F8b0Ph8X6VrY48nUy6Xvf8AUqfoY/GX95a1rfoP0X8V/9k= ------=_NextPart_000_00DB_01C138FA.0B785720-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Sun Sep 9 9:45:45 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id AF3E937B405 for ; Sun, 9 Sep 2001 09:45:42 -0700 (PDT) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 15g7iH-0004q3-0Y; Sun, 9 Sep 2001 17:45:41 +0100 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f89GiPc64501; Sun, 9 Sep 2001 17:44:25 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 9 Sep 2001 17:44:02 +0100 (BST) From: Doug Rabson To: Marcel Moolenaar Cc: Subject: Re: Ski port In-Reply-To: <20010909000427.A33296@dhcp01.pn.xcllnt.net> Message-ID: <20010909174317.V406-100000@salmon.nlsystems.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 On Sun, 9 Sep 2001, Marcel Moolenaar wrote: > Guys, > > I started working on the ski port today. I have it compiling, but > not linking. I have to implement the FreeBDS syscalls first. A > thought struck me: what if I, instead of implementing most syscalls > so that ski can be used for user processes, I implement an EFI > interface first? > > We're currently not really interested in userland code, so we're > going to run ski in "raw" mode anyway. I should be able to hack > something together that allows us to work on a real EFI bootloader. > With a combination of fake and real ACPI entries we should be able > to boot a kernel as if it was running on real hardware, right? > > Thoughts? That would probably be pretty useful. It sounds like a *lot* of work though. EFI is pretty extensive. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +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 Sun Sep 9 10:17:16 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id B3F9937B403 for ; Sun, 9 Sep 2001 10:17:00 -0700 (PDT) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by kayak.xcllnt.net (8.11.4/8.11.4) with ESMTP id f89HH0f45241; Sun, 9 Sep 2001 10:17:00 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.11.6/8.11.5) id f89HH0u00666; Sun, 9 Sep 2001 10:17:00 -0700 (PDT) (envelope-from marcel) Date: Sun, 9 Sep 2001 10:17:00 -0700 From: Marcel Moolenaar To: Doug Rabson Cc: ia64@freebsd.org Subject: Re: Ski port Message-ID: <20010909101700.A531@athlon.pn.xcllnt.net> References: <20010909000427.A33296@dhcp01.pn.xcllnt.net> <20010909174317.V406-100000@salmon.nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010909174317.V406-100000@salmon.nlsystems.com> User-Agent: Mutt/1.3.21i 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 Sun, Sep 09, 2001 at 05:44:02PM +0100, Doug Rabson wrote: > On Sun, 9 Sep 2001, Marcel Moolenaar wrote: > > > We're currently not really interested in userland code, so we're > > going to run ski in "raw" mode anyway. I should be able to hack > > something together that allows us to work on a real EFI bootloader. > > With a combination of fake and real ACPI entries we should be able > > to boot a kernel as if it was running on real hardware, right? > > > > That would probably be pretty useful. It sounds like a *lot* of work > though. EFI is pretty extensive. Yes, it would be a lot of work. And I can imagine that the ski owners are not going to keep the feature if it wasn't done right. I think it's good to have. I just want to make sure I spend my time well and not waste it on a feature that will never complete and/or won't be used. Another thought struck me. As soon as we have our own toolchain, we probably will use DBX as the debugging format and not dwarf. I'd better make sure that ski supports DBX if we want it to be as useful then as it is now. -- 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 Sun Sep 9 10:46: 4 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by hub.freebsd.org (Postfix) with ESMTP id D01DC37B403 for ; Sun, 9 Sep 2001 10:46:00 -0700 (PDT) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 15g8ed-0002Q3-0W; Sun, 9 Sep 2001 18:45:59 +0100 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f89Hiic64815; Sun, 9 Sep 2001 18:44:44 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 9 Sep 2001 18:44:20 +0100 (BST) From: Doug Rabson To: Marcel Moolenaar Cc: Subject: Re: Ski port In-Reply-To: <20010909101700.A531@athlon.pn.xcllnt.net> Message-ID: <20010909184220.K406-100000@salmon.nlsystems.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 On Sun, 9 Sep 2001, Marcel Moolenaar wrote: > On Sun, Sep 09, 2001 at 05:44:02PM +0100, Doug Rabson wrote: > > On Sun, 9 Sep 2001, Marcel Moolenaar wrote: > > > > > We're currently not really interested in userland code, so we're > > > going to run ski in "raw" mode anyway. I should be able to hack > > > something together that allows us to work on a real EFI bootloader. > > > With a combination of fake and real ACPI entries we should be able > > > to boot a kernel as if it was running on real hardware, right? > > > > > > > That would probably be pretty useful. It sounds like a *lot* of work > > though. EFI is pretty extensive. > > Yes, it would be a lot of work. And I can imagine that the ski owners > are not going to keep the feature if it wasn't done right. I think > it's good to have. I just want to make sure I spend my time well and > not waste it on a feature that will never complete and/or won't be > used. Before you start, I suggest you pick up a copy of the EFI sample implementation source and have a look at that. Actually, having that source around is pretty useful for clarifying bits of the EFI spec. > > Another thought struck me. As soon as we have our own toolchain, we > probably will use DBX as the debugging format and not dwarf. I'd > better make sure that ski supports DBX if we want it to be as useful > then as it is now. I have no idea what format is considered best these days. I thought that dwarf2 was the direction things were moving in though. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +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 Sun Sep 9 11:12:31 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id 076F437B401 for ; Sun, 9 Sep 2001 11:12:28 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.4/8.11.4) with ESMTP id f89ICRf45425; Sun, 9 Sep 2001 11:12:27 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.3) id f89ICch00833; Sun, 9 Sep 2001 11:12:38 -0700 (PDT) (envelope-from marcel) Date: Sun, 9 Sep 2001 11:12:38 -0700 From: Marcel Moolenaar To: Doug Rabson Cc: ia64@freebsd.org Subject: Re: Ski port Message-ID: <20010909111238.A575@dhcp01.pn.xcllnt.net> References: <20010909101700.A531@athlon.pn.xcllnt.net> <20010909184220.K406-100000@salmon.nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010909184220.K406-100000@salmon.nlsystems.com> User-Agent: Mutt/1.3.21i 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 Sun, Sep 09, 2001 at 06:44:20PM +0100, Doug Rabson wrote: > On Sun, 9 Sep 2001, Marcel Moolenaar wrote: > > > On Sun, Sep 09, 2001 at 05:44:02PM +0100, Doug Rabson wrote: > > > On Sun, 9 Sep 2001, Marcel Moolenaar wrote: > > > > > > > We're currently not really interested in userland code, so we're > > > > going to run ski in "raw" mode anyway. I should be able to hack > > > > something together that allows us to work on a real EFI bootloader. > > > > With a combination of fake and real ACPI entries we should be able > > > > to boot a kernel as if it was running on real hardware, right? > > > > > > > > > > That would probably be pretty useful. It sounds like a *lot* of work > > > though. EFI is pretty extensive. > > > > Yes, it would be a lot of work. And I can imagine that the ski owners > > are not going to keep the feature if it wasn't done right. I think > > it's good to have. I just want to make sure I spend my time well and > > not waste it on a feature that will never complete and/or won't be > > used. > > Before you start, I suggest you pick up a copy of the EFI sample > implementation source and have a look at that. Actually, having that > source around is pretty useful for clarifying bits of the EFI spec. I got it. The license allows its use for EFI emulation, so maybe we're lucky here. I'll get in touch with Mike (ski owner) and David (Linux porter) and see what they think. > > > > Another thought struck me. As soon as we have our own toolchain, we > > probably will use DBX as the debugging format and not dwarf. I'd > > better make sure that ski supports DBX if we want it to be as useful > > then as it is now. > > I have no idea what format is considered best these days. I thought that > dwarf2 was the direction things were moving in though. Yes, I think it is. If we're going to stick with dwarf, now is probably the best time to decide (with now I mean without having any ia64 releases and backward compatibility problems; and me not having coded DBX support in ski of course :-). I think we should stick with dwarf on ia64. It gives us the most freedom to experiment with different compilers. I don't want to get stuck with gcc while SGI has a compiler that works for us and produces much better code. -- 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 Mon Sep 10 16:30:31 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 8DA9F37B407 for ; Mon, 10 Sep 2001 16:30:28 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id f8ANUOZ70315; Mon, 10 Sep 2001 16:30:24 -0700 (PDT) (envelope-from obrien) Date: Mon, 10 Sep 2001 16:30:24 -0700 From: "David O'Brien" To: Marcel Moolenaar Cc: ia64@freebsd.org Subject: Re: Ski port Message-ID: <20010910163024.A70233@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20010909000427.A33296@dhcp01.pn.xcllnt.net> <20010909174317.V406-100000@salmon.nlsystems.com> <20010909101700.A531@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010909101700.A531@athlon.pn.xcllnt.net>; from marcel@xcllnt.net on Sun, Sep 09, 2001 at 10:17:00AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 Sun, Sep 09, 2001 at 10:17:00AM -0700, Marcel Moolenaar wrote: > Another thought struck me. As soon as we have our own toolchain, we It was about 2 weeks away until yesterday.... > probably will use DBX as the debugging format and not dwarf. Note that the IA-64 psABI requires DWARF debugging and I was planning on changing all FreeBSD platform's prefered debugging type to be DWARF. This is also the debugging format the GDB maintainers want to spend time on. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Mon Sep 10 19:40: 5 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id 00DCC37B40B; Mon, 10 Sep 2001 19:40:02 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.4/8.11.4) with ESMTP id f8B2e1m00507; Mon, 10 Sep 2001 19:40:01 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.3) id f8B2eEZ00644; Mon, 10 Sep 2001 19:40:14 -0700 (PDT) (envelope-from marcel) Date: Mon, 10 Sep 2001 19:40:14 -0700 From: Marcel Moolenaar To: "David O'Brien" Cc: ia64@FreeBSD.ORG Subject: Re: Ski port Message-ID: <20010910194014.A577@dhcp01.pn.xcllnt.net> References: <20010909000427.A33296@dhcp01.pn.xcllnt.net> <20010909174317.V406-100000@salmon.nlsystems.com> <20010909101700.A531@athlon.pn.xcllnt.net> <20010910163024.A70233@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010910163024.A70233@dragon.nuxi.com> User-Agent: Mutt/1.3.21i 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 Mon, Sep 10, 2001 at 04:30:24PM -0700, David O'Brien wrote: > On Sun, Sep 09, 2001 at 10:17:00AM -0700, Marcel Moolenaar wrote: > > Another thought struck me. As soon as we have our own toolchain, we > > It was about 2 weeks away until yesterday.... What happened yesterday? > Note that the IA-64 psABI requires DWARF debugging and I was planning on > changing all FreeBSD platform's prefered debugging type to be DWARF. > This is also the debugging format the GDB maintainers want to spend time > on. Ok, good to know. I'll make sure that ski has DWARF support and I'm not going to worry about anything else. -- 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 Mon Sep 10 20: 9: 1 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from wildcatblue.com (flanders.wildcatblue.com [206.157.147.206]) by hub.freebsd.org (Postfix) with ESMTP id 0D7A737B403 for ; Mon, 10 Sep 2001 20:08:58 -0700 (PDT) Received: from vghk (unknown [206.157.147.77]) by wildcatblue.com (Postfix) with SMTP id 42DBB85B02 for ; Mon, 10 Sep 2001 22:23:01 +0000 (GMT) Message-ID: <002f01c13a6e$6cf873c0$040a0a0a@vghk> From: "David Rhodus" To: Subject: sign up Date: Mon, 10 Sep 2001 23:04:08 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01C13A4C.E55A4B30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 is a multi-part message in MIME format. ------=_NextPart_000_002C_01C13A4C.E55A4B30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable sign up Thanks, David Rhodus Sekurity.net sdrhodus@wildcatblue.com ********************************************** This message is confidential; its contents do not constitute a commitment by Sekurity Networks except where provided for in a written = agreement between you and Sekurity Networks. Any unauthorised disclosure, use or dissemination, either whole or partial, is prohibited. If you are not the intended recipient of=20 the message, please notify the sender immediately. *********************************************** ------=_NextPart_000_002C_01C13A4C.E55A4B30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
sign up

Thanks,
 
David Rhodus
Sekurity.net
sdrhodus@wildcatblue.com
= **********************************************
This=20 message is confidential; its contents do not constitute
a commitment = by=20 Sekurity Networks except where provided for in a written agreement = between you=20 and Sekurity Networks.
Any unauthorised disclosure, use or = dissemination,=20 either whole
or partial, is prohibited. If you are not the intended = recipient=20 of
the message, please notify the sender=20 immediately.
*********************************************** ------=_NextPart_000_002C_01C13A4C.E55A4B30-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Sep 11 3:23:31 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from darius.concentric.net (darius.concentric.net [207.155.198.79]) by hub.freebsd.org (Postfix) with ESMTP id D7A5E37B407 for ; Tue, 11 Sep 2001 03:23:29 -0700 (PDT) Received: from newman.concentric.net (newman.concentric.net [207.155.198.71]) by darius.concentric.net [Concentric SMTP Routing 1.0] id f8BANS005007 for ; Tue, 11 Sep 2001 06:23:28 -0400 (EDT) Received: from gmx.net (da001d1068.lax-ca.osd.concentric.net [64.0.148.47]) by newman.concentric.net (8.9.1a) id GAA08004; Tue, 11 Sep 2001 06:23:27 -0400 (EDT) Date: Tue, 11 Sep 2001 06:23:27 -0400 (EDT) Message-Id: <200109111023.GAA08004@newman.concentric.net> From: BenefitsAll@gmx.net Reply-To: BenefitsAll@gmx.net To: ia64@freebsd.org Subject: Donation to your organization 090401 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 Dear Friend Sept 2001 Newsletter Here is another way for your organization to raise money in a painless way Cash rebates of up to 30% from BenefitsAll become welcome donations to your organization when your members shop online with Borders, Disney, Dell, Gap, Esprit and 300 plus retailers through our web site. Widely endorsed, socially responsible site offers no obligation, free rebate program for members. See how easy it is for your charity to earn substantial cash back for every online, shopping purchase made. To find out more information from BenefitsAll click on reply and we will contact you shortly. Please put "MORE INFO" in the subject box. To remove you from this list type " REMOVE" in the subject box and click reply. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Wed Sep 12 15:21:18 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id 67BA137B40D; Wed, 12 Sep 2001 15:21:05 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.4/8.11.4) with ESMTP id f8CML5m26251; Wed, 12 Sep 2001 15:21:05 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.3) id f8CMLKd01326; Wed, 12 Sep 2001 15:21:20 -0700 (PDT) (envelope-from marcel) Date: Wed, 12 Sep 2001 15:21:20 -0700 From: Marcel Moolenaar To: ia64@freebsd.org Cc: dfr@freebsd.org Subject: Can't build libficl.a Message-ID: <20010912152120.A1294@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.21i 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 Does anybody else see this, or do I have an incomplete tmake script: dhcp01% tmake ia64-unknown-linux-gcc -O -D__FreeBSD__ -U__linux__ -O -pipe -I/usr/src/sys/boot/ficl -I/usr/src/sys/boot/ficl/ia64 -I/usr/src/sys/boot/ficl/../common -c /usr/src/sys/boot/ficl/loader.c -o loader.o In file included from /usr/src/sys/boot/ficl/loader.c:36: /usr/src/sys/boot/ficl/../common/bootstrap.h:254: parse error before `struct' /usr/src/sys/boot/ficl/../common/bootstrap.h:254: warning: data definition has no type or storage class *** Error code 1 Stop in /usr/src/sys/boot/ficl. dhcp01% cat `which tmake` #!/bin/sh export CC='ia64-unknown-linux-gcc -O -D__FreeBSD__ -U__linux__' export LD=ia64-unknown-linux-ld export NM=ia64-unknown-linux-nm export RANLIB=ia64-unknown-linux-ranlib export OBJDUMP=ia64-unknown-linux-objdump export OBJCOPY=ia64-unknown-linux-objcopy export MACHINE_ARCH=ia64 make $@ -- 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 Sep 13 1:25: 3 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by hub.freebsd.org (Postfix) with ESMTP id 5A34E37B403; Thu, 13 Sep 2001 01:25:00 -0700 (PDT) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 15hRnu-00013W-0X; Thu, 13 Sep 2001 09:24:59 +0100 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f8D8Nhc83717; Thu, 13 Sep 2001 09:23:43 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 13 Sep 2001 09:23:11 +0100 (BST) From: Doug Rabson To: Marcel Moolenaar Cc: , Subject: Re: Can't build libficl.a In-Reply-To: <20010912152120.A1294@dhcp01.pn.xcllnt.net> Message-ID: <20010913092252.M398-100000@salmon.nlsystems.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 On Wed, 12 Sep 2001, Marcel Moolenaar wrote: > Does anybody else see this, or do I have an incomplete tmake script: > > dhcp01% tmake > ia64-unknown-linux-gcc -O -D__FreeBSD__ -U__linux__ -O -pipe -I/usr/src/sys/boot/ficl -I/usr/src/sys/boot/ficl/ia64 -I/usr/src/sys/boot/ficl/../common -c /usr/src/sys/boot/ficl/loader.c -o loader.o > In file included from /usr/src/sys/boot/ficl/loader.c:36: > /usr/src/sys/boot/ficl/../common/bootstrap.h:254: parse error before `struct' > /usr/src/sys/boot/ficl/../common/bootstrap.h:254: warning: data definition has no type or storage class > *** Error code 1 > > Stop in /usr/src/sys/boot/ficl. > > dhcp01% cat `which tmake` > #!/bin/sh > > export CC='ia64-unknown-linux-gcc -O -D__FreeBSD__ -U__linux__' > export LD=ia64-unknown-linux-ld > export NM=ia64-unknown-linux-nm > export RANLIB=ia64-unknown-linux-ranlib > export OBJDUMP=ia64-unknown-linux-objdump > export OBJCOPY=ia64-unknown-linux-objcopy > export MACHINE_ARCH=ia64 > make $@ You probably need to freshen the includes in your toolchain. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +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 Sep 15 15: 4:36 2001 Delivered-To: freebsd-ia64@freebsd.org Received: from denver.addr.com (de13a-add01-4501-004.arcommunications.net [216.168.78.100]) by hub.freebsd.org (Postfix) with ESMTP id E349A37B40A for ; Sat, 15 Sep 2001 15:03:55 -0700 (PDT) Received: (from root@localhost) by denver.addr.com (8.11.4/8.9.3) id f8FM3tj55026 for freebsd-ia64@FreeBSD.ORG; Sat, 15 Sep 2001 16:03:55 -0600 (MDT) (envelope-from support@addr.com) Received: from CHUNKY2.addr.com (den132.den.addr.com [192.168.1.132]) by denver.addr.com (8.11.4/8.9.3) with ESMTP id f8FM3r754934 for ; Sat, 15 Sep 2001 16:03:54 -0600 (MDT) (envelope-from support@addr.com) Message-Id: <5.0.0.25.2.20010915160349.018f8d50@denver.den.addr.com> X-Sender: chunky2@denver.den.addr.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 15 Sep 2001 16:03:53 -0600 To: freebsd-ia64@FreeBSD.ORG From: "Addr.com Web Hosting" Subject: Re: freebsd-ia64-digest V5 #26 In-Reply-To: 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 At 02:03 AM 9/4/2001 -0700, you wrote: >freebsd-ia64-digest Tuesday, September 4 2001 Volume 05 : Number 026 > > > >In this issue: >Re: ia64 + kse == not happy.. >Roadmap? >Re: ia64 + kse == not happy.. >Re: ia64 + kse == not^H^H^Hnow happy.. >Re: ia64 + kse == not^H^H^Hnow happy.. >Re: Roadmap? >Re: ia64 + kse == not happy.. >Re: Roadmap? >Re: Roadmap? >Re: Roadmap? >Re: ia64 + kse == not^H^H^Hnow happy.. >Re: ia64 + kse == not^H^H^Hnow happy.. >Re: ia64 + kse == not happy.. >Re: ia64 + kse == not happy.. >Re: ia64 + kse == not happy.. >Re: ia64 + kse == not happy.. > >---------------------------------------------------------------------- > >Date: Mon, 03 Sep 2001 01:40:53 -0700 >From: Peter Wemm >Subject: Re: ia64 + kse == not happy.. > >I finally solved it. I did a s/proc0/thread0/ in locore.s, forgetting that >proc0 is a structure, and thread0 is a pointer that requires indirection. > >Can somebody explain "rnatloc |= 0x1f8;" in vm_machdep.c:cpu_fork()? > >Anyway, ia64 + kse is happy so far. > >Some things I have noticed are missing: >setjmp/longjmp() (these look non-trivial given the register stack :-( ) >lots and lots and lots of minor things. :-) > >I have been considering taking a shot at porting loader(8) to run under >ski, and have *it* load the kernel via reading via sscdisk style >operations.. This should enable us to have better control of our >boot environment, symbol tables, etc. I think. :-] > >Peter Wemm wrote: > > After doing an alpha-style conversion of the ia64 code in the kse > > tree to get it to build/run, I have run into a brick wall. :-( > > > > loading kernel.kse... > > starting kernel... > > Memory descriptor count: 1 > > MD 0: type 7 pa 0x200000 cnt 0x4000 > > Descriptor 0 contains kernel > > Loading chunk before kernel: 0x200 / 0x500 > > Loading chunk after kernel: 0x819 / 0x4200 > > step 1: > > proc0uarea = 0xe000000000200000 > > proc0kstack = 0xe000000000201000 > > td_pcb = 0xe000000000204920 > > td_frame = 0xe0000000002046d0 > > pcb_sp = 0xe0000000002046c0 > > pcb_bspstore = 0xe000000000201000 > > made it to the end of ia64_init > > Copyright (c) 1992-2001 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD 5.0-CURRENT #4: Sun Sep 2 07:28:56 PDT 2001 > > peter@overcee.netplex.com.au:/home/peter/fbp4/kse/sys/ia64/compile/SIM > > real memory = 67108864 (65536K bytes) > > Physical memory chunk(s): > > 0x00209000 - 0x004fffff, 3108864 bytes (759 pages) > > 0x00819000 - 0x041f7fff, 60682240 bytes (14815 pages) > > avail memory = 60399616 (58984K bytes) > > made it to the end of cpu_startup > > linker_preload: in > > linker_preload: out > > mem: > > Calibrating clock(s) ... failed, using firmware default of 0 Hz > > > > fatal kernel trap: > > > > trap vector = 0x18 (General Exception) > > cr.iip = 0x0 > > cr.ipsr = 0x0 > > cr.isr = 0x0 > > cr.ifa = 0x0 > > cr.iim = 0x0 > > curthread = 0xe000000000815c20 > > pid = 0, comm = swapper > > > > Stopped at > > db> 20000e > > ? > > > > The actual change is at: > > http://people.freebsd.org/~peter/p4db/chv.cgi?CH=1344 > > > > And you can see any other changes at: > > http://people.freebsd.org/~peter/p4db/chb.cgi?FSPC=//depot/projects/kse/... > > > http://people.freebsd.org/~peter/p4db/chb.cgi?FSPC=//depot/projects/kse/sys/i > a64/... > > > > And, as announced elsewhere, the source can be had either from p4 if you > > have a freefall account, or from cvsup10.freebsd.org > (collection=p4-cvs-all, > > release=cvs). > > > > Key questions and changes: > > > > Under KSE, the U area is split into two entities. One contains struct > user, > > and the other contains the kernel stack + pcb. We have been putting > > the pcb at the *top* of the kernel stack on alpha / i386 since we have > > a grow-down stack and we slip in a guard page underneath it. I did this > > on the ia64 as well, but I think it may be a mistake as it looks like the > > grow-up and grow-down stacks will collide before then and cause a > bigger mess > . > > This can be easily backed out for testing, I'll try that soon. > > > > The old code did some odd things like subtracting 16 from the trapframe > > for various stack pointers. I'm not quite sure what is going on here > > but I tried to preserve it. I'd appreciate it if somebody could look over > > the changes to machdep.c / vm_machdep.c etc in this area. > > > > I would really appreciate it if somebody could look over my *.s changes. > > > > Any ideas? I'm falling asleep. :-) > > > > Cheers, > > -Peter > > -- > > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > > "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 > > > > > >Cheers, >- -Peter >- -- >Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au >"All of this is for nothing if we don't go to the stars" - JMS/B5 > >------------------------------ > >Date: Mon, 3 Sep 2001 02:15:05 -0700 >From: Marcel Moolenaar >Subject: Roadmap? > >Guys, > >HP has given me an old (A1 stepping) Itanium box to play with. I don't >know for how long, so I want to make the best use of it. Can someone >tell me where we are on ia64? > >Also, what's the story with gcc. It doesn't look like we have a working >ia64 compiler in the tree. Any ETA's on that front? > >I'll talk to the sysadmin next week, for I don't even know where the >box is. After that I'll play with it to figure out what I can do and >how best to do it. Any suggestions are welcome, > >- -- > Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net > >------------------------------ > >Date: Mon, 3 Sep 2001 11:35:02 +0100 (BST) >From: Doug Rabson >Subject: Re: ia64 + kse == not happy.. > >On Mon, 3 Sep 2001, Peter Wemm wrote: > > > I finally solved it. I did a s/proc0/thread0/ in locore.s, forgetting that > > proc0 is a structure, and thread0 is a pointer that requires indirection. > > > > Can somebody explain "rnatloc |= 0x1f8;" in vm_machdep.c:cpu_fork()? > >Each register has an associated bit which determines whether it contains a >valid value. These "not a thing" bits are accumulated into the ar.rnat >register as registers are written to the register stack. After stacking 63 >registers, the accumulated NaT bits are written to the stack. This happens >when the ar.bspstore pointer rolls past xxxxx1f8. To correctly fork a >child process, we must initialise its register stack and ar.rnat value so >that it contains reasonable values when its resumed. The correct ar.rnat >value is either the current process' ar.rnat if it has not yet been >flushed out since we entered the kernel or the value stored at rnatloc >otherwise. We determine this by checking to see if the current process' >ar.bspstore has gone past rnatloc. > > > > > Anyway, ia64 + kse is happy so far. > >:-) > > > > > Some things I have noticed are missing: > > setjmp/longjmp() (these look non-trivial given the register stack :-( ) > > lots and lots and lots of minor things. :-) > >I started working on this as part of an effort to get ficl working in the >EFI based loader. I got a bit stuck though - I probably should set up a >testcase that I can run under ski. > > > > > I have been considering taking a shot at porting loader(8) to run under > > ski, and have *it* load the kernel via reading via sscdisk style > > operations.. This should enable us to have better control of our > > boot environment, symbol tables, etc. I think. :-] > >Ooh. I want one. > >- -- >Doug Rabson Mail: dfr@nlsystems.com > Phone: +44 20 8348 6160 > >------------------------------ > >Date: Mon, 03 Sep 2001 03:58:38 -0700 >From: Peter Wemm >Subject: Re: ia64 + kse == not^H^H^Hnow happy.. > >Doug Rabson wrote: > > On Mon, 3 Sep 2001, Peter Wemm wrote: > > > > > I finally solved it. I did a s/proc0/thread0/ in locore.s, > forgetting that > > > proc0 is a structure, and thread0 is a pointer that requires indirection. > > > > > > Can somebody explain "rnatloc |= 0x1f8;" in vm_machdep.c:cpu_fork()? > > > > Each register has an associated bit which determines whether it contains a > > valid value. These "not a thing" bits are accumulated into the ar.rnat > > register as registers are written to the register stack. After stacking 63 > > registers, the accumulated NaT bits are written to the stack. This happens > > when the ar.bspstore pointer rolls past xxxxx1f8. To correctly fork a > > child process, we must initialise its register stack and ar.rnat value so > > that it contains reasonable values when its resumed. The correct ar.rnat > > value is either the current process' ar.rnat if it has not yet been > > flushed out since we entered the kernel or the value stored at rnatloc > > otherwise. We determine this by checking to see if the current process' > > ar.bspstore has gone past rnatloc. > >Aha! that make some sense. I'm starting to understand the ia64 manuals >now too. > >Question.. |= 1f8 depends on the stack starting at a xxxx000 address, right? >The original committed ia64+kse stuff that worked had the pcb >at the base of the stack, which meant that the bspstore started at some >address like xxxx680. That |= 1f8 isn't space for a full 63 registers. >Is it the address that is magic or the offset? Should it have been >+= 1f8 instead of |= ? > >In any case it shouldn't matter now since the bspstore starts at a xxx000 >address now in the kse kernel (the pcb is at the top-of-stack, above >trapframe and sp.) > >Speaking of sp, I've left some XXX comments about the -16 and +16 stuff... >What is going on there? > > td2->td_pcb->pcb_sp = (u_int64_t)p2tf - 16; > >Is that just to arrange stack alignment on 16 byte boundaries? ie: like >how we subtract sizeof(void *) in the i386 case but instead of 4 bytes >it is 16? > > > > Some things I have noticed are missing: > > > setjmp/longjmp() (these look non-trivial given the register stack :-( ) > > > lots and lots and lots of minor things. :-) > > > > I started working on this as part of an effort to get ficl working in the > > EFI based loader. I got a bit stuck though - I probably should set up a > > testcase that I can run under ski. > >Out of curiosity, what kind of lengths will setjmp/longjmp need to go >to? I'm suprised ddb hasn't exploded because of this.. > >If I had to guess, I would expect it to look a bit like the code in the >tail end of cpu_fork().. ie: copy base registers, turn off rse, flush >to backing store, turn rse back on? > > > > I have been considering taking a shot at porting loader(8) to run under > > > ski, and have *it* load the kernel via reading via sscdisk style > > > operations.. This should enable us to have better control of our > > > boot environment, symbol tables, etc. I think. :-] > > > > Ooh. I want one. > >Heh. dont we all. :-) > >Seriously, I think loader-under-ski is a good intermediate step before >loader-under-efi, unless the efi case is already close to working. Even >without ficl would be useful since we could have a real boot environment. > >Now to get the magic wand over to David O'Brien to get the gcc3 stuff with >basic ia64 support in it. :-) > >Cheers, >- -Peter >- -- >Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au >"All of this is for nothing if we don't go to the stars" - JMS/B5 > >------------------------------ > >Date: Mon, 3 Sep 2001 13:00:02 +0100 (BST) >From: Doug Rabson >Subject: Re: ia64 + kse == not^H^H^Hnow happy.. > >On Mon, 3 Sep 2001, Peter Wemm wrote: > > > Doug Rabson wrote: > > > On Mon, 3 Sep 2001, Peter Wemm wrote: > > > > > > > I finally solved it. I did a s/proc0/thread0/ in locore.s, > forgetting that > > > > proc0 is a structure, and thread0 is a pointer that requires > indirection. > > > > > > > > Can somebody explain "rnatloc |= 0x1f8;" in vm_machdep.c:cpu_fork()? > > > > > > Each register has an associated bit which determines whether it > contains a > > > valid value. These "not a thing" bits are accumulated into the ar.rnat > > > register as registers are written to the register stack. After > stacking 63 > > > registers, the accumulated NaT bits are written to the stack. This > happens > > > when the ar.bspstore pointer rolls past xxxxx1f8. To correctly fork a > > > child process, we must initialise its register stack and ar.rnat value so > > > that it contains reasonable values when its resumed. The correct ar.rnat > > > value is either the current process' ar.rnat if it has not yet been > > > flushed out since we entered the kernel or the value stored at rnatloc > > > otherwise. We determine this by checking to see if the current process' > > > ar.bspstore has gone past rnatloc. > > > > Aha! that make some sense. I'm starting to understand the ia64 manuals > > now too. > > > > Question.. |= 1f8 depends on the stack starting at a xxxx000 address, > right? > > The original committed ia64+kse stuff that worked had the pcb > > at the base of the stack, which meant that the bspstore started at some > > address like xxxx680. That |= 1f8 isn't space for a full 63 registers. > > Is it the address that is magic or the offset? Should it have been > > += 1f8 instead of |= ? > >Its the address thats magic. It doesn't matter where the stack started, >ar.rnat is always spilled at addresses ending in 0x1f8. > > > > > In any case it shouldn't matter now since the bspstore starts at a xxx000 > > address now in the kse kernel (the pcb is at the top-of-stack, above > > trapframe and sp.) > > > > Speaking of sp, I've left some XXX comments about the -16 and +16 stuff... > > What is going on there? > > > > td2->td_pcb->pcb_sp = (u_int64_t)p2tf - 16; > > > > Is that just to arrange stack alignment on 16 byte boundaries? ie: like > > how we subtract sizeof(void *) in the i386 case but instead of 4 bytes > > it is 16? > >The calling convention assumes that sp points at 16 bytes of scratch space >on function entry. The +/- 16s are there to ensure this. > > > > > > > Some things I have noticed are missing: > > > > setjmp/longjmp() (these look non-trivial given the register stack > :-( ) > > > > lots and lots and lots of minor things. :-) > > > > > > I started working on this as part of an effort to get ficl working in the > > > EFI based loader. I got a bit stuck though - I probably should set up a > > > testcase that I can run under ski. > > > > Out of curiosity, what kind of lengths will setjmp/longjmp need to go > > to? I'm suprised ddb hasn't exploded because of this.. > > > > If I had to guess, I would expect it to look a bit like the code in the > > tail end of cpu_fork().. ie: copy base registers, turn off rse, flush > > to backing store, turn rse back on? > >Its more similar to the code in cpu_switch() with some optimisations >assuming that we only ever longjmp to somewhere which is further up our >own stack. > > > > > > > I have been considering taking a shot at porting loader(8) to run under > > > > ski, and have *it* load the kernel via reading via sscdisk style > > > > operations.. This should enable us to have better control of our > > > > boot environment, symbol tables, etc. I think. :-] > > > > > > Ooh. I want one. > > > > Heh. dont we all. :-) > > > > Seriously, I think loader-under-ski is a good intermediate step before > > loader-under-efi, unless the efi case is already close to working. Even > > without ficl would be useful since we could have a real boot environment. > >The loader-under-efi case works well enough without ficl to get to the ok >prompt. Some stubs need to be filled in to get the elf loader going and I >need to write the magic trampoline code which turns on virtual addressing >and bounces into the kernel. > > > > > Now to get the magic wand over to David O'Brien to get the gcc3 stuff with > > basic ia64 support in it. :-) > >Hmm. 3.0.1 doesn't compile KDE2 AFAIK. > >- -- >Doug Rabson Mail: dfr@nlsystems.com > Phone: +44 20 8348 6160 > >------------------------------ > >Date: Mon, 3 Sep 2001 14:05:51 +0100 (BST) >From: Doug Rabson >Subject: Re: Roadmap? > >On Mon, 3 Sep 2001, Marcel Moolenaar wrote: > > > Guys, > > > > HP has given me an old (A1 stepping) Itanium box to play with. I don't > > know for how long, so I want to make the best use of it. Can someone > > tell me where we are on ia64? > > > > Also, what's the story with gcc. It doesn't look like we have a working > > ia64 compiler in the tree. Any ETA's on that front? > > > > I'll talk to the sysadmin next week, for I don't even know where the > > box is. After that I'll play with it to figure out what I can do and > > how best to do it. Any suggestions are welcome, > >I strongly suggest that you try upgrading to something more recent (B3 or >C0). A1 is old and buggy and I would prefer not to have to support it. >Linux has recently de-supported anything older than B3. > >Compiler wise, gcc 3.0.1 sounds promising apart from the fact that it >doesn't compile KDE2, which makes it unlikely to be imported any time >soon. > >- -- >Doug Rabson Mail: dfr@nlsystems.com > Phone: +44 20 8348 6160 > >------------------------------ > >Date: Mon, 3 Sep 2001 14:58:02 +0100 (BST) >From: Doug Rabson >Subject: Re: ia64 + kse == not happy.. > >On Mon, 3 Sep 2001, Doug Rabson wrote: > > > I started working on this as part of an effort to get ficl working in the > > EFI based loader. I got a bit stuck though - I probably should set up a > > testcase that I can run under ski. > >I managed to find my problem with longjmp - it was a result of wrongly >working around a difference between Intel's assembler and GAS. Hopefully, >this should get me a bit further with the EFI loader and will be suitable >for a libc setjmp/longjmp implementation. > >- -- >Doug Rabson Mail: dfr@nlsystems.com > Phone: +44 20 8348 6160 > >------------------------------ > >Date: Mon, 3 Sep 2001 09:15:31 -0500 >From: Brent Casavant >Subject: Re: Roadmap? > >On Mon, 3 Sep 2001, Marcel Moolenaar wrote: > > > HP has given me an old (A1 stepping) Itanium box to play with. I don't > > know for how long, so I want to make the best use of it. Can someone > > tell me where we are on ia64? > >Marcel, > >You should also know that late last year these boxes (I imagine you >have what is known as "Big Sur", up to a 2P system) had a significant >upgrade that replaced pretty much everything except the case, power >supply, and fans. Oh, and the video card. That means that if you >manage to get ahold of B3 or C0 processors they may or may not >work correctly with the older motherboard/etc. Someone else may have >experience in this area and be able to confirm whether newer >processors will work. > >Brent > >- -- >Brent Casavant http://www.scc.net/~bcasavan >b.j.casavant@ieee.org -.- -.. ..... . -- -... > >------------------------------ > >Date: Mon, 3 Sep 2001 10:10:26 -0700 >From: Marcel Moolenaar >Subject: Re: Roadmap? > >On Mon, Sep 03, 2001 at 02:05:51PM +0100, Doug Rabson wrote: > > On Mon, 3 Sep 2001, Marcel Moolenaar wrote: > > > > I strongly suggest that you try upgrading to something more recent (B3 or > > C0). A1 is old and buggy and I would prefer not to have to support it. > > Linux has recently de-supported anything older than B3. > >No deal here. HP has explicitly stated that a processor upgrade is >out of the question. The fact that I happen to have an A1 doesn't >mean we need to support it. If FreeBSD is itself stable enough, I >can more easily hijack one of the newer machines we have in use by >using a diskless configuration. > >- -- > Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net > >------------------------------ > >Date: Mon, 3 Sep 2001 10:14:49 -0700 >From: Marcel Moolenaar >Subject: Re: Roadmap? > >On Mon, Sep 03, 2001 at 09:15:31AM -0500, Brent Casavant wrote: > > > > You should also know that late last year these boxes (I imagine you > > have what is known as "Big Sur", up to a 2P system) had a significant >[snip] > >I don't think it's a Big Sur. I believe it's a Lion box. But let me >talk to the sysadmin first. > >- -- > Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net > >------------------------------ > >Date: Mon, 03 Sep 2001 20:44:55 -0700 (PDT) >From: John Baldwin >Subject: Re: ia64 + kse == not^H^H^Hnow happy.. > >On 03-Sep-01 Doug Rabson wrote: > > On Mon, 3 Sep 2001, Peter Wemm wrote: > >> Now to get the magic wand over to David O'Brien to get the gcc3 stuff with > >> basic ia64 support in it. :-) > > > > Hmm. 3.0.1 doesn't compile KDE2 AFAIK. > >Or kernels for that matter. It does evil things like convert 'printf("blah")' >to 'puts("blah")' which doesn't work well for a kernel environment that >doesn't >have puts() or putchar(). :-/ > >- -- > >John Baldwin -- http://www.FreeBSD.org/~jhb/ >PGP Key: http://www.baldwin.cx/~john/pgpkey.asc >"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > >------------------------------ > >Date: Mon, 03 Sep 2001 21:22:21 -0700 >From: Peter Wemm >Subject: Re: ia64 + kse == not^H^H^Hnow happy.. > >John Baldwin wrote: > > > > On 03-Sep-01 Doug Rabson wrote: > > > On Mon, 3 Sep 2001, Peter Wemm wrote: > > >> Now to get the magic wand over to David O'Brien to get the gcc3 > stuff with > > >> basic ia64 support in it. :-) > > > > > > Hmm. 3.0.1 doesn't compile KDE2 AFAIK. > > > > Or kernels for that matter. It does evil things like convert > 'printf("blah") > ' > > to 'puts("blah")' which doesn't work well for a kernel environment that > doesn > 't > > have puts() or putchar(). :-/ > >This is easily fixed. :-) > >Cheers, >- -Peter >- -- >Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au >"All of this is for nothing if we don't go to the stars" - JMS/B5 > >------------------------------ > >Date: Mon, 03 Sep 2001 21:23:22 -0700 >From: Peter Wemm >Subject: Re: ia64 + kse == not happy.. > >Doug Rabson wrote: > > On Mon, 3 Sep 2001, Doug Rabson wrote: > > > > > I started working on this as part of an effort to get ficl working in the > > > EFI based loader. I got a bit stuck though - I probably should set up a > > > testcase that I can run under ski. > > > > I managed to find my problem with longjmp - it was a result of wrongly > > working around a difference between Intel's assembler and GAS. Hopefully, > > this should get me a bit further with the EFI loader and will be suitable > > for a libc setjmp/longjmp implementation. > >Do you have something that you could check in in some form? Even if it >doesn't work yet, just having *something* would be nice. > >Cheers, >- -Peter >- -- >Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au >"All of this is for nothing if we don't go to the stars" - JMS/B5 > >------------------------------ > >Date: Tue, 4 Sep 2001 08:20:46 +0100 (BST) >From: Doug Rabson >Subject: Re: ia64 + kse == not happy.. > >On Mon, 3 Sep 2001, Peter Wemm wrote: > > > Doug Rabson wrote: > > > On Mon, 3 Sep 2001, Doug Rabson wrote: > > > > > > > I started working on this as part of an effort to get ficl working > in the > > > > EFI based loader. I got a bit stuck though - I probably should set up a > > > > testcase that I can run under ski. > > > > > > I managed to find my problem with longjmp - it was a result of wrongly > > > working around a difference between Intel's assembler and GAS. Hopefully, > > > this should get me a bit further with the EFI loader and will be suitable > > > for a libc setjmp/longjmp implementation. > > > > Do you have something that you could check in in some form? Even if it > > doesn't work yet, just having *something* would be nice. > >I chedked it in yesterday. I'm planning to play with loader a bit this >morning - if that works now, I'll check what I have there in too. > >- -- >Doug Rabson Mail: dfr@nlsystems.com > Phone: +44 20 8348 6160 > >------------------------------ > >Date: Tue, 04 Sep 2001 00:31:29 -0700 >From: Peter Wemm >Subject: Re: ia64 + kse == not happy.. > >Doug Rabson wrote: > > On Mon, 3 Sep 2001, Peter Wemm wrote: > > > > > Doug Rabson wrote: > > > > On Mon, 3 Sep 2001, Doug Rabson wrote: > > > > > > > > > I started working on this as part of an effort to get ficl > working in t > he > > > > > EFI based loader. I got a bit stuck though - I probably should > set up a > > > > > testcase that I can run under ski. > > > > > > > > I managed to find my problem with longjmp - it was a result of wrongly > > > > working around a difference between Intel's assembler and GAS. > Hopefully, > > > > this should get me a bit further with the EFI loader and will be > suitable > > > > for a libc setjmp/longjmp implementation. > > > > > > Do you have something that you could check in in some form? Even if it > > > doesn't work yet, just having *something* would be nice. > > > > I chedked it in yesterday. I'm planning to play with loader a bit this > > morning - if that works now, I'll check what I have there in too. > >Even if it doesn't, it would be nice if you could check it in.. That would >save a lot of duplicated work for getting a ski-based hack to run. (I dont >have real hardware yet). > >Cheers, >- -Peter >- -- >Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au >"All of this is for nothing if we don't go to the stars" - JMS/B5 > >------------------------------ > >Date: Tue, 4 Sep 2001 10:01:48 +0100 (BST) >From: Doug Rabson >Subject: Re: ia64 + kse == not happy.. > > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. > Send mail to mime@docserver.cac.washington.edu for more info. > >- --0-1211071170-999594108=:9620 >Content-Type: TEXT/PLAIN; charset=US-ASCII > >On Tue, 4 Sep 2001, Peter Wemm wrote: > > > Doug Rabson wrote: > > > On Mon, 3 Sep 2001, Peter Wemm wrote: > > > > > > > Doug Rabson wrote: > > > > > On Mon, 3 Sep 2001, Doug Rabson wrote: > > > > > > > > > > > I started working on this as part of an effort to get ficl > working in t > > he > > > > > > EFI based loader. I got a bit stuck though - I probably should > set up a > > > > > > testcase that I can run under ski. > > > > > > > > > > I managed to find my problem with longjmp - it was a result of > wrongly > > > > > working around a difference between Intel's assembler and GAS. > Hopefully, > > > > > this should get me a bit further with the EFI loader and will be > suitable > > > > > for a libc setjmp/longjmp implementation. > > > > > > > > Do you have something that you could check in in some form? Even if it > > > > doesn't work yet, just having *something* would be nice. > > > > > > I chedked it in yesterday. I'm planning to play with loader a bit this > > > morning - if that works now, I'll check what I have there in too. > > > > Even if it doesn't, it would be nice if you could check it in.. That would > > save a lot of duplicated work for getting a ski-based hack to run. (I dont > > have real hardware yet). > >Ok, apart from this ficl patch which I sent to you and dcs, I'm done. I >have a loader which 'works' both with and without ficl. You will need to >freshen your copy of libstand.a - I suggest using the handy attached >ia64-make script for this purpose. > >Index: words.c >=================================================================== >RCS file: /home/ncvs/src/sys/boot/ficl/words.c,v >retrieving revision 1.35 >diff -u -r1.35 words.c >- --- words.c 2001/05/27 16:30:10 1.35 >+++ words.c 2001/09/04 08:26:02 >@@ -1147,7 +1147,7 @@ > static void elseCoIm(FICL_VM *pVM) > { > CELL *patchAddr; >- - int offset; >+ FICL_INT offset; > FICL_DICT *dp = ficlGetDict(); > > assert(pBranchParen); > >- -- >Doug Rabson Mail: dfr@nlsystems.com > Phone: +44 20 8348 6160 > > >- --0-1211071170-999594108=:9620 >Content-Type: TEXT/PLAIN; charset=US-ASCII; name=ia64-make >Content-Transfer-Encoding: BASE64 >Content-ID: <20010904100148.M9620@salmon.nlsystems.com> >Content-Description: >Content-Disposition: attachment; filename=ia64-make > >ZXhwb3J0IENDPSdpYTY0LXVua25vd24tbGludXgtZ2NjIC1PIC1EX19GcmVl >QlNEX18gLVVfX2xpbnV4X18nDQpleHBvcnQgTEQ9aWE2NC11bmtub3duLWxp >bnV4LWxkDQpleHBvcnQgTk09aWE2NC11bmtub3duLWxpbnV4LW5tDQpleHBv >cnQgUkFOTElCPWlhNjQtdW5rbm93bi1saW51eC1yYW5saWINCmV4cG9ydCBP >QkpEVU1QPWlhNjQtdW5rbm93bi1saW51eC1vYmpkdW1wDQpleHBvcnQgT0JK >Q09QWT1pYTY0LXVua25vd24tbGludXgtb2JqY29weQ0KZXhwb3J0IE1BQ0hJ >TkVfQVJDSD1pYTY0DQptYWtlICRADQo= >- --0-1211071170-999594108=:9620-- > >------------------------------ > >End of freebsd-ia64-digest V5 #26 >********************************* > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with unsubscribe freebsd-ia64-digest in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message