gcc x64 linux code generation (passing pointer var-args) bug

gcc x64 linux code generation (passing pointer var-args) bug

[Reuben Hawkins]

Hi Overseers,

I ran into an issue with all versions of gcc which support x64 which
*could* be considered a bug.  At the very least, it's a pitfall.  I'm
not really sure to whom I should bring this problem to.  Bugzilla?
Mailing list?  Not sure...

Anyway, the gist of the bug is this...

printf("%p %p %p %p %p %p\n", 0, 0, 0, 0, 0, 0);

The first 5 zero ints are copied into the esi, edx, ecx, r8d and r9d,
(as the linux x64 calling convention mandates) with the movl
instruction.  The movl instruction will zero out the upper 32-bits of
those registers.  The last zero int, however is copied to (%rsp) with
movl, which does *not* zero out the upper 32 bits because (%rsp) is
not a register, so the last 0 is not promoted to a 64-bit zero, but
the rest of the zeros are.  If I were to add another zero, that zero
would be copied to 8(%rsp), so the upper 32-bits of (%rsp) are skipped
and whatever garbage happens to be there is passed to the called
function.

printf("%p %p %p %p %p %p\n", 0, 0, 0, 0, 0, (void*)0);

...works because the (void*) causes gcc to emit a movq instruction.

I'm wondering if there's a possibility to change this unexpected
behavior in gcc such that it always uses movq on stack args.

I realize all the zeros are technically wrong, they should be either
NULL or (void*) casts, but it's a huge pain that '0' works for the
first 6 args, then doesn't on the 7th when the args start going on the
stack.

Thanks in advance,
Reuben Hawkins

Re: gcc x64 linux code generation (passing pointer var-args) bug

[Andrew Pinski]

On Fri, Jan 23, 2015 at 1:36 PM, Reuben Hawkins <reubenhwk@gmail.com> wrote:
> Hi Overseers,
>
> I ran into an issue with all versions of gcc which support x64 which
> *could* be considered a bug.  At the very least, it's a pitfall.  I'm
> not really sure to whom I should bring this problem to.  Bugzilla?
> Mailing list?  Not sure...


It is not a bug because ...

>
> Anyway, the gist of the bug is this...
>
> printf("%p %p %p %p %p %p\n", 0, 0, 0, 0, 0, 0);

You are passing 32bit values where 64bit values are expected.  If you
used -Wformat, it would have warned you about this issue.

>
> The first 5 zero ints are copied into the esi, edx, ecx, r8d and r9d,
> (as the linux x64 calling convention mandates) with the movl
> instruction.  The movl instruction will zero out the upper 32-bits of
> those registers.  The last zero int, however is copied to (%rsp) with
> movl, which does *not* zero out the upper 32 bits because (%rsp) is
> not a register, so the last 0 is not promoted to a 64-bit zero, but
> the rest of the zeros are.  If I were to add another zero, that zero
> would be copied to 8(%rsp), so the upper 32-bits of (%rsp) are skipped
> and whatever garbage happens to be there is passed to the called
> function.
>
> printf("%p %p %p %p %p %p\n", 0, 0, 0, 0, 0, (void*)0);
>
> ...works because the (void*) causes gcc to emit a movq instruction.
>
> I'm wondering if there's a possibility to change this unexpected
> behavior in gcc such that it always uses movq on stack args.


it is not unexpected because the ABI says something different from
what you are trying to work with.

>
> I realize all the zeros are technically wrong, they should be either
> NULL or (void*) casts, but it's a huge pain that '0' works for the
> first 6 args, then doesn't on the 7th when the args start going on the
> stack.


So this is undefined in C and will never work on most other targets too.

Thanks,
Andrew

>
> Thanks in advance,
> Reuben Hawkins

Re: gcc x64 linux code generation (passing pointer var-args) bug

[Reuben Hawkins]

