PATCH: Use "unsigned long long int" in x86-64 __makecontext

[H.J. Lu]

On Fri, Mar 16, 2012 at 2:20 PM, Roland McGrath <roland@hack.frob.com> wrote:
>> On Fri, Mar 16, 2012 at 1:13 PM, Roland McGrath <roland@hack.frob.com> wrote:
>> > Why not use greg_t in va_arg too?
>>
>> I thought about it.  I am concerned
>>
>>       default:
>>         /* Put value on stack.  */
>>         sp[i - 5] = va_arg (ap, unsigned long int);
>>         break;
>>
>> Why is unsigned long int used here when all other places use long int?
>> I think they should be the same.  But I may have missed something.
>
> It certainly doesn't matter to the behavior of va_arg.
> I can't see how it would matter to the assignment either,
> since there is no widening taking place.
>
> I guess to be paranoid you could compare the generated code before and
> after.  The only change that should potentially make a difference is the
> type of IDX_UC_LINK.  But off hand it seems to me that should be size_t
> anyway, and then the generated code should be completely identical unless
> I've overlooked something.
>
> I also notice the XXX comment in that file, which doesn't apply to the code
> there now (but does still apply to the test case, which probably ought to
> test int, long int, and pointer arguments explicitly just to be thorough).
>
> Hmm.  The specification for makecontext actually says all the arguments are
> just int, though our x86_64 code supports long int and pointer as well.  If
> the specification were modernized it might say something like "integer
> types no larger than intptr_t" or something like that.  But still it seems
> unlikely it would specify that you have to handle anything larger than a
> pointer.  You're making x32 handle int64_t even though that's larger than a
> pointer.  That makes some intrinsic sense for x32 because of its calling
> convention, but the generic specification would never require that since
> it's not going handle e.g. int64_t on i386.  Since the x86_64 and x32 ABIs
> specify 64-bit locations for all smaller integer arguments, it may make no
> difference.  But it's not entirely clear to me from the ABI document what
> the rules are about sign-extension.  If the callee is always required to
> ignore the high bits of an argument of type int (rather than expecting the
> caller to have sign-extended it), then it doesn't matter if the argument is
> treat as int or int64_t for va_arg in makecontext.
>

I compared the assembly outputs for both x32 and x86-64.  There
are no differences between "long int" and "unsigned long int" vs.
"greg_t" on va_arg.  Here is the patch to use  greg_t exclusively.
OK to install?

Thanks.


-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libc-x32-makecontext.patch
Type: text/x-patch
Size: 3120 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20120316/ccd0d973/attachment.bin>