Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.uwa.edu.au!classic.iinet.com.au!swing.iinet.net.au!news.uoregon.edu!news.emf.net!overload.lbl.gov!lll-winken.llnl.gov!uwm.edu!chi-news.cic.net!newsfeed.internetmci.com!news.sprintlink.net!EU.net!Austria.EU.net!newsfeed.ACO.net!swidir.switch.ch!scsing.switch.ch!news.belwue.de!News.Uni-Marburg.DE!news.th-darmstadt.de!fauern!lrz-muenchen.de!uni-regensburg.de!faui0n.informatik.uni-erlangen.de!uni-erlangen.de!news.tu-chemnitz.de!irz 401!uriah.heep!not-for-mail From: j@uriah.heep.sax.de (J Wunsch) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Will FreeBSD ever support ELF? Date: 15 Oct 1995 17:46:21 +0100 Organization: Private FreeBSD site, Dresden. Lines: 41 Message-ID: <45rdst$kpv@uriah.heep.sax.de> References: <oenwlx9v8.fsf@vapor.Franz.COM> <45hbnd$9ln@uriah.heep.sax.de> <45lu9a$408@news.rrz.uni-koeln.de> NNTP-Posting-Host: uriah.heep.sax.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Stefan Esser <se@MI.Uni-Koeln.DE> wrote: >|> Anyway, you're more than welcome to supply patches that make FreeBSD >|> run with ELF binaries. :-) >Well, do we really want this ? Yes. We don't have an _urgent_ need however. >Introducing a new binary and shared library format for >no good reason means, that we'll have to deal with both >formats for a long time to come. Given the flexibility of the imgact_* modules, this doesn't seem to be _the_ problem. Remember, we're already supporting at least two different object formats without much hassles: a.out and gzipped a.out (pseudo-device gzip). The ibcs2 and linux image activators are also steadily improving... >There is nothing magcial about ELF. It's just that the >Common Object File Format introduced in System V Unix >turned out to be not that common :) and that something >more flexible was needed for System V.4 ... a.out is even more limited than COFF. No surprise, it's simply older and the ancestor of the other object formats. (You certainly know the "PDP-11 executable" message for file *.o until very recently.) The most annoying limitation is that a.out does only have a predefined set of sections available. It's sometimes useful to have more of them, think of the problematic to distinguish between pageable and non-pageable objects in the kernel. Things like run-time initialization sections for C++ are also a nightmare to handle in a.out, but rather easy to do even in COFF. You can simply toss all global constructors and destructors into different sections of the object file and have the linker collect them in the executable. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)