From owner-freebsd-hackers Wed Nov 29 13:34:15 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA22182 for hackers-outgoing; Wed, 29 Nov 1995 13:34:15 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA22005 ; Wed, 29 Nov 1995 13:31:10 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA28672; Wed, 29 Nov 1995 14:24:59 -0700 From: Terry Lambert Message-Id: <199511292124.OAA28672@phaeton.artisoft.com> Subject: Re: Enough already! (Was: Where is the documentation for ibcs2?) To: grog@lemis.de Date: Wed, 29 Nov 1995 14:24:59 -0700 (MST) Cc: sos@freebsd.org, hackers@freebsd.org In-Reply-To: <199511291004.LAA16724@allegro.lemis.de> from "Greg Lehey" at Nov 29, 95 11:04:35 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1547 Sender: owner-hackers@freebsd.org Precedence: bulk > Here's the gdb code to fetch registers from the u area, somewhat > simplified (BTW, Terry suggested that this should be done with /proc, > not with ptrace(). This won't work, because this is a COFF > executable, and I shudder at the consequences of trying to tell an > SVR3 executable about FreeBSD): Wrong /dev/proc. Use an "IBCS2" specific /dev/proc. Yeah, you'd have to write one. > Well, I think I have to disagree about the value of 10%, but I agree > that there's still a lot to be done. As I said in a previous message, > I have a number of pieces there for the taking, including the complete > GNU C library for SCO (and it works!). It's not in shared library > format at the moment, but it shouldn't be that much of a problem if > somebody's interested. A shared library replacement for SCO has to map at the expected addresses and act quite differently. The mapping has to be established elsewhere than ctr0.o. Making an SCO compatible shared library will be a task. It will be compiler dependent, and it will have to have a sorted index facility to implement object order (that order derived from an executable linked with the shared lib *or* from an SCO system. I don't know whether or not that data is considered proprietary. I know that 'nm' data is in fact considered proprietary, as I expect the Lesstif project to discover once they've completed Lesstif and release it. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.