Date: Wed, 8 May 1996 15:00:38 +0200 (MET) From: "Jesus A. Mora Marin" <amora@obelix.cica.es> To: terry@lambert.org (Terry Lambert) Cc: freebsd-questions@freebsd.org Subject: Re: troubles with IBCS emulation Message-ID: <199605081300.PAA04660@obelix.cica.es> In-Reply-To: <199605032222.PAA14979@phaeton.artisoft.com> from "Terry Lambert" at May 3, 96 03:22:21 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Terry!
I have contacted with Soren Schmidt, as you suggested. He replied:
} Hmm, The iBCS2 emulator that Sean & I wrote has been replaced with a
} hacked up version of the NetBSD iBCS2 emulator, so there is no
} (official) fixes to your problems other than installing FreeBSD-current
} and trying out the new emulator. I suggest you contact swallace@FreeBSD.org
} as it is his baby now :)
So further discussion about this trouble is of no use, until I try the new
emulator. I have asked Jordan for the SNAP CD-ROM announced some time ago
and maybe I'll give it a chance. Otherwise, I'll wait for the regular
subscription CD-ROM. Nevertheless, some final comments, just for fun:
> Use an SCO copy of GDB instead, of course. It will understand COFF, and
> since we can run it under IBCS2, it will run.
Hmm... SCO is not smart enough to include `gdb'. It uses `adb' (an
assembler-only debugger, for hard-cored hackers) and `sdb' (a symbolic debugger
lightyears behind gdb). Well I can get both of them, but how should you trace
the sqlexec process? If you run it standalone it simply exits. To make its
work, I guess, it must be child of a process that previously has set up an IPC
mechanism -I think it's a pipe for sqlexec, shared memory for other DBM engines-.
You can debug a running process in FreeBSD with GDB, but I am not aware that
`sbd' can do that. I should better read the sdb manpage. By the way: can gdb be
recompiled in order to understand COFF binaries under FreeBSD? Would it work
at all?
> This would require an SCO system to test; sorry, I don't have one.
Nor I do, and no intention of installing forty diskettes. Also, I have browsed
old docs and can now confirm you that SCO Unix -I'm always talking about SVR3
versions- doesn't have a lstat(2) syscall: in fact, symbolic links were
introduced in SVR4 -AT&T was never very innovative-.
> The bad thing is, BSD would need to support the Xenix 386 sysi86()
> call to support running 286emul as a 386 Xenix app.
>
> I have a licensed version of Xenix 386 somewhere, actually, so a
> loader wouldn't be too hard to build. Supporting the system call
> for 286-type segments would be much, much harder. 8-(.
And it doesn't worth the effort needed, I think. I wonder how many people is
still running that venerable stuff out there. Not many, I guess. So, let's
forget about this.
>> IBCS2: 'sysi86' function 104(0x68) not implemented yet
>> IBCS2: 'sysi86' function 100(0x64) not implemented yet
Just FYI, I've seen <sys/sysi86.h> and function 104 (SI86CHIDT) is described
"set user level int 0xf0, ... 0xff handlers", and function 100 (SI86SHFIL) is
"map a file into addr space of a proc".
> System call tables are referenced indirectly through the proc struct,
> so each process can, theoretically, be running using a different ABI
> compatability. Not that anyone would need to do this.
A very nice solution. I have asked Jordan whether a guide to kernel inner
workings and design is projected. I am VERY interested in this subject. I got
the book about 4.3 BSD [Leffler, McKusick et al.] many years ago, and is
out of date when compared to FreeBSD.
So many thanks for this discussion, Terry. See you again and let's keep on
enjoying FreeBSD!
Jesus A. Mora
amora@obelix.cica.es
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605081300.PAA04660>