Date: Wed, 8 May 1996 12:32:03 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: amora@obelix.cica.es (Jesus A. Mora Marin) Cc: terry@lambert.org, freebsd-questions@freebsd.org Subject: Re: troubles with IBCS emulation Message-ID: <199605081932.MAA26662@phaeton.artisoft.com> In-Reply-To: <199605081300.PAA04660@obelix.cica.es> from "Jesus A. Mora Marin" at May 8, 96 03:00:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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'. But GDB binaries for SCO are available from the net (sorry, I use SCO only to generate ABI test programs, so I have no idea where). > 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? As far as you're concerned, the emulated exec call is occuring on an SCO machine. I believe SDB will follow an exec; I know that the coff gdb will, or you can alter the exec argument to send it gdb with the rest as an argument. This is a data hack that is scary, but perfectly resonable to do (since after a for, you are working in an address space it's OK to destroy). > 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? Yes, in theory. I have never done it. > Would it work at all? Yes, in theory. > > 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". 100 sounds like a simple variation on MMAP. 104 might be nearly impossible, depending on what exactly is meant by that. > > 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. There is a 4.4 book out, which credits the main VM and system architects and others from the FreeBSD camp. I don't know if it covers FreeBSD itself in any detail. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605081932.MAA26662>