Re: [PATCH] Fix passing/returning of complex data for PowerPC 32-bit

[Luis Machado <lgustavo@codesourcery.com>]

On 06/27/2014 07:40 PM, Luis Machado wrote:
> On 06/27/2014 11:30 AM, Mark Kettenis wrote:
>>> Date: Thu, 26 Jun 2014 06:54:59 +0100
>>> From: Luis Machado <lgustavo@codesourcery.com>
>>>
>>> The PowerPC 32-bit unified ABI states that there are two ways of passing
>>> and returning complex type data:
>>>
>>> - Pointer, in a register, to a memory area.
>>> - Data in registers.
>>>
>>> The problem is that it is not clear how to detect which variation a
>>> program is using. GDB currently does a bit of both. It uses the first
>>> mechanism for passing parameters and uses both to return data, depending
>>> on the size of the data type. It is a bit messy because GDB is not
>>> handling complex types explicitly.
>>>
>>> Checking the gdb.base/callfuncs.exp testcase for a PowerPC 32-bit
>>> target, with code built with GCC, showed a few failures related to
>>> complex types.
>>>
>>> This patch steers GDB towards what GCC seems to generate for PowerPC
>>> 32-bit and handles complex type passing/return via general registers
>>> (the second option). All failures are gone.
>>>
>>> The problem here is if some other target/compiler is using the other
>>> variation. So, for those that have a PowerPC 32-bit handy, can you
>>> confirm it works reliably? I'm thinking AIX, Darwin or some other eabi
>>> target.
>>
>> AIX uses its own inplementations (rs6000_push_dummy_call and
>> rs6000_return_value).  And we don't support Darwin on PowerPC.
>>
>
> True. That should be a non issue then.
>
>>> Otherwise, does this look reasonable?
>>
>> I agree that the "System V" support code should support the
>> ATR-PASS-COMPLEX-IN-GPRS ABI Attribute.  This is what the Linux ABI
>> uses (it is included in ATR-LINUX) which pretty much is the direct
>> succssor of the System V ABI (which didn't specify anything about
>> complex floating-point support).
>>
>> If somebody really wants to support complex numbers on an embedded
>> system that uses ATR-PASS-COMPLEX-AS-STRUCT, they'll have to implement
>> an osabi sniffer for it and override the appropriate methods.
>>
>> Code generally looks good.  Some nits below.  The comments are a bit
>> elaborate though.  I'd cut them down a bit; see my suggestion below.
>>
>>
>
> I adjusted the patch and compressed the comments according to the
> suggestions.
>
> Thanks!
> Luis

It seems folks are happy with this patch (at least the interested 
parties), so i'll go ahead and commit this one in the following days 
unless i hear something back.

Thanks,
Luis