Mail Archives: cygwin/2014/10/21/08:27:37
On 10/21/2014 7:17 AM, Corinna Vinschen wrote:
> On Oct 20 15:58, Ken Brown wrote:
>> On 10/20/2014 3:03 PM, Corinna Vinschen wrote:
>>> One of the headaches when porting is sometimes the ABI. While on Linux
>>> the first 6 arguments to a function are given in registers, on Windows
>>> only 4 args are in registers. This can result in bugs when calling
>>> functions with more than 4 parameters, which are invisible on Linux, due
>>> to the way 32 bit parameter are stored in registers on x86_64. This
>>> happened to us already for at least one package.
>>
>> Am I right in thinking this can only be an issue if the source includes
>> assembler code?
>
> No. This can be easily trigger by a bug in C code. What happens is
> this:
>
> The 64 bit ABI is defined so that the first function args are passed
> to the called functions via CPU registers. On Windows the ABI uses 4
> such registers(*), on Linux 6(**). All following arguments are passed
> on the stack.
>
> The AMD64 CPUs introduced the following behaviour: If a 32 bit value
> (for instance, an int in C) is written to a register, the CPU
> automatically clears the upper 32 bits of the register. For instance:
>
> %rdx == 0x0123456789abcdef
>
> mov.l $0x42,%edx <- This is a 32 bit mov!
>
> ==> %rdx == 0x0000000000000042
>
> No sign extension:
>
> mov.l $0xffffffff,%edx
>
> ==> %rdx == 0x00000000ffffffff
>
> Now consider what happens if, for instance, the 5th argument to a
> stdargs function is expecting a pointer value. The caller calls the
> function like this:
>
> foo (a, b, c, d, 0);
>
> The 0 is int, it's not extendend to 64 bit. On Linux, nothing bad
> happens, because the 0 will be passed over to foo via register R8,
> so the upper 32 bits are cleared. On Cygwin, the 5th parameter is
> passed via the stack, 64 bit aligned. The upper 32 bits will not
> be explicitely written. They will contain random bytes. foo doesn't
> get a NULL pointer, but something like 0xdeadbeef00000000. Here's
> an example:
>
> $ cat > p.c <<EOF
> #include <stdio.h>
>
> int
> main ()
> {
> printf ("prepare stack:\n%p\n%p\n%p\n%p\n%p\n%p\n",
> 0x1111111111111111UL, 0x2222222222222222UL, 0x3333333333333333UL,
> 0x4444444444444444UL, 0x5555555555555555UL, 0x6666666666666666UL);
> printf ("\nprint null ptr:\n%p\n%p\n%p\n%p\n%p\n%p\n", 0, 0, 0, 0, 0, 0);
> }
> EOF
> $ gcc -g -o p p.c
> $ ./p
>
> The same problem might occur if some code uses a function unprototyped.
> My favorite example:
>
> /* Don't include string,h */
> printf ("Error message is: %s\n", strerror (errno));
>
> Long story short, I have no idea if that's your problem at all, but I
> thought I should at least mention it.
Thanks for the explanation!
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -