From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Mosberger Newsgroups: gmane.linux.ports.ia64,gmane.lisp.guile.devel Subject: Re: Guile garbage collector on ia64-linux Date: Wed, 25 Jun 2003 09:58:07 -0700 Sender: linux-ia64-admin@linuxia64.org Message-ID: <16121.54431.794996.977946@napali.hpl.hp.com> References: <15307.10445.674412.197780@napali.hpl.hp.com> Reply-To: davidm@hpl.hp.com NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1056560466 6484 80.91.224.249 (25 Jun 2003 17:01:06 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 25 Jun 2003 17:01:06 +0000 (UTC) Cc: David Mosberger , linux-ia64@linuxia64.org, Original-X-From: linux-ia64-admin@linuxia64.org Wed Jun 25 19:01:03 2003 Return-path: Original-Received: from panoramix.vasoftware.com ([198.186.202.147] helo=externalmx.vasoftware.com) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19VDdn-0001g6-00 for ; Wed, 25 Jun 2003 19:01:03 +0200 Original-Received: from localhost ([127.0.0.1]:59123 helo=panoramix.vasoftware.com) by externalmx.vasoftware.com with esmtp (Exim 4.20 #1 (Debian)) id 19VDcs-0003gz-5P; Wed, 25 Jun 2003 10:00:06 -0700 Original-Received: from palrel13.hp.com ([156.153.255.238]:56113) by externalmx.vasoftware.com with esmtp (Exim 4.20 #1 (Debian)) id 19VDcb-0003cr-BK for ; Wed, 25 Jun 2003 09:59:49 -0700 Original-Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by palrel13.hp.com (Postfix) with ESMTP id E14FC1C00F51; Wed, 25 Jun 2003 09:58:17 -0700 (PDT) Original-Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by hplms2.hpl.hp.com (8.12.9/8.12.9/HPL-PA Hub) with ESMTP id h5PGwGeb025380; Wed, 25 Jun 2003 09:58:17 -0700 (PDT) Original-Received: from napali.hpl.hp.com (localhost [127.0.0.1]) by napali.hpl.hp.com (8.12.3/8.12.3/Debian-5) with ESMTP id h5PGwGrK028846; Wed, 25 Jun 2003 09:58:16 -0700 Original-Received: (from davidm@localhost) by napali.hpl.hp.com (8.12.3/8.12.3/Debian-5) id h5PGw7Bl028840; Wed, 25 Jun 2003 09:58:07 -0700 Original-To: stefan In-Reply-To: X-Mailer: VM 7.07 under Emacs 21.2.1 X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ X-EA-Verified: externalmx.vasoftware.com 19VDcb-0003cr-BK 4142ee73f5c8710bd452bb1cb7c21f8d X-Spam-Score: -1.0 Errors-To: linux-ia64-admin@linuxia64.org X-BeenThere: linux-ia64@linuxia64.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Linux Kernel Discussions on the IA-64 Platform List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.linux.ports.ia64:1973 gmane.lisp.guile.devel:2577 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2577 >>>>> On Wed, 25 Jun 2003 04:58:59 +0200 (CEST), stefan said: Stefan> * have some header where ucontext_t is declared but Stefan> setcontext()/getcontext() is not -> so we can redeclare it Stefan> to make getcontext() return the 'struct rv'. One way of achieving this is to do: #define getcontext hide_getcontext #include #undef getcontext Andreas suggested another method. Both have their ups and downs. Stefan> * determination of the size and location of the backing Stefan> store; this has been previously achieved by: Stefan> ctx.uc_mcontext.sc_ar_bsp -> the top Stefan> __libc_ia64_register_backing_store_base -> the bottom Newer Stefan> glibc headers don't have 'sc_ar_bsp', but things like Stefan> 'ar_bsp_base' or 'ar_bspstore'. Can something in the Stefan> structure ucontext_t be used to achieve the same? Will this Stefan> change often in the future? This doesn't sound right. There were no member-name changes "struct sigcontext". I just checked the current libc CVS tree and it has: struct sigcontext { : unsigned long int sc_ar_bsp; /* backing store pointer */ So I don't know why this isn't working for you. What distro are you using? --david