Date: Tue, 07 May 2002 23:06:06 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: arch@FreeBSD.ORG Cc: Nathan Hawkins <utsl@quic.net> Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <3CD8C04E.A62999D9@mindspring.com> References: <XFMail.20020507103320.jhb@FreeBSD.org> <3CD7FE57.1000508@quic.net> <20020507110901.F23330@dragon.nuxi.com> <3CD823E8.2010809@quic.net> <20020507135957.A30027@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David O'Brien wrote: > > Even if it violates spec. > What is "it" and how does it violate the gABI spec? I think he means a non-zero EI_OSABI and/or EI_ABIVERSION. Basically, you are supposed to go through the standards process to define values other than 0. It's like defining a new "MIME type". > > NIH is a matter of perspective. FreeBSD could be considered to be in NIH > > mode, because the other ELF based systems use a different method. > > FreeBSD was the first to have a need to "brand" binaries. So there was > nothing to follow, so no NIH. > > [The need was to be able to run static Linux binaries. Note that if > Linux was strictly gABI compliant there would (1) be no static > binaries; and (2) we could not use the dynamic linker's name as a key > to know the binary is a Linux one.] FreeBSD has static binaries, too. I almost suggested "branding" the images, but that's really ridiculous. The closest thing I have seen to a real answer is the ABI command line argument to the compiler, and I think that's a really bad idea, too, though you have to wonder how a commercial vendor will get the old ABI. If I were a commercial vendor offering a binary, I would target the binary to the lowest common denominator, which would mean I would target the oldest ABI that could support the necessary functions to make the program work. The NetWare ABI has this same problem, with people targetting oder ABI's -- mostly because they can, since NetWare maintains interfaces back to the 2.0a version (early 1980's), and ships them with the libraries in the SDK. If you want to have the largest possible audience/customer base, then you target the least common denominator. Actually... I'm not really aware of any installations which don't have the "bindery emulation" NLM loaded so that they can run older software on their Novell network. > > this from a field in the ELF header. But you also use the .interp > > section in the emulation selector code. > > Not really. We do, but that is because few are strictly compliant with > the psABI's. For i386 FreeBSD and Linux should be using > "/usr/lib/libc.so.1". For Alpha "/usr/lib/ld.so", and for Sparc64 > "/usr/libexec/ld-elf.so.1". Yep. The problem is that some of the system calls have been co-opt'ed, so binary compatability with the EABI spec and some commercial OS's isn't possible. Ideally, when Linux went and exceeded the scope of the Solaris ABI, and added binary incompatabilities (e.g. differences in manifest constant values, elimination of character devices, etc.), they should have used a different kernel entry vector. Even more ideally, they would have just conformed to the solaris EABI, and all the code would "just run". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CD8C04E.A62999D9>