[LLVMdev] [PowerPC] ABI questions

[David Wiberg]

2014-07-31 17:49 GMT+02:00 Bill Schmidt <wschmidt at linux.vnet.ibm.com>:
> On Thu, 2014-07-31 at 07:48 -0500, Hal Finkel wrote:
>> ----- Original Message -----
>> > From: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com>
>> > To: "David Wiberg" <dwiberg at gmail.com>
>> > Cc: llvmdev at 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

>
>>
>> Thanks again,
>> Hal
>>
>> >
>> > Bye,
>> > Ulrich
>> >
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev