This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] rs6000.c ELF bits inclusion
- To: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: [PATCH] rs6000.c ELF bits inclusion
- From: "David O'Brien" <obrien at FreeBSD dot org>
- Date: Thu, 3 May 2001 19:10:58 -0700
- Cc: gcc at gcc dot gnu dot org
- Organization: The NUXI BSD group
- References: <obrien@NUXI.com> <200105032303.TAA24884@makai.watson.ibm.com>
- Reply-To: obrien at FreeBSD dot org
On Thu, May 03, 2001 at 07:03:53PM -0400, David Edelsohn wrote:
> >>>>> "David O'Brien" writes:
> David> This patch allows me to do what I need. Are you OK with it, or is there
> David> another way you would like to see the problem solved? I really do not
> David> want to include config/svr4.h.
> I do not believe that it is productive for FreeBSD to have its
> own, slightly different ABI.
I do not feel FreeBSD has its own "slightly different ABI" any more than
Linux or AIX does. Linux and FreeBSD, at least, both break ever psABI I
know of by not using the defined name of the dynamic interrupter
For PowerPC FreeBSD will follow either the ABI or eABI as specified in
"PowerPC Processor ABI Supplement - Sept. 1995". (if you know of a better
PPC psABI, please let me know)
Maybe we should agree on some terms to help the discussion. Do you
consider what the gabi4.1pdf (System V Application Binary Interface) from
www.sco.com and "PowerPC Processor ABI Supplement - Sept. 1995" describes
to be the ELF or SVR4 ABI? Both of these uses "SVR4", however wider
usage [here] seems different. "ELF: From The Programmer's Perspective"
by Hongjiu Lu, says:
The Executable and Linking Format (ELF) is a binary format originally
developed and published by UNIX System Laboratories (USL). It is the
default binary format for the executable files used by SVR4 and
I interrupt this to mean Lu considers the binary format and ABI to be
named "ELF" and SVR4 a consumer of it (having been invented by its
maker). If you want to call the ABI "SVR4", what term should we use to
describe the Unix system from USL? As I pointed out in another email,
things like "#define SCCS_DIRECTIVE" and linker command line options are
not specified in any gABI or psABI document I know of and describes an
attribute not of an ABI, but a particular Unix system.
When elfos.h was created from svr4.h, I thought GCC developers in general
had agreed that "svr4" was the Unix system, and "elf" to refer to the
general ABI and object format attributes. If this is not the case, give
me two terms and lets make the existing elfos.h be svr4.h and the
existing svr4.h to be svr4-implementation.h or what ever two terms you
> FreeBSD likely will discourage more potential users by being slightly
> incompatible than it gains for any perceived improvement over the
> standard. This design argument does not seem to be effective with you.
The attributes in the various FreeBSD headers describe attributes of
FreeBSD systems such as the name of our crt.o file is crt1.o, our linker
uses -Bshareable and -Bsymbolic, but not -p, our dynamic linker is
/usr/libexec/ld-elf.so.1, we expect "__PIC__" to be defined if -fPIC was
given on the command line, we don't like DEFAULT_PCC_STRUCT_RETURN, or
Do you consider these to be part of a standard, or just platform
implementation details? (granted the dynamic linker is address in the
above ABI documents)
> "... allows me to do what I need" is not a very compelling
> argument that a patch is correct or should be approved, IMHO.
Why not? I have a need of greater generality that currently exists.
Because there are an infinite amount of hours for anyone to work on GCC,
people are only going to put time into things that "scratch itches" You
admitted that you know there are something in rs6000.h that better belong
in aix.h. Why haven't you moved them there yet? Because the need isn't
[yet] great enough to spend the time on it.
> From my
> perspective, it seems that you expediently want to solve the symptom of
> your problem and not your problem.
I feel my problem is many of the GCC config headers were written under
the assumption only the vendor's OS is the only OS in existence that runs
on the HW. Things have gotten better over time, but alpha/alpha.h still
assumes it describes OSF/1. rs6000/rs6000.h still has assumptions of AIX
in it. What do you feel is my problem?
> Because this patch is small and localized and this discussion no
> longer seems to be productive,
I would like to make it productive.
> I suspect that you will have to return to this issue again (and
> again) and eventually will need to solve it correctly.
Explicitly, what is the correct way to solve it?
-- David (obrien@FreeBSD.org)