Fix passing/returning of complex data for PowerPC 32-bit
Commit Message
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
Comments
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
2014-06-27 Luis Machado <lgustavo@codesourcery.com>
* ppc-sysv-tdep.c (ppc_sysv_abi_push_dummy_call): Explicitly
handle passing of complex arguments.
(do_ppc_sysv_return_value): Explicitly handle return of
complex types.
@@ -269,6 +269,44 @@ ppc_sysv_abi_push_dummy_call (struct gdbarch *gdbarch, struct value *function,
greg += 4;
}
}
+ else if (TYPE_CODE (type) == TYPE_CODE_COMPLEX)
+ {
+ int type_size = TYPE_LENGTH (type);
+ int ngpr = type_size / tdep->wordsize;
+
+ /* The PowerPC Unified 32-bit ABI specifies two mutually
+ conflicting conventions for passing and returning complex
+ floating-point values. These values are either treated as if
+ they were represented as a structure containing an array of
+ size two of the corresponding floating-point types (as
+ identified by the ATR-PASS-COMPLEX-AS-STRUCT ABI attribute) or
+ passed in the GPRs (as identified by the
+ ATR-PASS-COMPLEX-IN-GPRS ABI attribute). Since the latter
+ convention is the default in GCC, and mandated by the Linux
+ ABI, that's what we implement. */
+ if (ngpr + greg > 11)
+ {
+ /* Pass parameter in the stack. */
+ argoffset = align_up (argoffset, 8);
+ if (write_pass)
+ write_memory (sp + argoffset, val, len);
+ argoffset += len;
+ }
+ else
+ {
+ /* Pass the parameter in registers. */
+ if (write_pass)
+ {
+ int i;
+
+ for (i = 0; i < ngpr; i++)
+ regcache_cooked_write (regcache,
+ tdep->ppc_gp0_regnum + greg + i,
+ val + i * 4);
+ }
+ greg += ngpr;
+ }
+ }
else if (TYPE_CODE (type) == TYPE_CODE_DECFLOAT && len <= 8
&& !tdep->soft_float)
{
@@ -724,6 +762,30 @@ do_ppc_sysv_return_value (struct gdbarch *gdbarch, struct type *func_type,
}
return RETURN_VALUE_REGISTER_CONVENTION;
}
+
+ /* The PowerPC Unified 32-bit specifies that complex
+ floating-point values are returned in the GPRs for
+ ATR-PASS-COMPLEX-IN-GPRS. */
+ if (TYPE_CODE (type) == TYPE_CODE_COMPLEX)
+ {
+ int i, nregs;
+ int return_reg = tdep->ppc_gp0_regnum + 3;
+
+ nregs = TYPE_LENGTH (type) / tdep->wordsize;
+
+ for (i = 0; i < nregs; i++)
+ {
+ if (readbuf)
+ regcache_cooked_read (regcache, return_reg + i,
+ readbuf + i * tdep->wordsize);
+ if (writebuf)
+ regcache_cooked_write (regcache, return_reg + i,
+ writebuf + i * tdep->wordsize);
+ }
+
+ return RETURN_VALUE_REGISTER_CONVENTION;
+ }
+
if (TYPE_CODE (type) == TYPE_CODE_FLT
&& TYPE_LENGTH (type) == 16
&& !tdep->soft_float