Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!spool.mu.edu!news.sol.net!newspump.sol.net!newsfeeder.sdsu.edu!hookup!news.mathworks.com!uunet!in1.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: GCC 2.7.2 for FreeBSD ??
Date: Mon, 08 Jul 1996 14:37:19 -0700
Organization: Me
Lines: 101
Message-ID: <31E17F8F.541A304F@lambert.org>
References: <4rhnut$23c@wdl1.wdl.loral.com> <31DD7744.35DB9D01@lambert.org> <4rn03t$nc1@news.cs.tu-berlin.de>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Martin v.Loewis wrote:
]
] In article <31DD7744.35DB9D01@lambert.org>,
] Terry Lambert <terry@lambert.org> wrote:
] >GCC 2.7.2 can not successfully compile the kernel without patches.
]
] Is that documented somewhere?
Yes, in the GCC problem report database.
] It might be helpful for user mode applications as well to have a
] list of sample programs that either don't compile or produce
] invalid code when compiled with 2.7.2.
This would imply that someone had nothing better to do with their
time than test GCC 2.7.2, which was supposedly tested before it
was released.
Not to put too fine a point on it, but there are certain assumptions
one makes about release software that just aren't valid for GCC.
] >The linker has consistently failed to integrate FreeBSD provided
] >patches for a.out shared libraries.
]
] Who failed to intergrate patches? The linker, as in /usr/bin/ld?
The linker maintainer; specifically, the binutils have not tracked
the necessary a.out changes (including crt0.o).
] In what way is the linker's support for a.out shared libraries
] related to the compiler version? Sorry, I'm just having difficulties
] to understand that sentence.
Older linkers (which you must use to get BSD shared libraries, as
explained in the binutils maintenance/integration discussion) do
not handle the strength reduction directives emitted by newer
compilers.
It is possible to hack the compiler each time, but it is unpleasent.
] >It would be helpful if the Elf standard would define some mechanism
] >for differentiating Elf binaries.
]
] You mean, to distinguish images for the same architecture but
] different operating systems?
Yes.
] For images linked with shared libraries, you can do that by
] providing different shared loaders.
No, you can not. Secifically, the SVR4 EABI, maintained at
Motorolla, specifies a load address other than 0x80000000. The
reason for this is not obvious, even though the load address was
corrected by the Linux camp when it was pointed out to them that
they were loading at the wrong address.
The address range 0x80000000 to 0x80001000 is reserved for a
NULL pointer dereference guard page.
The address range 0x80001000 to 0x802c000 (? -- see EABI for
confirmation) is reserved for the *KERNEL* to map the ld.so
into your address space on your behalf.
If this happens (as it is supposed to), then there is no way to
distinguish the binaries to determine autoselection of the loader.
That Linux and the GCC crt0.o, etc. are kludged right now is no
excuse.
] On some architectures, such support is not necessary. For example,
] on the Sparc, the different systems provide different trap entry
] points, so you know at run time what kind of image you have.
Kind of irrelevent as well, unless they change from version to
version (which would quickly overrrun the trap space), in case
you wanted to support ABI compatability among multiple versions
of a system interface.
The other (equally unacceptable) alternative would be to freeze
the interface.
] I agree that support for further image identification would be
] helpful. Historically, I assume it's not there because it was
] defined in the context of binary compatibility anyways.
I think it's because the SYSV EABI was adopted without adopting
its system interfacing. Since Linux changed its link address to
comply with the EABI, it is no longer possible to distinguish a
Linux ELF binary from a non-Linux.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.