Clarification on PowerPC64 Linux ABI

Clarification on PowerPC64 Linux ABI

[Rohit Arul Raj]

Hello All,

I have a question regarding PowerPC64 bit ABI. Since GCC generates FP
instructions for Non FP code, i was running in to issues with
applications having interrupts (i have seen some threads with people
complaining about this). So the other option to resolve this was to
build the entire application with '-msoft-float' compiler option. It
seems to work fine with 32-bit PPC.

But when i tried to do the same with 64bit PPC, i was getting 'cannot
find -lgcc' error which was due to the MULTILIB option, that has been
set to exclude building target libraries with '-msoft-float -m64'
compiler option.

I have discussed this in the IRC channel some one mentioned that it is
because of 64bit ABI restriction even though some PPC Linux kernels
are built using this option.

I have gone through the ABI doc in the link given
"http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html"
and there is no mention of 'soft-float' or floating point emulation.
So it means i have to assume that '-msoft-float' is not defined by
ABI?

I have also gone through 32-bit PPC Linux ABI (sys V) doc,
"http://refspecs.freestandards.org/elf/elfspec_ppc.pdf" and there is
no mention of 'soft-float' or floating point emulation either.

But the PPC EABI doc does have reference to soft-float/FP emulation
[CHAPTER 6 Libraries 20 - Software Floating Point Emulation Support
Routines].
http://sources-redhat.mirrors.airband.net/binutils/ppc-docs/ppc-eabi-1995-01.pdf

1. Am i referring right documents?
2. Is there any restriction on '-msoft-float' ABI definition on 32bit
Linux sys V ABI, 32-bit EABI, 64bit ABI?
3. If PPC linux kernels are built with  '-msoft-float -m64' compiler
option, is it reasonably safe to build the application with the same
options?

Thanks,
Rohit

Re: Clarification on PowerPC64 Linux ABI

[Andrew Pinski]

On Mon, Mar 21, 2011 at 10:50 PM, Rohit Arul Raj <rohitarulraj@gmail.com> wrote:
> Hello All,
>
> I have a question regarding PowerPC64 bit ABI. Since GCC generates FP
> instructions for Non FP code, i was running in to issues with
> applications having interrupts (i have seen some threads with people
> complaining about this).


What kind of interrupts?  Because FP code should only produce an
interrupt at the first usage and that is it.  Since all PowerPC64
machines have a FPU, there will be no emulation needed.  The only
other kind of interrupt I can think of is an unaligned load/store for
a FPU load/store.  If that happens then you have issues dealing with
unaligned memory which is most like caused by undefined code.  Most
PPC64 machines are able to handle word aligned float/double
load/stores without an unaligned exception happening.  The reason why
it is undefined because of alignment requirements in the C/C++
standard.  I think you need to do some debugging to figure out why you
get the unaligned exceptions.  It is most likely a bug in your code.

Thanks.
Andrew Pinski

PS -msoft-float does not work as we don't multilib on -msoft-float for PPC64.

Re: Clarification on PowerPC64 Linux ABI

[Rohit Arul Raj]

Hello Andrew,

On Tue, Mar 22, 2011 at 11:41 AM, Andrew Pinski <pinskia@gmail.com> wrote:
> On Mon, Mar 21, 2011 at 10:50 PM, Rohit Arul Raj <rohitarulraj@gmail.com> wrote:
>> Hello All,
>>
>> I have a question regarding PowerPC64 bit ABI. Since GCC generates FP
>> instructions for Non FP code, i was running in to issues with
>> applications having interrupts (i have seen some threads with people
>> complaining about this).
>
>
> What kind of interrupts?

My usage is similar to the thread given below:
http://old.nabble.com/powerpc-eabi-gcc-no-implicit-FPU-usage-td27185159.html

When an interrupt occurs, the FPU is disabled. And while servicing an
interrupt, corresponding ISR gets called for which GCC generates code
that have FP registers being used even though there is no explicit FPU
usage.

> Because FP code should only produce an
> interrupt at the first usage and that is it.  Since all PowerPC64
> machines have a FPU, there will be no emulation needed.  The only
> other kind of interrupt I can think of is an unaligned load/store for
> a FPU load/store.  If that happens then you have issues dealing with
> unaligned memory which is most like caused by undefined code.  Most
> PPC64 machines are able to handle word aligned float/double
> load/stores without an unaligned exception happening.  The reason why
> it is undefined because of alignment requirements in the C/C++
> standard.  I think you need to do some debugging to figure out why you
> get the unaligned exceptions.  It is most likely a bug in your code.
>
> Thanks.
> Andrew Pinski
>
> PS -msoft-float does not work as we don't multilib on -msoft-float for PPC64.
>