This is the mail archive of the
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:37:57 +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>
2013/6/13 Corinna Vinschen wrote:
> On Jun 12 20:52, Yaakov (Cygwin/X) wrote:
>> On 2013-06-10 07:46, Dr. Volker Zell wrote:
>> >I think the stack trace translates to the following:
>> >Stack trace:
>> >Frame Function Args
>> >The offending code line
>> > case BvOff:
>> > res.bo = (char *) b->result + b->off;
>> > ((struct berval *) (res.bo + tot_size))->bv_val = NULL; <- line 414
>> > tot_size = 0;
>> > break;
>> That is where it is crashing, but after some debugging, AFAICS the
>> real culprit is the call to ber_scanf() in ldap_get_attribute_ber().
>> Presumably because this is a varargs function, the compiler wasn't
>> able to handle the necessary type promotion automatically (ber_len_t
>> is an unsigned long); so b->off was showing here as 0x600000000,
>> taking line 414 off to la-la land. Patch attached and pushed to
>> Ports git.
> 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 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.