Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 24 Feb 2001 03:58:06 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        arch@FreeBSD.ORG
Cc:        marcel@cup.hp.com (Marcel Moolenaar)
Subject:   Re: ELF, OS and ABI [was: Re: sysctl kern.fallback_elf_brand]
Message-ID:  <200102240358.UAA07092@usr05.primenet.com>
In-Reply-To: <20010223161604.C72750@dragon.nuxi.com> from "David O'Brien" at Feb 23, 2001 04:16:04 PM

next in thread | previous in thread | raw e-mail | index | archive | help
> > Do any of you have pointers to ELF specifications that document the ABI
> > section.
> 
> Of course not!  The {\extreme_sarcasm Blessed} ones want to hold all the
> knowledge on this so we have to beg that they take pity on us and teach
> us the One True Way.  (it's amusing many of them are GPV adovcates who
> preach "Freedom of Knowledge)
> 
> (see http://people.freebsd.org/~obrien/ei_osabi-binutils.mbox)
> 
> It is up to you to remove the {\extreme_sarcasm Blessed} distinction
> since you have better contacts with those of power on the IA-64 psABI
> committee than I do.

One of the messages in your archives says:

   >     http://developer.intel.com/design/IA-64/Downloads/24537002.pdf
   > 
   > Note that the second paragraph in section 1.1 of that specification
   > includes the following:
   > 
   >     This document is the result of consensus among operating system
   >     vendors intending to provide UNIX and UNIX workalike operating
   >     systems on the IA-64 architecture. The vendors participating in
   >     this effort include Intel, Sun Microsystems, SCO, IBM, SGI,
   >     Cygnus Solutions, VA Linux Systems, HP, and Compaq.

It's interesting that you didn't take them to task over the
suggestion that statically linked binaries were, by definition,
non conforming.  I have to say that, as a practical matter,
the idea that a compliant program could run on any compliant
platform is a good one, but the idea that programs will not
be statically linked by vendors seeking to comply with library
license redistribution clauses is absurd.

I know that SVR4 has, for a long time, mapped ld.so into the
image space of binaries in the loader in the kernel.  It seems
to me that ABI compatability is a hard row to hoe in light of
that mapping.

I also think that libc mapping too heavily assumes what do and do
not constitute symbols externalized by libc, particularly in light
of pthreads and the "errno" definitio, as permitted by POSIX (not
to mention the system error strings, environ, and related garbage
of a similar nature).

It seems to me that what they are definiing is Pascal: something
that you can build programs which run, but for which there are
no defined file I/O mechanisms within the scope of that standard
(in this instance, no system calls).

I think you are pissing in the wind with regard to H.J. Lu and
others in the Linux camp: the want the Linux system call
interface to be a pig more equal than others, and it seems to
me that it is intentional that they are squatting on "0" to try
and hijack the system call interface.

Good luck in getting to the committee meetings; my suggestion
would be to work through HP, Intel, Sun, Compaq, or IBM, as they
are the most "disinterested" of the parties involved.  Clearly,
several of them are in the camp of having "misunderstood" about
the "intent" of "operating system and", and in most dire need of
it staying in the standard.  HP won't be able to offer a PA-RISC
targetd binary that also runs on an IA-64 without it, for example
(NB: this may be in the interests of the "IA-64 yes, PA-RISC no"
camp in HP, but there have got to be proponents of both sides
there somewhere).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

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?200102240358.UAA07092>