This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [64bit] openldap compilation doesn't produce shared libraries
- From: Kai Tietz <ktietz70 at googlemail dot com>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 13 Jun 2013 10:55:44 +0200
- Subject: Re: [64bit] openldap compilation doesn't produce shared libraries
- References: <87sj13i801 dot fsf at oracle dot com> <51A8D6C0 dot 3060507 at users dot sourceforge dot net> <51B1945E dot 6060002 at users dot sourceforge dot net> <87obbil3hb dot fsf at VZELL-LAP dot de dot oracle dot com> <87wqq2cotj dot fsf at oracle dot com> <20130610095305 dot GA32691 at calimero dot vinschen dot de> <87bo7ekuaz dot fsf at VZELL-LAP dot de dot oracle dot com> <51B925EC dot 1090706 at users dot sourceforge dot net> <20130613081928 dot GA15436 at calimero dot vinschen dot de> <CAEwic4acCNL9hymGkXbTEdMhX-ocYNc6jmpfytvZ0nrTyBJcZA at mail dot gmail dot com> <20130613085237 dot GF1736 at calimero dot vinschen dot de>
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