From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: stefan Newsgroups: gmane.linux.ports.ia64,gmane.lisp.guile.devel Subject: Re: Guile garbage collector on ia64-linux Date: Wed, 25 Jun 2003 20:03:15 +0200 (CEST) Sender: linux-ia64-admin@linuxia64.org Message-ID: References: <16121.54431.794996.977946@napali.hpl.hp.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1056564511 28100 80.91.224.249 (25 Jun 2003 18:08:31 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 25 Jun 2003 18:08:31 +0000 (UTC) Cc: linux-ia64@linuxia64.org, Original-X-From: linux-ia64-admin@linuxia64.org Wed Jun 25 20:08:29 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 19VEga-0007Fp-00 for ; Wed, 25 Jun 2003 20:08:00 +0200 Original-Received: from localhost ([127.0.0.1]:47336 helo=panoramix.vasoftware.com) by externalmx.vasoftware.com with esmtp (Exim 4.20 #1 (Debian)) id 19VEfh-0002R2-C5; Wed, 25 Jun 2003 11:07:05 -0700 Original-Received: from obh.snafu.de ([213.73.92.34]:2755) by externalmx.vasoftware.com with esmtp (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 4.20 #1 (Debian)) id 19VEfR-0003od-BQ for ; Wed, 25 Jun 2003 11:06:49 -0700 Original-Received: from p-164-156.zrz.tu-berlin.de ([130.149.164.156] helo=bono) by obh.snafu.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 19VEfO-000Fdn-00; Wed, 25 Jun 2003 20:06:47 +0200 Original-Received: from localhost ([127.0.0.1] ident=ela) by bono with esmtp (Exim 3.36 #1) id 19VEc0-00009b-00; Wed, 25 Jun 2003 20:03:16 +0200 X-X-Sender: stefan@bono.reversers.net Original-To: David Mosberger In-Reply-To: <16121.54431.794996.977946@napali.hpl.hp.com> X-EA-Verified: externalmx.vasoftware.com 19VEfR-0003od-BQ 6866b6f82f70db9e60c8a735c463a2aa X-Spam-Score: -2.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:1974 gmane.lisp.guile.devel:2578 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:2578 On Wed, 25 Jun 2003, David Mosberger wrote: > >>>>> 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? I've been using the Compaq testdrive account 'SuSE Linux 7.2a (ia64) - Kernel 2.4.4-SMP (2)' ... looks like a glibc 2.2.2 Well may be too an old one. Thanks for the quick response, stefan@lkcc.org