[PowerPC] ABI questions

DavidW · July 30, 2014, 6:51pm

Hi all,

I'm trying to understand which ABIs are supported in the PowerPC
backend and I'm getting a bit confused. Here's what I've gathered so
far alongside with some questions.

- In PPCSubtarget.h there's DarwinABI, SVR4ABI and ELFv2ABI.
- The CodeGenerator documentation claims that the AIX PowerPC ABI is
followed (with some deviations). Is this refering to the DarwinABI?
- In a recent commit a TargetABI value and enumeration was added to
PPCSubtarget which contains PPC_ABI_UNKNOWN, PPC_ABI_ELFv1 and
PPC_ABI_ELFv2. For 64-bit non-Darwin the TargetABI value is set to
either ELF-variant in resetSubtargetFeatures(...) based on endianess
(unless explicitly set previously). As I understand it ELFv2 is a new
ABI but which ABI does ELFv1 map to?
- Since isSVR4ABI() is defined as !isDarwin() it currently is possible
for SVR4 and ELFv2 to be true at the same time which doesn't seem
correct to me.
- My understanding of SVR4ABI have been that it is the 32-bit PPC
processor supplement from Sun. Is this correct? If so, which ABI is
used for 64-bit non-Darwin?

I'm trying to implement the PPC EABI (which is based on the SVR4ABI)
for an out-of-tree subtarget which means I need to understand the
current status a bit better.

Best regards
David

Ulrich_Weigand · July 30, 2014, 7:29pm

Hi David,

I'm trying to understand which ABIs are supported in the PowerPC
backend and I'm getting a bit confused. Here's what I've gathered so
far alongside with some questions.

Sorry for the confusion, this all should probably be cleaned up a bit.
In general, LLVM today supports the following ABIs:
- The Darwin ABI (32-bit and 64-bit flavors)
- The 32-bit SVR4 ABI
- Two variants of the 64-bit SVR4 ABI: ELFv1 and ELFv2

The ELFv1 ABI is used on 64-bit big-endian Linux and AIX.
The ELFv2 ABI is used on 64-bit little-endian Linux.

Unfortunately, the term "SVR4" is quite overloaded, and applies
both to the 32-bit and the 64-bit ABIs, even though they are
quite different. "ELF ABI" is used interchangably with "SVR4 ABI".

ELFv1 is a recently introduced term to refer to what was previously
just called the ELF ABI (or equivalently SVR4 ABI); it is now used
to refer to the *old* variant of the ELF ABI as opposed to the new
one (ELFv2).

- In PPCSubtarget.h there's DarwinABI, SVR4ABI and ELFv2ABI.
- The CodeGenerator documentation claims that the AIX PowerPC ABI is
followed (with some deviations). Is this refering to the DarwinABI?

No, that's the ELFv1 ABI.

- In a recent commit a TargetABI value and enumeration was added to
PPCSubtarget which contains PPC_ABI_UNKNOWN, PPC_ABI_ELFv1 and
PPC_ABI_ELFv2. For 64-bit non-Darwin the TargetABI value is set to
either ELF-variant in resetSubtargetFeatures(...) based on endianess
(unless explicitly set previously). As I understand it ELFv2 is a new
ABI but which ABI does ELFv1 map to?

I hope the above makes it clearer.

- Since isSVR4ABI() is defined as !isDarwin() it currently is possible
for SVR4 and ELFv2 to be true at the same time which doesn't seem
correct to me.

isSVR4ABI is true for either ELFv1 or ELFv2, and also for the 32-bit
SVR4 ABI. This should probably be cleaned up by having three separate
predicates ...

- My understanding of SVR4ABI have been that it is the 32-bit PPC
processor supplement from Sun. Is this correct? If so, which ABI is
used for 64-bit non-Darwin?

SVR4 has always been used for either the 32-bit or 64-bit ELF ABIs
(*both* are processor supplement documents based on the original
Sun ELF/SVR4 ABI).

I'm trying to implement the PPC EABI (which is based on the SVR4ABI)
for an out-of-tree subtarget which means I need to understand the
current status a bit better.

It's up to Hal, but I'd suggest to split up the isSVR4ABI predicate
into three separate options, e.g. isSVR4ABI (or maybe isSVR4_32ABI),
isELFv1ABI, and isELFv2ABI; and then add another one for your new
ABI.

Bye,
Ulrich

DavidW · July 30, 2014, 8:06pm

Hello Ulrich,

Thank you for a good explanation of the different variants.

Hi David,

I'm trying to understand which ABIs are supported in the PowerPC
backend and I'm getting a bit confused. Here's what I've gathered so
far alongside with some questions.

Sorry for the confusion, this all should probably be cleaned up a bit.
In general, LLVM today supports the following ABIs:
- The Darwin ABI (32-bit and 64-bit flavors)
- The 32-bit SVR4 ABI
- Two variants of the 64-bit SVR4 ABI: ELFv1 and ELFv2

The ELFv1 ABI is used on 64-bit big-endian Linux and AIX.
The ELFv2 ABI is used on 64-bit little-endian Linux.

Unfortunately, the term "SVR4" is quite overloaded, and applies
both to the 32-bit and the 64-bit ABIs, even though they are
quite different. "ELF ABI" is used interchangably with "SVR4 ABI".

ELFv1 is a recently introduced term to refer to what was previously
just called the ELF ABI (or equivalently SVR4 ABI); it is now used
to refer to the *old* variant of the ELF ABI as opposed to the new
one (ELFv2).

- In PPCSubtarget.h there's DarwinABI, SVR4ABI and ELFv2ABI.
- The CodeGenerator documentation claims that the AIX PowerPC ABI is
followed (with some deviations). Is this refering to the DarwinABI?

No, that's the ELFv1 ABI.

But it describes both 64-bit and 32-bit linkage areas. Doesn't that
imply that it isn't ELFv1?
Just to be clear the document I'm talking about is:
http://llvm.org/docs/CodeGenerator.html#llvm-powerpc-abi

- David

Finkel_Hal_J · July 31, 2014, 12:48pm

From: "Ulrich Weigand" <Ulrich.Weigand@de.ibm.com>
To: "David Wiberg" <dwiberg@gmail.com>
Cc: llvmdev@cs.uiuc.edu
Sent: Wednesday, July 30, 2014 2:29:22 PM
Subject: Re: [LLVMdev] [PowerPC] ABI questions

Hi David,

> I'm trying to understand which ABIs are supported in the PowerPC
> backend and I'm getting a bit confused. Here's what I've gathered
> so
> far alongside with some questions.

Sorry for the confusion, this all should probably be cleaned up a
bit.
In general, LLVM today supports the following ABIs:
- The Darwin ABI (32-bit and 64-bit flavors)
- The 32-bit SVR4 ABI
- Two variants of the 64-bit SVR4 ABI: ELFv1 and ELFv2

The ELFv1 ABI is used on 64-bit big-endian Linux and AIX.
The ELFv2 ABI is used on 64-bit little-endian Linux.

Unfortunately, the term "SVR4" is quite overloaded, and applies
both to the 32-bit and the 64-bit ABIs, even though they are
quite different. "ELF ABI" is used interchangably with "SVR4 ABI".

ELFv1 is a recently introduced term to refer to what was previously
just called the ELF ABI (or equivalently SVR4 ABI); it is now used
to refer to the *old* variant of the ELF ABI as opposed to the new
one (ELFv2).

> - In PPCSubtarget.h there's DarwinABI, SVR4ABI and ELFv2ABI.
> - The CodeGenerator documentation claims that the AIX PowerPC ABI
> is
> followed (with some deviations). Is this refering to the DarwinABI?

No, that's the ELFv1 ABI.

> - In a recent commit a TargetABI value and enumeration was added to
> PPCSubtarget which contains PPC_ABI_UNKNOWN, PPC_ABI_ELFv1 and
> PPC_ABI_ELFv2. For 64-bit non-Darwin the TargetABI value is set to
> either ELF-variant in resetSubtargetFeatures(...) based on
> endianess
> (unless explicitly set previously). As I understand it ELFv2 is a
> new
> ABI but which ABI does ELFv1 map to?

