Re: SVR4 Emulation [was Re: iBCS status?]
On Wed, Jun 07, 2000 at 10:24:15PM -0400, Matthew Emmerton wrote: brandelf will really understand any brand at all; We just add special cases to suppress the need for -f for "known" brands. As it happens, though, there's no reason why you can't run "brandelf -f -t BOGUS-BOGUS foo" and have it put a BOGUS-BOGUS brand into an ELF object called foo. What may compound the problem is if multiple ELF formats use the same brand, or none at all (as is the case with SCO ODT5 binaries.) Well, yes, that's the thing - Branding is, AFAICT, specific to FreeBSD and Linux ELF; All other OSs need either a heuristic to select the appropriate emulator (for example, the pathname to the ELF interpreter in the executable, which doesn't always work), or an explicit branding, or an appropriate setting of the kern.fallback_elf_brand sysctl MIB variable. Even more interesting is the SCO document on how ELFs are pseudo-branded. OpenServer 5: No brand, but have a 28-byte NOTE field. UnixWare 7: No brand, but have one of the flags set in the FLAG field. (I couldn't find anything more specific than this.) -- Matthew Emmerton GSI Computer Services +1 (800) 217-5409 (Canada) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SVR4 Emulation [was Re: iBCS status?]
On Tue, Jun 13, 2000 at 11:45:28PM -0400, Matthew Emmerton wrote: Even more interesting is the SCO document on how ELFs are pseudo-branded. OpenServer 5: No brand, but have a 28-byte NOTE field. UnixWare 7: No brand, but have one of the flags set in the FLAG field. (I couldn't find anything more specific than this.) Ah, thanks for that - I'll note it away for not-too-distant future reference. The emulator structures at the moment look for the ELF interpreter and try to switch on that, but I think that'll bite us with SysVR4 because all the SysVR4 OSs will use the same ELF interpreter pathname, and because it doesn't work as a discriminator anyway (Solaris executables still need to be specifically branded, or you need to rely on kern.fallback_elf_brand). Additional discriminators like this (even if they're bodgy crap ones) are useful things to know about. - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SVR4 Emulation [was Re: iBCS status?]
In article [EMAIL PROTECTED], Dan Nelson [EMAIL PROTECTED] wrote: Hmm. So does this mean that SVR4-compliant programs must be dynamically-linked? Yes. The specification says that statically-linked programs are not compliant. Is there any recommendations on how an OS should supply an SVR4 libc to an SVR4 application when the OS itself may not be SVR4-compliant? Theoretically, you wouldn't need any kernel-level emulation at all if you provided the right libc. But of course it's not really SVR4 you want to emulate -- it's UnixWare or OpenServer or something else that has lots of extra interfaces which are outside the ABI specification. Overall I think it's easier to use the vendor's libraries and do the emulation at the kernel level, as we do now. And this doesn't address any libraries other than libc, I suppose? Right. Sounds like trying to emulate "SVR4" in itself isn't sufficient. We can still call the kld svr4.ko, but it's really doing SCO/SolarisX86 syscall emulation. Yep. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SVR4 Emulation [was Re: iBCS status?]
In the last episode (Jun 07), Matthew Emmerton said: And while we're on the topic, has anyone looked at the svr4 emulation stuff for Linux, most notably Debian? According to this link (http://www.debian.org/Packages/stable/otherosfs/ibcs-base.html), it has SCO SVR3 as well as SCO ODT5 (SVR4) support. This may have already covered a lot of the hairy issues (like syscall mappings). I realize it is dated (late 97), but anything helpful is better than nothing :) I've looked at the linuxibcs stuff, dated 1998 (it does ibcs and svr4) but don't really want to copy code outright, since it's GPL'ed. The basic stuff like syscall mappings is already covered by our existing svr4 code. The hardest part is adding support for SCO oddball syscalls, like xstat, which can return up to 4 different "struct stat"s depending on what you pass into it. It's hard because SCO doesn't document any of this. You have to root through headers trying to figure out what structures are used when. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SVR4 Emulation [was Re: iBCS status?]
On Wed, Jun 07, 2000 at 09:46:26AM -0500, Dan Nelson wrote: It's hard because SCO doesn't document any of this. You have to root through headers trying to figure out what structures are used when. How do you think the rest of the emulator has been written? :-) Ok -- I envisaged that there'd be a difficulty with different SysV vendors who used different semantics for the same syscalls, or different syscall numbering schemes. "It could happen!" (and, as we can see, it probably has). To fix it in as painless a way as possible, I'm envisaging something along the lines of this: * The existing svr4 KLD module, which implements the guts of the emulator; and * Additional much, much smaller modules which implement the differences between the "base" svr4 and wierd oddball variants. The additional modules would be dependent on the base module. Each one would have its own syscall table, but most of the entries in it would point to symbols which are defined in the base module. Only the system calls which have totally different semantics would need to be defined separately. Of course, this also gives us a simple way to renumber syscalls. Each variant would have its own ELF brand to aid the selection of the correct API. The files used to implement this would be in subdirectories of src/sys/svr4 and src/sys/i386/svr4, each of which would contain a *_sysvec.c file, a syscalls.master file, and the support .h files needed to glue it all together. The result of running "make" in src/modules/svr4 would be a base KLD plus several smaller flavour- specific KLDs. Note that syscall numbering isn't the only thing I can see that'll be different between "flavours" of SysVR4. Things like ioctl() commands, signal numbers, and basically all the other things the emulator translates could exhibit minor differences between flavours, but the bulk of it should be the same from vendor to vendor. Comments? - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SVR4 Emulation [was Re: iBCS status?]
To fix it in as painless a way as possible, I'm envisaging something along the lines of this: * The existing svr4 KLD module, which implements the guts of the emulator; and * Additional much, much smaller modules which implement the differences between the "base" svr4 and wierd oddball variants. Modularity seems to be the most logical way to go. The ibcs2 stuff was sortof written like this (ibcs2.ko, and then ibcs2_coff.ko handled all the COFF-specific stuff; yes, it's quite different, but the concept was similar.) Each variant would have its own ELF brand to aid the selection of the correct API. Makes sense. On a related note, I'm curious to see how this will integrate into existing non-kernel tools. For example, truss and brandelf) only understand BSD and Linux ELF binaries, and will require modifications to identify all the different brands. What may compound the problem is if multiple ELF formats use the same brand, or none at all (as is the case with SCO ODT5 binaries.) -- Matthew Emmerton GSI Computer Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SVR4 Emulation [was Re: iBCS status?]
On Wed, Jun 07, 2000 at 10:24:15PM -0400, Matthew Emmerton wrote: Each variant would have its own ELF brand to aid the selection of the correct API. Makes sense. On a related note, I'm curious to see how this will integrate into existing non-kernel tools. For example, truss and brandelf) only understand BSD and Linux ELF binaries, and will require modifications to identify all the different brands. brandelf will really understand any brand at all; We just add special cases to suppress the need for -f for "known" brands. As it happens, though, there's no reason why you can't run "brandelf -f -t BOGUS-BOGUS foo" and have it put a BOGUS-BOGUS brand into an ELF object called foo. What may compound the problem is if multiple ELF formats use the same brand, or none at all (as is the case with SCO ODT5 binaries.) Well, yes, that's the thing - Branding is, AFAICT, specific to FreeBSD and Linux ELF; All other OSs need either a heuristic to select the appropriate emulator (for example, the pathname to the ELF interpreter in the executable, which doesn't always work), or an explicit branding, or an appropriate setting of the kern.fallback_elf_brand sysctl MIB variable. - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SVR4 Emulation [was Re: iBCS status?]
In the last episode (Jun 08), Mark Newton said: Ok -- I envisaged that there'd be a difficulty with different SysV vendors who used different semantics for the same syscalls, or different syscall numbering schemes. "It could happen!" (and, as we can see, it probably has). Possibly.. But isn't there some SVR4 ABI standard that says "you must implement these syscalls and these ioctls this way", etc? I'm sure the ABI explicitly says what lseek() takes for arguments, for example. Each variant would have its own ELF brand to aid the selection of the correct API. This I'm not sure we need. Linux's ibcs2 code does a pretty good job of automatically determining what ABI the program expects. The first thing an SCO binary does, for example, is call sysarch(SI86GETFEATURES) which tells it what version of SCO it's running (ABIs within ABIs. Imagine that.) I imagine Solaris has a similar call. If not, we can just assume we're using the Solaris ABI until we see a sysarch call. I'm not a big fan of branding executables; they make it really hard to run things off CDROM or use automated installation scripts. "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 "Daniel Nelson" - Anagram of "No Inland Eels" :( [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: iBCS status?
In the last episode (Jun 06), Mark Newton said: On Tue, Jun 06, 2000 at 01:48:10AM -0400, Matthew Emmerton wrote: I was recently playing around with iBCS support in FreeBSD 3.4/4.0, and noticed that there hasn't been much done since 96/97. From what I can see now, FreeBSD can't run SCO OpenServer 5.0 ELF binaries, which is a feature I need desperately -- Linux has this functionality. If anyone is working on iBCS, let me know, otherwise I'll start hacking away at the the emulation code to allow SCO OSR5 ELF stuff. SCO OpenServer doesn't use iBCS2, it's an SysVR4 ELF system. FreeBSD has notional support for it under the svr4 emulator in 4.x and -current, but hardly any testing has been done with SCO (I've been using Solaris binaries and libraries). I can say it pretty much doesn't work at all on SCO. There is apparently quite a difference between Solaris and SCO SVR4; the first thing I had to do was change the lseek() syscall to use 32-bit offsets instead of 64-bit, for example. SCO binaries also require most of the iBCS2 emulation to exist as well, so I ended up making svr4.ko depend on ibcs2.ko. I'm currently stuck trying to get getdents() and fstat() work. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: iBCS status?
On Tue, Jun 06, 2000 at 01:25:53AM -0500, Dan Nelson wrote: In the last episode (Jun 06), Mark Newton said: On Tue, Jun 06, 2000 at 01:48:10AM -0400, Matthew Emmerton wrote: I was recently playing around with iBCS support in FreeBSD 3.4/4.0, and noticed that there hasn't been much done since 96/97. From what I can see now, FreeBSD can't run SCO OpenServer 5.0 ELF binaries, which is a feature I need desperately -- Linux has this functionality. If anyone is working on iBCS, let me know, otherwise I'll start hacking away at the the emulation code to allow SCO OSR5 ELF stuff. SCO OpenServer doesn't use iBCS2, it's an SysVR4 ELF system. FreeBSD has notional support for it under the svr4 emulator in 4.x and -current, but hardly any testing has been done with SCO (I've been using Solaris binaries and libraries). I can say it pretty much doesn't work at all on SCO. I'm not at all surprised :-) I've had some reports from people who say they've had limited success, but since I don't have any SCO bits here I haven't been running any SCO software. There is apparently quite a difference between Solaris and SCO SVR4; the first thing I had to do was change the lseek() syscall to use 32-bit offsets instead of 64-bit, for example. Interesting - Solaris has two lseek syscalls, notionally "lseek" and "lseek64". If SCO only has one, which is a 64 bit variant, could you perhaps let me know what its syscall number is? - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: iBCS status?
In the last episode (Jun 06), Mark Newton said: There is apparently quite a difference between Solaris and SCO SVR4; the first thing I had to do was change the lseek() syscall to use 32-bit offsets instead of 64-bit, for example. Interesting - Solaris has two lseek syscalls, notionally "lseek" and "lseek64". If SCO only has one, which is a 64 bit variant, could you perhaps let me know what its syscall number is? SCO OSR5 has only the 32-bit variant at syscall 19, and its args match the ibcs2_lseek syscall (int fd, long offset, int whence). UW7 apparently has two additional syscalls: lseek32 and lseek64, but I don't know what numbers they are; I don't have UW7. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
iBCS status?
Hi all, I was recently playing around with iBCS support in FreeBSD 3.4/4.0, and noticed that there hasn't been much done since 96/97. >From what I can see now, FreeBSD can't run SCO OpenServer 5.0 ELF binaries, which is a feature I need desperately -- Linux has this functionality. If anyone is working on iBCS, let me know, otherwise I'll start hacking away at the the emulation code to allow SCO OSR5 ELF stuff. Thanks, --Matthew EmmertonGSI Computer Services
Re: iBCS status?
On Tue, Jun 06, 2000 at 01:48:10AM -0400, Matthew Emmerton wrote: I was recently playing around with iBCS support in FreeBSD 3.4/4.0, and noticed that there hasn't been much done since 96/97. From what I can see now, FreeBSD can't run SCO OpenServer 5.0 ELF binaries, which is a feature I need desperately -- Linux has this functionality. If anyone is working on iBCS, let me know, otherwise I'll start hacking away at the the emulation code to allow SCO OSR5 ELF stuff. SCO OpenServer doesn't use iBCS2, it's an SysVR4 ELF system. FreeBSD has notional support for it under the svr4 emulator in 4.x and -current, but hardly any testing has been done with SCO (I've been using Solaris binaries and libraries). If you want to play with it and send patches, feel free to bounce them my way. See http://slash.dotat.org/~newton/freebsd-svr4/ for more info. - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
