x86gas.pl, 1.0.1j, MacOSX, x86 assembler, .comm directive

[Patrick Middleton]

Hi folks

I have been building OpenSSL 1.0.1j on assorted MacOSX releases of
various ages, and encountered a failure

=-=-=-=-=-=-=-=-=-=-=
x86cpuid.s:327:Rest of line ignored. 1st junk character valued 44 (,).
=-=-=-=-=-=-=-=-=-=-=

when building on 10.4.11/ppc, cross-compiling for i386, when using
gcc 4.0.1. Comparable failures did not occur when building on 10.6.8/
x86_64 or 10.8.5/x86_64 for either i386 or x86_64 using gcc 4.2, or
when building OpenSSL 0.9.8zc.

I have traced this to openssl-1.0.1j/crypto/perlasm/x86gas.pl

=-=-=-=-=-=-=-=-=-=-=
sub ::file_end
{ if ($::macosx)
{ if (%non_lazy_ptr)
{ push(@out,".section
__IMPORT,__pointers,non_lazy_symbol_pointers\n");
foreach $i (keys %non_lazy_ptr)
{ push(@out,"$non_lazy_ptr{$i}:\n.indirect_symbol\t$i\n.long\t0
\n"); }
}
}
if (grep {/\b${nmdecor}OPENSSL_ia32cap_P\b/i} @out) {
my $tmp=".comm\t${nmdecor}OPENSSL_ia32cap_P,8";
if ($::macosx) { push (@out,"$tmp,2\n"); }
elsif ($::elf) { push (@out,"$tmp,4\n"); }
else { push (@out,"$tmp\n"); }
}
push(@out,$initseg) if ($initseg);
}
=-=-=-=-=-=-=-=-=-=-=

At some point, which in my ignorance I believe to be http://
git.openssl.org/gitweb/?
p=openssl.git;a=commitdiff;h=4a5397fb68279702e6e0b20c514ff18713bdd38b ,
sub ::file_end was modified so that on Darwin/i386, openssl-1.0.1j/
crypto/x86cpuid.s would end

=-=-=-=-=-=-=-=-=-=-=
.section __IMPORT,__pointers,non_lazy_symbol_pointers
L_OPENSSL_ia32cap_P$non_lazy_ptr:
.indirect_symbol _OPENSSL_ia32cap_P
.long 0
-.comm _OPENSSL_ia32cap_P,8
+.comm _OPENSSL_ia32cap_P,8,2
.mod_init_func
.align 2
.long _OPENSSL_cpuid_setup
=-=-=-=-=-=-=-=-=-=-=

and that does not sit well with the documentation for MacOSX i386
assembler:
https://developer.apple.com/library/mac/documentation/DeveloperTools/
Reference/Assembler/040-Assembler_Directives/asm_directives.html
suggesting that the .comm directive takes two operands, while .lcomm
takes an optional third operand.

Other documentation https://sourceware.org/binutils/docs/as/Comm.html
states "When using ELF or (as a GNU extension) PE, the .comm
directive takes an optional third argument". 32-bit MacOSX uses
neither ELF nor PE. The third argument ought to be redundant here;
the default natural alignment as described in the Apple developer
documentation ought to be adequate.

It's not clear to me that me ought to do anything; this is a problem
only when building using compilers for MacOSX releases that have long
since been EOLed.


______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org

[Andy Polyakov]

Hi,

Thanks for report. Good job.

Post by Patrick Middleton
and that does not sit well with the documentation for MacOSX i386
https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/Assembler/040-Assembler_Directives/asm_directives.html
suggesting that the .comm directive takes two operands, while .lcomm
takes an optional third operand.
Other documentation https://sourceware.org/binutils/docs/as/Comm.html
states "When using ELF or (as a GNU extension) PE, the .comm directive
takes an optional third argument". 32-bit MacOSX uses neither ELF nor
PE. The third argument ought to be redundant here; the default natural
alignment as described in the Apple developer documentation ought to be
adequate.

Apple 'as' stems from some ancient version and you shouldn't try to
apply contemporary documentation literally. The fact that it didn't
accept alignment for .comm was obviously missing feature (the fact that
it was fixed is the proof). The reason for change on MacOS was desire to
keep things harmonized with other platforms.

Post by Patrick Middleton
It's not clear to me that me ought to do anything; this is a problem
only when building using compilers for MacOSX releases that have long
since been EOLed.

Well, if you can confirm following, then it would still be appropriate
to revert that change. Compile following snippet with -sectalign __DATA
__common 4 argument and post nm output for resulting binary.

.text
.globl _main
_main:
ret

.comm _one,4
.comm _two,8
.comm _four,16

Goal is to confirm that _two and _four are actually aligned at their
sized even though section alignment is relaxed.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org

[Patrick Middleton]

Post by Andy Polyakov

It's not clear to me that we ought to do anything; this is a problem
only when building using compilers for MacOSX releases that have long
since been EOLed.

Well, if you can confirm following, then it would still be appropriate
to revert that change. Compile following snippet with -sectalign __DATA
__common 4 argument and post nm output for resulting binary.
.text
.globl _main
ret
.comm _one,4
.comm _two,8
.comm _four,16
Goal is to confirm that _two and _four are actually aligned at their
sized even though section alignment is relaxed.
$ cc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -c -o
alignments.o alignments.s ; nm alignments.o
00000010 C _four
00000000 T _main
00000004 C _one
00000008 C _two

... and I'll own up to not knowing for certain whether that's the
answer for which we were looking!

-- Patrick
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org

[Patrick Middleton]

Post by Andy Polyakov

Post by Patrick Middleton
It's not clear to me that me ought to do anything; this is a problem
only when building using compilers for MacOSX releases that have long
since been EOLed.

Well, if you can confirm following, then it would still be appropriate
to revert that change. Compile following snippet with -sectalign __DATA
__common 4 argument and post nm output for resulting binary.
.text
.globl _main
ret
.comm _one,4
.comm _two,8
.comm _four,16
Goal is to confirm that _two and _four are actually aligned at their
sized even though section alignment is relaxed.

Having done some more research, I'm still not sure I understand the
output, but I did at least remember to include the requested
arguments. Same output.

Post by Andy Polyakov
cc -arch i386 -sectalign __DATA __common 4 -isysroot /Developer/
SDKs/MacOSX10.4u.sdk -c -o alignments.o alignments.s ; nm alignments.o
00000010 C _four
00000000 T _main
00000004 C _one
00000008 C _two

-- Patrick
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org

[Patrick Middleton]

Post by Andy Polyakov

It's not clear to me that we ought to do anything; this is a problem
only when building using compilers for MacOSX releases that have long
since been EOLed.

Well, if you can confirm following, then it would still be appropriate
to revert that change. Compile following snippet with -sectalign
__DATA
__common 4 argument and post nm output for resulting binary.
.text
.globl _main
ret
.comm _one,4
.comm _two,8
.comm _four,16
Goal is to confirm that _two and _four are actually aligned at their
sized even though section alignment is relaxed.
$ cc -arch i386 -sectalign __DATA __common 4 -isysroot /Developer/
SDKs/MacOSX10.4u.sdk -c -o alignments.o alignments.s ; nm alignments.o
00000010 C _four
00000000 T _main
00000004 C _one
00000008 C _two

... and I'll own up to not knowing for certain whether that's the
answer for which we were looking!

-- Patrick


______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org

[Andy Polyakov]

Post by Andy Polyakov

It's not clear to me that we ought to do anything; this is a problem
only when building using compilers for MacOSX releases that have long
since been EOLed.

Well, if you can confirm following, then it would still be appropriate
to revert that change. Compile following snippet with -sectalign __DATA
__common 4 argument and post nm output for resulting binary.
.text
.globl _main
ret
.comm _one,4
.comm _two,8
.comm _four,16
Goal is to confirm that _two and _four are actually aligned at their
sized even though section alignment is relaxed.
$ cc -arch i386 -sectalign __DATA __common 4 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -c -o alignments.o alignments.s ; nm
alignments.o
00000010 C _four
00000000 T _main
00000004 C _one
00000008 C _two

No, not -c, but all the way so that it generates executable. Question is
what is alignment of these variables in *final* executable, not
intermediate .o. I should have been more explicit, sorry.

______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-***@openssl.org
Automated List Manager ***@openssl.org