I hope the above makes it clearer.

> - Since isSVR4ABI() is defined as !isDarwin() it currently is
> possible
> for SVR4 and ELFv2 to be true at the same time which doesn't seem
> correct to me.

isSVR4ABI is true for either ELFv1 or ELFv2, and also for the 32-bit
SVR4 ABI. This should probably be cleaned up by having three
separate
predicates ...

> - My understanding of SVR4ABI have been that it is the 32-bit PPC
> processor supplement from Sun. Is this correct? If so, which ABI is
> used for 64-bit non-Darwin?

SVR4 has always been used for either the 32-bit or 64-bit ELF ABIs
(*both* are processor supplement documents based on the original
Sun ELF/SVR4 ABI).

> I'm trying to implement the PPC EABI (which is based on the
> SVR4ABI)
> for an out-of-tree subtarget which means I need to understand the
> current status a bit better.

It's up to Hal, but I'd suggest to split up the isSVR4ABI predicate
into three separate options, e.g. isSVR4ABI (or maybe isSVR4_32ABI),
isELFv1ABI, and isELFv2ABI; and then add another one for your new
ABI.

I'd certainly welcome this. The current state of affairs seems to be the result of evolution more than design, and cleaning this up seems like a good idea.

Thanks again,
Hal

Ulrich_Weigand · July 31, 2014, 2:32pm

Ah, I must admit I never noticed that part of the docs before. I don't
know what that refers to, and it doesn't seem to correspond with what
LLVM actually implements on any platform ...

In general, I don't think it even makes sense to talk in terms of a
"LLVM PowerPC ABI" as that document does -- LLVM doesn't stand on its
own, it must be compatible to the *system* ABI for any of the systems
it supports.

So it would certainly be better to look at the actual system ABI
documents. If LLVM's behavior differs, that's a bug that should
be fixed.

Bye,
Ulrich

Finkel_Hal_J · July 31, 2014, 2:44pm

From: "Ulrich Weigand" <Ulrich.Weigand@de.ibm.com>
To: "David Wiberg" <dwiberg@gmail.com>
Cc: llvmdev@cs.uiuc.edu
Sent: Thursday, July 31, 2014 9:32:58 AM
Subject: Re: [LLVMdev] [PowerPC] ABI questions

> http://llvm.org/docs/CodeGenerator.html#llvm-powerpc-abi

Ah, I must admit I never noticed that part of the docs before. I
don't
know what that refers to, and it doesn't seem to correspond with what
LLVM actually implements on any platform ...

In general, I don't think it even makes sense to talk in terms of a
"LLVM PowerPC ABI" as that document does -- LLVM doesn't stand on its
own, it must be compatible to the *system* ABI for any of the systems
it supports.

So it would certainly be better to look at the actual system ABI
documents. If LLVM's behavior differs, that's a bug that should
be fixed.

Indeed, this documentation seems to refer to the Darwin ABI, and was likely written before other ABIs were supported. Updates to this documentation would certainly be appreciated as well.

-Hal

Bill_Schmidt · July 31, 2014, 3:49pm

