2013/6/13 Corinna Vinschen wrote: > On Jun 13 10:37, Kai Tietz wrote: >> 2013/6/13 Corinna Vinschen wrote: >> > Too bad. This is a typical problem of projects which have been ported >> > to 64 bit, but only to SYSV ABI, not to MS ABI. The problem never shows >> > up in the SYSV ABI (Linux, Solaris, etc), because arguments < 64 bit are >> > zero extended when pushed on the stack. Unfortunately, in the MS ABI, >> > parameters < 64 bit are not zero extended so the higher bits can contain >> > any random value. Here, the uncasted 0 is int, so it's pushed on the >> > stack with the higher 32 bit set to any garbage this stack address >> > contains at the time. >> > >> > Given our LP64-ness, I'm wondering if we couldn't tweak gcc to zero >> > extend arguments as well, even when otherwise using the MS ABI... >> > >> > >> > Corinna >> > >> > -- >> > Corinna Vinschen Please, send mails regarding Cygwin to >> > Cygwin Maintainer cygwin AT cygwin DOT com >> > Red Hat >> >> Hmm, well, we could do that, but it means of course in some cases a >> performance-penalty. For preventing some misunderstandings about >> MS-ABI I have to note that MS-ABI also extends argument also to >> natural-stack-boundary (means 8 byte on x64). Only difference here is >> that no sign-extending is used in general (in oppose to x86_64 ABI). >> So as quick feature this isn't implementable AFAICS due it has impact >> on behavior and performance. > > That puzzles me quite a bit. If MS-ABI *does* extend arguments, and > only the signedness is a problem, then why does (int)0 pushes something > different on the stack than (long)0? Signedness can't be the reason > here. > > The only reason I can see for that is that the argument has not been > extended at all. Yes, it takes its 64 bit slot, but only 32 bits have > been written to the stack, apparently. Am I missing something?
Yes, the save-region. A variadic-function will store for MS-ABI arguments to stack from register to save-region. variadic handling is stack-based for 32-bit and for 64-bit. Kai