Date: Wed, 29 Nov 1995 11:04:35 +0100 (MET) From: grog@lemis.de (Greg Lehey) To: sos@freebsd.org Cc: hackers@freebsd.org (FreeBSD Hackers) Subject: Re: Enough already! (Was: Where is the documentation for ibcs2?) Message-ID: <199511291004.LAA16724@allegro.lemis.de> In-Reply-To: <199511290837.JAA01196@ra.dkuug.dk> from "sos@freebsd.org" at Nov 29, 95 09:37:44 am
next in thread | previous in thread | raw e-mail | index | archive | help
sos@freebsd.org writes:
>
> In reply to Greg Lehey who wrote:
>>
>>> You need a COFF debugger, preferably compile FreeBSD native...
>>
>> You don't understand. Watch my fingers: "it doesn't get as far as
>> being executed." I have a gdb compiled under SCO 3.2.2 (by chance),
>> though it still doesn't like the "user area" of the emulator: ptrace()
>> bombs out looking for the eip value.
>
> Hmm, I'm not sure who it is that don't understand here...
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):
fetch_register (regno)
int regno;
{
/* This isn't really an address. But ptrace thinks of it as one. */
CORE_ADDR regaddr;
char buf[MAX_REGISTER_RAW_SIZE];
char mess[128]; /* For messages */
register int i;
/* Offset of registers within the u area. */
unsigned int offset;
offset = U_REGS_OFFSET;
regaddr = register_addr (regno, offset);
*(PTRACE_XFER_TYPE *) &buf[i] = ptrace (PT_READ_U, inferior_pid,
(PTRACE_ARG3_TYPE) regaddr, 0);
supply_register (regno, buf);
}
I don't have an SCO machine up and running at the moment, but I've
seen this problem before: register_addr itself calls ptrace() to find
the address of the saved register block, and it's wrong (typically
contains 0). If you *really*, *really* find this important, I'll drag
out the disk and fire her up.
>> To be more specific, you can't debug the vi problem because it bombs
>> out of execve (look at the end of the function source: if things go
>> wrong, it sends a SIGABRT). This is reasonable, since COFF
>> effectively specifies multiple text segments in the header, and the
>> file for one of them was missing. Possibly, though, we should
>> consider a message stating the name of the missing file if it wasn't
>> the executable itself.
>
> Look at how our execution classes works, and you will now why this is
> so. If you miss a shared lib it should say so though (at least in
> the old iBCS2 code).
Hmmm. Certainly in this case we're not getting a message, though we
are missing a shared library. And we are getting a SIGABRT, and
that's what execve does if it can't get the process to run. Possibly
the causes are more complex than that, but I can't be bothered to go
through the code. Your turn now :-)
> I'll repeat again :
> The kernel part of the iBCS2 emulation is only say 10% of what is
> needed to run iBCS2/SCO apps, we must have a compatibel shell, ed
> sed, echo, awk, and and and, or its just going to break one
> way or another. We must have our own legal shared libs (plus an
> environment to make these in case things change). Then we also
> must have a "custom" util to install the stuff, plus whatever
> config files, setups, filestructure etc etc etc that the SCO
> apps expects from the system.
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.
>> So when are we going for SVR4.2 emulation?
>
> Ha!, I've had my system run NCR svr4 binaries for almost a year
> now, but there are even more things to make SVR4 run that
> running iBCS2 (and besides my code for this doesn't work
> with the iBCS2 stuff we now have from NetBSD, it is nicely
> integrated into the "original" iBCS2 emulator).
Well, it's a start. What was wrong with the "original" emulator?
Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511291004.LAA16724>