> From: "Ulrich Weigand" <Ulrich.Weigand@de.ibm.com>
> To: "David Wiberg" <dwiberg@gmail.com>
> Cc: llvmdev@cs.uiuc.edu
> Sent: Wednesday, July 30, 2014 2:29:22 PM
> Subject: Re: [LLVMdev] [PowerPC] ABI questions
>
> Hi David,
>
> > I'm trying to understand which ABIs are supported in the PowerPC
> > backend and I'm getting a bit confused. Here's what I've gathered
> > so
> > far alongside with some questions.
>
> Sorry for the confusion, this all should probably be cleaned up a
> bit.
> In general, LLVM today supports the following ABIs:
> - The Darwin ABI (32-bit and 64-bit flavors)
> - The 32-bit SVR4 ABI
> - Two variants of the 64-bit SVR4 ABI: ELFv1 and ELFv2
>
> The ELFv1 ABI is used on 64-bit big-endian Linux and AIX.
> The ELFv2 ABI is used on 64-bit little-endian Linux.
>
> Unfortunately, the term "SVR4" is quite overloaded, and applies
> both to the 32-bit and the 64-bit ABIs, even though they are
> quite different. "ELF ABI" is used interchangably with "SVR4 ABI".
>
> ELFv1 is a recently introduced term to refer to what was previously
> just called the ELF ABI (or equivalently SVR4 ABI); it is now used
> to refer to the *old* variant of the ELF ABI as opposed to the new
> one (ELFv2).
>
> > - In PPCSubtarget.h there's DarwinABI, SVR4ABI and ELFv2ABI.
> > - The CodeGenerator documentation claims that the AIX PowerPC ABI
> > is
> > followed (with some deviations). Is this refering to the DarwinABI?
>
> No, that's the ELFv1 ABI.
>
> > - In a recent commit a TargetABI value and enumeration was added to
> > PPCSubtarget which contains PPC_ABI_UNKNOWN, PPC_ABI_ELFv1 and
> > PPC_ABI_ELFv2. For 64-bit non-Darwin the TargetABI value is set to
> > either ELF-variant in resetSubtargetFeatures(...) based on
> > endianess
> > (unless explicitly set previously). As I understand it ELFv2 is a
> > new
> > ABI but which ABI does ELFv1 map to?
>
> I hope the above makes it clearer.
>
> > - Since isSVR4ABI() is defined as !isDarwin() it currently is
> > possible
> > for SVR4 and ELFv2 to be true at the same time which doesn't seem
> > correct to me.
>
> isSVR4ABI is true for either ELFv1 or ELFv2, and also for the 32-bit
> SVR4 ABI. This should probably be cleaned up by having three
> separate
> predicates ...
>
> > - My understanding of SVR4ABI have been that it is the 32-bit PPC
> > processor supplement from Sun. Is this correct? If so, which ABI is
> > used for 64-bit non-Darwin?
>
> SVR4 has always been used for either the 32-bit or 64-bit ELF ABIs
> (*both* are processor supplement documents based on the original
> Sun ELF/SVR4 ABI).
>
> > I'm trying to implement the PPC EABI (which is based on the
> > SVR4ABI)
> > for an out-of-tree subtarget which means I need to understand the
> > current status a bit better.
>
> It's up to Hal, but I'd suggest to split up the isSVR4ABI predicate
> into three separate options, e.g. isSVR4ABI (or maybe isSVR4_32ABI),
> isELFv1ABI, and isELFv2ABI; and then add another one for your new
> ABI.

I'd certainly welcome this. The current state of affairs seems to be the result of evolution more than design, and cleaning this up seems like a good idea.

I may have asked this before a long time ago, but: How would people
feel about eradicating the use of the term SVR4 and replacing it with
ELF throughout? I really don't like the dated SVR4 terminology very
much.

Thanks,
Bill

DavidW · August 1, 2014, 9:24am

> From: "Ulrich Weigand" <Ulrich.Weigand@de.ibm.com>
> To: "David Wiberg" <dwiberg@gmail.com>
> Cc: llvmdev@cs.uiuc.edu
> Sent: Wednesday, July 30, 2014 2:29:22 PM
> Subject: Re: [LLVMdev] [PowerPC] ABI questions
>
> Hi David,
>
> > I'm trying to understand which ABIs are supported in the PowerPC
> > backend and I'm getting a bit confused. Here's what I've gathered
> > so
> > far alongside with some questions.
>
> Sorry for the confusion, this all should probably be cleaned up a
> bit.
> In general, LLVM today supports the following ABIs:
> - The Darwin ABI (32-bit and 64-bit flavors)
> - The 32-bit SVR4 ABI
> - Two variants of the 64-bit SVR4 ABI: ELFv1 and ELFv2
>
> The ELFv1 ABI is used on 64-bit big-endian Linux and AIX.
> The ELFv2 ABI is used on 64-bit little-endian Linux.
>
> Unfortunately, the term "SVR4" is quite overloaded, and applies
> both to the 32-bit and the 64-bit ABIs, even though they are
> quite different. "ELF ABI" is used interchangably with "SVR4 ABI".
>
> ELFv1 is a recently introduced term to refer to what was previously
> just called the ELF ABI (or equivalently SVR4 ABI); it is now used
> to refer to the *old* variant of the ELF ABI as opposed to the new
> one (ELFv2).
>
> > - In PPCSubtarget.h there's DarwinABI, SVR4ABI and ELFv2ABI.
> > - The CodeGenerator documentation claims that the AIX PowerPC ABI
> > is
> > followed (with some deviations). Is this refering to the DarwinABI?
>
> No, that's the ELFv1 ABI.
>
> > - In a recent commit a TargetABI value and enumeration was added to
> > PPCSubtarget which contains PPC_ABI_UNKNOWN, PPC_ABI_ELFv1 and
> > PPC_ABI_ELFv2. For 64-bit non-Darwin the TargetABI value is set to
> > either ELF-variant in resetSubtargetFeatures(...) based on
> > endianess
> > (unless explicitly set previously). As I understand it ELFv2 is a
> > new
> > ABI but which ABI does ELFv1 map to?
>
> I hope the above makes it clearer.
>
> > - Since isSVR4ABI() is defined as !isDarwin() it currently is
> > possible
> > for SVR4 and ELFv2 to be true at the same time which doesn't seem
> > correct to me.
>
> isSVR4ABI is true for either ELFv1 or ELFv2, and also for the 32-bit
> SVR4 ABI. This should probably be cleaned up by having three
> separate
> predicates ...
>
> > - My understanding of SVR4ABI have been that it is the 32-bit PPC
> > processor supplement from Sun. Is this correct? If so, which ABI is
> > used for 64-bit non-Darwin?
>
> SVR4 has always been used for either the 32-bit or 64-bit ELF ABIs
> (*both* are processor supplement documents based on the original
> Sun ELF/SVR4 ABI).
>
> > I'm trying to implement the PPC EABI (which is based on the
> > SVR4ABI)
> > for an out-of-tree subtarget which means I need to understand the
> > current status a bit better.
>
> It's up to Hal, but I'd suggest to split up the isSVR4ABI predicate
> into three separate options, e.g. isSVR4ABI (or maybe isSVR4_32ABI),
> isELFv1ABI, and isELFv2ABI; and then add another one for your new
> ABI.

I'd certainly welcome this. The current state of affairs seems to be the result of evolution more than design, and cleaning this up seems like a good idea.

I may have asked this before a long time ago, but: How would people
feel about eradicating the use of the term SVR4 and replacing it with
ELF throughout? I really don't like the dated SVR4 terminology very
much.

Thanks,
Bill

Hi,

The SVR4 terminology might be dated but it is also referred to by
other documents. As an example I'm looking at an EABI document from
Freescale. Are there examples of other ABI documents which uses ELF
instead?

I'm a novice when it comes to these parts but I thought that ELF was
more of a format mandated by the ABI and as such perhaps not suitable
as a term for the ABI itself.

If it were to be removed one important aspect would be to update the
documentation to clarify the relationships between the different ABIs
and help follow the paper trail from documents which still uses SVR4.

- David

Jonas_Maebe1 · August 1, 2014, 1:19pm

There’s one small difference between the two: with the 64 bit ELFv1/SVR4 ABI, tail padding for structs passed by value is only performed in case the struct is larger than 8 bytes, while for AIX 64 bit it’s always done. As an aside, on Darwin/ppc64 it’s done if the aggregate’s size is not in [1,2,4].

For an example, look at the assembly code for the program below. I don’t have the setup to compile for Linux/AIX PPC64 with clang, so I don’t know what LLVM does right now (I performed the tests with gcc).

Jonas

Ulrich_Weigand · August 1, 2014, 2:06pm

SVR4 ABI, tail padding for structs passed by value is only performed
in case the struct is larger than 8 bytes, while for AIX 64 bit it's
always done. As an aside, on Darwin/ppc64 it's done if the
aggregate's size is not in [1,2,4].

Ah, right, that's still a special case on AIX.

