This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> 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.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]