On Fri, Jan 23, 2015 at 1:40 PM, Andrew Pinski <pinskia@gcc.gnu.org> wrote:
> On Fri, Jan 23, 2015 at 1:36 PM, Reuben Hawkins <reubenhwk@gmail.com> wrote:
>> Hi Overseers,
>>
>> I ran into an issue with all versions of gcc which support x64 which
>> *could* be considered a bug.  At the very least, it's a pitfall.  I'm
>> not really sure to whom I should bring this problem to.  Bugzilla?
>> Mailing list?  Not sure...
>
>
> It is not a bug because ...
>
>>
>> Anyway, the gist of the bug is this...
>>
>> printf("%p %p %p %p %p %p\n", 0, 0, 0, 0, 0, 0);
>
> You are passing 32bit values where 64bit values are expected.  If you
> used -Wformat, it would have warned you about this issue.

printf is just an example.  I noticed it when using
newtFormAddComponents, which has no warning.

>
>>
>> The first 5 zero ints are copied into the esi, edx, ecx, r8d and r9d,
>> (as the linux x64 calling convention mandates) with the movl
>> instruction.  The movl instruction will zero out the upper 32-bits of
>> those registers.  The last zero int, however is copied to (%rsp) with
>> movl, which does *not* zero out the upper 32 bits because (%rsp) is
>> not a register, so the last 0 is not promoted to a 64-bit zero, but
>> the rest of the zeros are.  If I were to add another zero, that zero
>> would be copied to 8(%rsp), so the upper 32-bits of (%rsp) are skipped
>> and whatever garbage happens to be there is passed to the called
>> function.
>>
>> printf("%p %p %p %p %p %p\n", 0, 0, 0, 0, 0, (void*)0);
>>
>> ...works because the (void*) causes gcc to emit a movq instruction.
>>
>> I'm wondering if there's a possibility to change this unexpected
>> behavior in gcc such that it always uses movq on stack args.
>
>
> it is not unexpected because the ABI says something different from
> what you are trying to work with.
>
>>
>> I realize all the zeros are technically wrong, they should be either
>> NULL or (void*) casts, but it's a huge pain that '0' works for the
>> first 6 args, then doesn't on the 7th when the args start going on the
>> stack.
>
>
> So this is undefined in C and will never work on most other targets too.

Dang.  :(

Which is preferred, NULL or (void*)0?  Are there cases where NULL will
be simply defined as 0?

(sorry if this question take this into off-topic territory).

>
> Thanks,
> Andrew
>
>>
>> Thanks in advance,
>> Reuben Hawkins

Re: gcc x64 linux code generation (passing pointer var-args) bug

[Ian Lance Taylor]

Reuben Hawkins <reubenhwk@gmail.com> writes:

> I ran into an issue with all versions of gcc which support x64 which
> *could* be considered a bug.  At the very least, it's a pitfall.  I'm
> not really sure to whom I should bring this problem to.  Bugzilla?
> Mailing list?  Not sure...

The overseers mailing list is not the right place.  This mailing list is
for discussion of the maintenance of the systems gcc.gnu.org and
sourceware.org.  You should take this to the mailing list
gcc-help@gcc.gnu.org.  Thanks.

Ian

Re: gcc x64 linux code generation (passing pointer var-args) bug

[Joseph Myers]

On Sat, 24 Jan 2015, Ian Lance Taylor wrote:

> Reuben Hawkins <reubenhwk@gmail.com> writes:
> 
> > I ran into an issue with all versions of gcc which support x64 which
> > *could* be considered a bug.  At the very least, it's a pitfall.  I'm
> > not really sure to whom I should bring this problem to.  Bugzilla?
> > Mailing list?  Not sure...
> 
> The overseers mailing list is not the right place.  This mailing list is
> for discussion of the maintenance of the systems gcc.gnu.org and
> sourceware.org.  You should take this to the mailing list
> gcc-help@gcc.gnu.org.  Thanks.

I think we're getting bug reports on overseers because the message about 
Bugzilla account creation being restricted points to overseers.

I think the message ought to include more information, such as (a) that 
account creation has been restricted because of large amounts of spam, (b) 
contact overseers and someone will create an account manually for you (not 
"for information about creating an account"), (c) the account will 
probably be created within time X, ((d) (if needed) make clear whether 
it's GCC Bugzilla or Sourceware Bugzilla you want an account on).

-- 
Joseph S. Myers
joseph@codesourcery.com