For an example, look at the assembly code for the program below. I
don't have the setup to compile for Linux/AIX PPC64 with clang, so I
don't know what LLVM does right now (I performed the tests with gcc).

Well, LLVM follows the Linux variant. I don't think we really
support AIX in LLVM anyway at this point ...

Bye,
Ulrich

Iain_Sandoe1 · August 1, 2014, 2:39pm

Hi Jonas

The ELFv1 ABI is used on 64-bit big-endian Linux and AIX.

There's one small difference between the two: with the 64 bit ELFv1/SVR4 ABI, tail padding for structs passed by value is only performed in case the struct is larger than 8 bytes, while for AIX 64 bit it's always done. As an aside, on Darwin/ppc64 it's done if the aggregate's size is not in [1,2,4].

JFTR,
1/ The darwin ppc64 case is, indeed, relatively sane (but darwin ppc64 is not yet implemented in clang or llvm).

2/ The Darwin ppc32 struct layout case is more complex (also inherited from AIX).

See "Mac OS X ABI Function Call Guide" (Feb 2009) [Apple]
- 32-bit PowerPC Calling Conventions
- Data Types and Alignments (Power case, which is the default).

I have almost completed an implementation of this ABI and hope to post patches in the next few weeks (test cases to make and polishing needed).

As of now, effectively, clang has "no detailed idea" of the Darwin PPC32 or PPC64 ABIs (except in so much as they are 32/64 bit RISCish) it is really quite amazing that any code works at all.

Iain

Jonas_Maebe1 · August 1, 2014, 2:51pm

There's one small difference between the two: with the 64 bit ELFv1/SVR4 ABI, tail padding for structs passed by value is only performed in case the struct is larger than 8 bytes, while for AIX 64 bit it's always done. As an aside, on Darwin/ppc64 it's done if the aggregate's size is not in [1,2,4].

JFTR,
1/ The darwin ppc64 case is, indeed, relatively sane (but darwin ppc64 is not yet implemented in clang or llvm).

Well, its requirement to pass individual floating point and vector fields of structs as if they were passed as separate parameters while packing everything else still together into integer registers is another matter...

2/ The Darwin ppc32 struct layout case is more complex (also inherited from AIX).

See "Mac OS X ABI Function Call Guide" (Feb 2009) [Apple]
- 32-bit PowerPC Calling Conventions
- Data Types and Alignments (Power case, which is the default).

I know, I've implemented the parameter passing for ppc32 for Linux, Mac OS X and AIX in our own compiler (and I'm currently working on cleaning up the 64 bit ppc parameter passing while adding support for ELFv2). In general, I consider the Darwin/ppc32 ABI much easier than the Darwin/ppc64 ABI.

I have almost completed an implementation of this ABI and hope to post patches in the next few weeks (test cases to make and polishing needed).

As of now, effectively, clang has "no detailed idea" of the Darwin PPC32 or PPC64 ABIs (except in so much as they are 32/64 bit RISCish) it is really quite amazing that any code works at all.

Absolutely! I guess the main reason is that very few system APIs make use of call-by-value struct parameters. For "project-internal" code, it doesn't really matter what you use as long as it's the same everywhere.

Jonas

Bill_Schmidt · August 1, 2014, 3:17pm

>> > From: "Ulrich Weigand" <Ulrich.Weigand@de.ibm.com>
>> > To: "David Wiberg" <dwiberg@gmail.com>
>> > Cc: llvmdev@cs.uiuc.edu
>> > Sent: Wednesday, July 30, 2014 2:29:22 PM
>> > Subject: Re: [LLVMdev] [PowerPC] ABI questions
>> >
>> > Hi David,
>> >
>> > > I'm trying to understand which ABIs are supported in the PowerPC
>> > > backend and I'm getting a bit confused. Here's what I've gathered
>> > > so
>> > > far alongside with some questions.
>> >
>> > Sorry for the confusion, this all should probably be cleaned up a
>> > bit.
>> > In general, LLVM today supports the following ABIs:
>> > - The Darwin ABI (32-bit and 64-bit flavors)
>> > - The 32-bit SVR4 ABI
>> > - Two variants of the 64-bit SVR4 ABI: ELFv1 and ELFv2
>> >
>> > The ELFv1 ABI is used on 64-bit big-endian Linux and AIX.
>> > The ELFv2 ABI is used on 64-bit little-endian Linux.
>> >
>> > Unfortunately, the term "SVR4" is quite overloaded, and applies
>> > both to the 32-bit and the 64-bit ABIs, even though they are
>> > quite different. "ELF ABI" is used interchangably with "SVR4 ABI".
>> >
>> > ELFv1 is a recently introduced term to refer to what was previously
>> > just called the ELF ABI (or equivalently SVR4 ABI); it is now used
>> > to refer to the *old* variant of the ELF ABI as opposed to the new
>> > one (ELFv2).
>> >
>> > > - In PPCSubtarget.h there's DarwinABI, SVR4ABI and ELFv2ABI.
>> > > - The CodeGenerator documentation claims that the AIX PowerPC ABI
>> > > is
>> > > followed (with some deviations). Is this refering to the DarwinABI?
>> >
>> > No, that's the ELFv1 ABI.
>> >
>> > > - In a recent commit a TargetABI value and enumeration was added to
>> > > PPCSubtarget which contains PPC_ABI_UNKNOWN, PPC_ABI_ELFv1 and
>> > > PPC_ABI_ELFv2. For 64-bit non-Darwin the TargetABI value is set to
>> > > either ELF-variant in resetSubtargetFeatures(...) based on
>> > > endianess
>> > > (unless explicitly set previously). As I understand it ELFv2 is a
>> > > new
>> > > ABI but which ABI does ELFv1 map to?
>> >
>> > I hope the above makes it clearer.
>> >
>> > > - Since isSVR4ABI() is defined as !isDarwin() it currently is
>> > > possible
>> > > for SVR4 and ELFv2 to be true at the same time which doesn't seem
>> > > correct to me.
>> >
>> > isSVR4ABI is true for either ELFv1 or ELFv2, and also for the 32-bit
>> > SVR4 ABI. This should probably be cleaned up by having three
>> > separate
>> > predicates ...
>> >
>> > > - My understanding of SVR4ABI have been that it is the 32-bit PPC
>> > > processor supplement from Sun. Is this correct? If so, which ABI is
>> > > used for 64-bit non-Darwin?
>> >
>> > SVR4 has always been used for either the 32-bit or 64-bit ELF ABIs
>> > (*both* are processor supplement documents based on the original
>> > Sun ELF/SVR4 ABI).
>> >
>> > > I'm trying to implement the PPC EABI (which is based on the
>> > > SVR4ABI)
>> > > for an out-of-tree subtarget which means I need to understand the
>> > > current status a bit better.
>> >
>> > It's up to Hal, but I'd suggest to split up the isSVR4ABI predicate
>> > into three separate options, e.g. isSVR4ABI (or maybe isSVR4_32ABI),
>> > isELFv1ABI, and isELFv2ABI; and then add another one for your new
>> > ABI.
>>
>> I'd certainly welcome this. The current state of affairs seems to be the result of evolution more than design, and cleaning this up seems like a good idea.
>
> I may have asked this before a long time ago, but: How would people
> feel about eradicating the use of the term SVR4 and replacing it with
> ELF throughout? I really don't like the dated SVR4 terminology very
> much.
>
> Thanks,
> Bill

Hi,

The SVR4 terminology might be dated but it is also referred to by
other documents. As an example I'm looking at an EABI document from
Freescale. Are there examples of other ABI documents which uses ELF
instead?

I'm a novice when it comes to these parts but I thought that ELF was
more of a format mandated by the ABI and as such perhaps not suitable
as a term for the ABI itself.

If it were to be removed one important aspect would be to update the
documentation to clarify the relationships between the different ABIs
and help follow the paper trail from documents which still uses SVR4.

I don't have a strong opinion. The two 64-bit ABIs and the 32-bit
Unified ABI don't use the term SVR4 in their titles. However, they are
all "supplements" to the original SVR4 ELF ABI, so it's reasonable to
leave the name as is. Simplest just to leave things alone.

Bill