RE: [openssl.org #2620] Resolved: static libs cause crash in linking application on Win64 x64 when built with default (masm) compilation...

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: [openssl.org #2620] Resolved: static libs cause crash in linking application on Win64 x64 when built with default (masm) compilation...

Rich Salz via RT
Looks like it is still there in 1.0.0g

Again, it's an alignment issue of function pointers put into an array
processed by the C-runtime normally used for doing things like global
constructors.

Its in crypto/perlasm/x86_64-xlate.pl:558
Currently:
        $v.=" READONLY DWORD";
Should be:
        $v.=" READONLY ALIGN(8)";

The problem with DWORD alignment is that on x64 the function pointers
are QWORDs, so you can easily link such that the pointer is misaligned,
leading to a crash.

Let me know if you want more info.

-dave

> -----Original Message-----
> From: Andy Polyakov via RT [mailto:[hidden email]]
> Sent: Sunday, January 15, 2012 8:00 AM
> To: [hidden email]
> Subject: [openssl.org #2620] Resolved: static libs cause
> crash in linking application on Win64 x64 when built with
> default (masm) compilation...
>
>
> According to our records, your request has been resolved. If
> you have any
> further questions or concerns, please respond to this message.
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #2620] Resolved: static libs cause crash in linking application on Win64 x64 when built with default (masm) compilation...

Rich Salz via RT
> Looks like it is still there in 1.0.0g

Right, modification made to 1.0.1 as focus was on beta...

> Again, it's an alignment issue of function pointers put into an array
> processed by the C-runtime normally used for doing things like global
> constructors.

I actually have hard time imagining how misalignment can actually
happen. Even if x86_64cpuid.asm aligns .CRT$XCU at DWORD, it's
*appended* to segment aligned at QWORD *and* contains QWORD itself.
Therefore it shouldn't disrupt alignment. And I can't reproduce the
problem with openssl.exe and any of the test programs [produced with
nt.mak]. Can you confirm that it fails in say openssl.exe or are you
referring to your [or 3rd party] application that is failing? The only
scenario I can imagine is that some other object module specifies
unaligned .CRT prior $XCU and places DWORD there, thus disrupting the
alignment. But if this is the case, then it's more important to fix
actually guilty one... If openssl.exe crashes, can you submit map file?
Add /m to LFLAGS in nt.mak...

> Its in crypto/perlasm/x86_64-xlate.pl:558
> Currently:
> $v.=" READONLY DWORD";
> Should be:
> $v.=" READONLY ALIGN(8)";

For reference, the original reason for sticking to DWORD was because
initial ml64 versions didn't understand ALIGN(N). So that formally
solution should be to choose between DWORD and ALIGN(8) depending on
assembler version [and pray for DWORD to work with old version], see
http://cvs.openssl.org/chngview?cn=22061.

And in case of doubt use nasm, which is actually preferred option.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [openssl.org #2620] Resolved: static libs cause crash in linking application on Win64 x64 when built with default (masm) compilation...

Rich Salz via RT
Ah, OK (on the 1.0.1 beta)

I agree with your reasoning and surprise on the misalignment (regarding
the appending, etc), but there it is.  I am referring to my 3rd party
application, I didn't bother to inspect the openssl.exe.  Also, it
doesn't _always_ wind up this way (though always for me, haha).  I'll
try to cook up a short program that exhibits the behaviour and send it
to you, along with detailed build config.

Also on the topic of x64, though not related to this, I can not for the
life of me get Linux builds to generate position-independent-code for
the asm modules.  I can for the C stuff (via -DPIC -fPIC on the ./config
step), but it doesn't help the asm modules, so I have to compile with
no-asm, which then results in half the runtime speed, alas.  Separate
bug/enhancement though....

-dave

> -----Original Message-----
> From: Andy Polyakov via RT [mailto:[hidden email]]
> Sent: Saturday, January 21, 2012 5:41 AM
> To: [hidden email]
> Cc: [hidden email]
> Subject: Re: [openssl.org #2620] Resolved: static libs cause
> crash in linking application on Win64 x64 when built with
> default (masm) compilation...
>
>
> > Looks like it is still there in 1.0.0g
>
> Right, modification made to 1.0.1 as focus was on beta...
>
> > Again, it's an alignment issue of function pointers put
> into an array
> > processed by the C-runtime normally used for doing things
> like global
> > constructors.
>
> I actually have hard time imagining how misalignment can actually
> happen. Even if x86_64cpuid.asm aligns .CRT$XCU at DWORD, it's
> *appended* to segment aligned at QWORD *and* contains QWORD itself.
> Therefore it shouldn't disrupt alignment. And I can't reproduce the
> problem with openssl.exe and any of the test programs [produced with
> nt.mak]. Can you confirm that it fails in say openssl.exe or are you
> referring to your [or 3rd party] application that is failing? The only
> scenario I can imagine is that some other object module specifies
> unaligned .CRT prior $XCU and places DWORD there, thus disrupting the
> alignment. But if this is the case, then it's more important to fix
> actually guilty one... If openssl.exe crashes, can you submit
> map file?
> Add /m to LFLAGS in nt.mak...
>
> > Its in crypto/perlasm/x86_64-xlate.pl:558
> > Currently:
> > $v.=" READONLY DWORD";
> > Should be:
> > $v.=" READONLY ALIGN(8)";
>
> For reference, the original reason for sticking to DWORD was because
> initial ml64 versions didn't understand ALIGN(N). So that formally
> solution should be to choose between DWORD and ALIGN(8) depending on
> assembler version [and pray for DWORD to work with old version], see
> http://cvs.openssl.org/chngview?cn=22061.
>
> And in case of doubt use nasm, which is actually preferred option.
>
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #2620] Resolved: static libs cause crash in linking application on Win64 x64 when built with default (masm) compilation...

Erik Forsberg-11
In reply to this post by Rich Salz via RT
The latest snapshot that has this checkin, has a Perl syntax error on line
573
of crypto/perlasm/x86_64-xlate.pl (missing ; on the line above)

Using perl 5.8.4 on Solaris 10.

>-- Original Message --
>Subject: Re: [openssl.org #2620] Resolved: static libs cause crash in linking
>application on Win64 x64 when built with default (masm) compilation...
>From: "Andy Polyakov via RT" <[hidden email]>
>To: [hidden email]
>Cc: [hidden email]
>Date: Sat, 21 Jan 2012 12:41:03 +0100 (CET)
>Reply-To: [hidden email]
>
>
>> Looks like it is still there in 1.0.0g
>
>Right, modification made to 1.0.1 as focus was on beta...
>
>> Again, it's an alignment issue of function pointers put into an array
>> processed by the C-runtime normally used for doing things like global
>> constructors.
>
>I actually have hard time imagining how misalignment can actually
>happen. Even if x86_64cpuid.asm aligns .CRT$XCU at DWORD, it's
>*appended* to segment aligned at QWORD *and* contains QWORD itself.
>Therefore it shouldn't disrupt alignment. And I can't reproduce the
>problem with openssl.exe and any of the test programs [produced with
>nt.mak]. Can you confirm that it fails in say openssl.exe or are you
>referring to your [or 3rd party] application that is failing? The only
>scenario I can imagine is that some other object module specifies
>unaligned .CRT prior $XCU and places DWORD there, thus disrupting the
>alignment. But if this is the case, then it's more important to fix
>actually guilty one... If openssl.exe crashes, can you submit map file?
>Add /m to LFLAGS in nt.mak...
>
>> Its in crypto/perlasm/x86_64-xlate.pl:558
>> Currently:
>> $v.=" READONLY DWORD";
>> Should be:
>> $v.=" READONLY ALIGN(8)";
>
>For reference, the original reason for sticking to DWORD was because
>initial ml64 versions didn't understand ALIGN(N). So that formally
>solution should be to choose between DWORD and ALIGN(8) depending on
>assembler version [and pray for DWORD to work with old version], see
>http://cvs.openssl.org/chngview?cn=22061.
>
>And in case of doubt use nasm, which is actually preferred option.
>
>
>______________________________________________________________________
>OpenSSL Project                                 http://www.openssl.org
>Development Mailing List                       [hidden email]
>Automated List Manager                           [hidden email]


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #2620] Resolved: static libs cause crash in linking application on Win64 x64 when built with default (masm) compilation...

Andy Polyakov-2
> The latest snapshot that has this checkin, has a Perl syntax error on line
> 573
> of crypto/perlasm/x86_64-xlate.pl (missing ; on the line above)
>
> Using perl 5.8.4 on Solaris 10.

Ooops. Fixed. Thanks.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]