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