Support for .asciz directive in perlasm modules.

[openssl.git] / crypto / perlasm / x86_64-xlate.pl

diff --git a/crypto/perlasm/x86_64-xlate.pl b/crypto/perlasm/x86_64-xlate.pl
index 7487249c7922fef0380d49b17054ab151aca0e07..4370a97b6af2c2552ee7c675b3bb540a07c29589 100755 (executable)
--- a/crypto/perlasm/x86_64-xlate.pl
+++ b/crypto/perlasm/x86_64-xlate.pl
@@ -133,6 +133,10 @@ my $current_function;
        my $self = shift;
 
        if (!$masm) {
+           # Solaris /usr/ccs/bin/as can't handle multiplications
+           # in $self->{value}
+           $self->{value} =~ s/(?<![0-9a-f])(0[x0-9a-f]+)/oct($1)/egi;
+           $self->{value} =~ s/([0-9]+\s*[\*\/\%]\s*[0-9]+)/eval($1)/eg;
            sprintf "\$%s",$self->{value};
        } else {
            $self->{value} =~ s/0x([0-9a-f]+)/0$1h/ig;
@@ -163,11 +167,17 @@ my $current_function;
        my $self = shift;
        my $sz = shift;
 
+       # Silently convert all EAs to 64-bit. This is required for
+       # elder GNU assembler and results in more compact code,
+       # *but* most importantly AES module depends on this feature!
+       $self->{index} =~ s/^[er](.?[0-9xpi])[d]?$/r\1/;
+       $self->{base}  =~ s/^[er](.?[0-9xpi])[d]?$/r\1/;
+
        if (!$masm) {
-           # elder GNU assembler insists on 64-bit EAs:-(
-           # on pros side, this results in more compact code:-)
-           $self->{index} =~ s/^[er](.?[0-9xp])[d]?$/r\1/;
-           $self->{base}  =~ s/^[er](.?[0-9xp])[d]?$/r\1/;
+           # Solaris /usr/ccs/bin/as can't handle multiplications
+           # in $self->{label}
+           $self->{label} =~ s/(?<![0-9a-f])(0[x0-9a-f]+)/oct($1)/egi;
+           $self->{label} =~ s/([0-9]+\s*[\*\/\%]\s*[0-9]+)/eval($1)/eg;
 
            if (defined($self->{index})) {
                sprintf "%s(%%%s,%%%s,%d)",
@@ -313,6 +323,8 @@ my $current_function;
                $line =~ s/\@function.*/\@function/;
                if ($line =~ /\.picmeup\s+(%r[\w]+)/i) {
                    $self->{value} = sprintf "\t.long\t0x%x,0x90000000",$opcode{$1};
+               } elsif ($line =~ /\.asciz\s+"(.*)"$/) {
+                   $self->{value} = ".byte\t".join(",",unpack("C*",$1),0);
                } else {
                    $self->{value} = $line;
                }
@@ -325,12 +337,12 @@ my $current_function;
            undef $self->{value};
            $line = substr($line,@+[0]); $line =~ s/^\s+//;
            SWITCH: for ($dir) {
-               /\.(text|data)/
+               /\.(text)/
                            && do { my $v=undef;
                                    $v="$current_segment\tENDS\n" if ($current_segment);
-                                   $current_segment = "_$1";
+                                   $current_segment = "_$1\$";
                                    $current_segment =~ tr/[a-z]/[A-Z]/;
-                                   $v.="$current_segment\tSEGMENT PARA";
+                                   $v.="$current_segment\tSEGMENT ALIGN(64) 'CODE'";
                                    $self->{value} = $v;
                                    last;
                                  };
@@ -368,6 +380,12 @@ my $current_function;
                /\.picmeup/ && do { $self->{value} = sprintf"\tDD\t 0%Xh,090000000h",$opcode{$line};
                                    last;
                                  };
+               /\.asciz/   && do { if ($line =~ /^"(.*)"$/) {
+                                       $self->{value} = "DB\t"
+                                               .join(",",unpack("C*",$1),0);
+                                   }
+                                   last;
+                                 };
            }
            $line = "";
        }
@@ -476,7 +494,10 @@ close STDOUT;
 # arguments passed to callee, *but* not less than 4! This means that
 # upon function entry point 5th argument resides at 40(%rsp), as well
 # as that 32 bytes from 8(%rsp) can always be used as temporal
-# storage [without allocating a frame].
+# storage [without allocating a frame]. One can actually argue that
+# one can assume a "red zone" above stack pointer under Win64 as well.
+# Point is that at apparently no occasion Windows kernel would alter
+# the area above user stack pointer in true asynchronous manner...
 #
 # All the above means that if assembler programmer adheres to Unix
 # register and stack layout, but disregards the "red zone" existense,