Date: Fri, 9 Aug 1996 10:28:26 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bwithrow@BayNetworks.com (Robert Withrow) Cc: jkh@time.cdrom.com, lada@ws2301.gud.siemens.co.at, markd@Grizzly.COM, hackers@freebsd.org Subject: Re: What are the plans for ELF support? Message-ID: <199608091728.KAA18991@phaeton.artisoft.com> In-Reply-To: <199608091143.HAA09783@tuva.engeast.baynetworks.com> from "Robert Withrow" at Aug 9, 96 07:43:15 am
next in thread | previous in thread | raw e-mail | index | archive | help
> jkh@time.cdrom.com said: > :- we'll only switch to ELF if and when it demonstrates a set of > :- advantages which outweigh the disadvantages of changing. > > 1) Ability to build and use new GCC and BINUTILS distributions > ``out of the box''. This is not necessarily a big win, IMO. I believe the execution class loader exists for doing this already, if you wanted to do it. > 2) Ability to use the various BINUTILS tools for which there are > no a.out equivalents (like objdump). objdump is mostly for dumping ELF-specific information, in the stuff that it does above and beyond the traditional "hdr" program for dumping the file header data, and "ldd" for dynamic linkages. This is mostly useful if you already have ELF. However, if you take advantage of the ELF loader existing (#1), you can do this too. > 3) Ability to use site-written and commercial applications that > are designed around elf (of which we have many). This is actually false. The problem is that SVR4, Linux, and FreeBSD all use different system call entry points, and the ELF format has no way of tagging the binary by source system type. This is a flaw in the SVR4 EABI (available for download from the Motorolla site). Linux actually uses the name of the ld.so to distinguish the binaries (which won't work for static binaries). This is actually incorrect usage, since the ld.so code is designed (by implication in the SVR4 EABI) to be mapped in by the execution class loader -- in the kernel, not in a hacked up crt0.o. In netnews, I suggested a soloution to this, but it would require changing the Linux binary format slightly to make it work. The idea would be to define an ABI interface, hopefully one that was identical to some existing commercial system, and then standardizing it: 1) produce the spec. 2) produce a free validation suite under TET/ETET for the thing. 3) include in the spec a mechanism for restricting the system to executing *only* the ABI defined in the spec -- no extentions -- to allow the first real application compliance testing in the industry. 4) validate systems through self-validation; the spec would include mechanisms to uniquely identify builds of the system from a binary interface (specifically, the validation would be per release/code-cut, and the spec revision would be part of the validation). Ship compliance certification results with the system. 5) validate applications by doing the normal prerelease validation of the app with the mechanism in #3 active. Resulting binaries are guaranteed to run on any compliant system. Ship compliance certification results with the application. I called the ABI "FABIO" for "Free Application Binary Interface Objective". > 4) Ability to natively use elf for other purposes (like i18n), > in ways that a.out are not as well suited. The use of alternate language segments, unless they are data-only, is a misuse of the ELF format. In that direction lies per release dialog and resource data -- and therefore ruin. The problam is that such use is localization. Localization is the process of taking software, and using an internationalization mechanism, converting the application to a specific locale. Internationalization is the process of enabling data-driven localization. I believe that applications should be internationalized, not localized. The Windows and Mac approaches are therfore crap. > 5) Increased ease of developing multi-platform support. See my answer to your #3, above. If you can't distinguish the platforms, then you can't support multiple platform developement. If you meant cross compilation environments, I'll grudgingly admit that it would help. But since the GCC crosscompilation mechanism requires producing a "config" per target instance, the sources you compile are derived, rather than intrinsically capable of retargeting. GCC needs to change in this regard... this has been discussed at length in gnu.misc.discuss inre: why there are still cmpilers other than GCC, and in general, why GNU has not displaced the rest of the world (a one word summation is "productization"). I believe that ELF enables a lot of things (of which no ELF platform other than Windows95 / WindowsNT currently takes any advantage), and that this will be important to future directions, such a paging out kernel code that isn't going to be used, or was used only during system initialization, and never subsequent to that, etc.. It's also useful for module loading, and for use space use of Microsoft DLL's in UNIX applications -- possible, and relatively easy to do with minor linker changes, though DLL's typically consume interfaces not provided by BSD. Part of this direction would allow use of NDIS drivers under BSD, use of manufacturer supplied video drivers, etc.. It should even be possible to use ActiveX components (which, unlike ActiveX controls, do not consume MS-specific GUI interfaces) in BSD programs; the difference between these and ordinary DLL's is simply their support of process and thread attachement mechanisms for support of threading reeentrancy, and for virtual base class derived instance initialization (cv: MFC -- Foundation Classes for DLL/method association). ELF is definitely the direction of the future, if its problems can be adequately addressed. Since they are minor, I believe this is possible. Regards, 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?199608091728.KAA18991>