Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
#! /usr/bin/env perl
|
|
|
|
|
# Copyright 2005-2016 The OpenSSL Project Authors. All Rights Reserved.
|
|
|
|
|
#
|
|
|
|
|
# Licensed under the OpenSSL license (the "License"). You may not use
|
|
|
|
|
# this file except in compliance with the License. You can obtain a copy
|
|
|
|
|
# in the file LICENSE in the source distribution or at
|
|
|
|
|
# https://www.openssl.org/source/license.html
|
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
# Ascetic x86_64 AT&T to MASM/NASM assembler translator by <appro>.
|
|
|
|
|
#
|
|
|
|
|
# Why AT&T to MASM and not vice versa? Several reasons. Because AT&T
|
|
|
|
|
# format is way easier to parse. Because it's simpler to "gear" from
|
|
|
|
|
# Unix ABI to Windows one [see cross-reference "card" at the end of
|
|
|
|
|
# file]. Because Linux targets were available first...
|
|
|
|
|
#
|
|
|
|
|
# In addition the script also "distills" code suitable for GNU
|
|
|
|
|
# assembler, so that it can be compiled with more rigid assemblers,
|
|
|
|
|
# such as Solaris /usr/ccs/bin/as.
|
|
|
|
|
#
|
|
|
|
|
# This translator is not designed to convert *arbitrary* assembler
|
|
|
|
|
# code from AT&T format to MASM one. It's designed to convert just
|
|
|
|
|
# enough to provide for dual-ABI OpenSSL modules development...
|
|
|
|
|
# There *are* limitations and you might have to modify your assembler
|
|
|
|
|
# code or this script to achieve the desired result...
|
|
|
|
|
#
|
|
|
|
|
# Currently recognized limitations:
|
|
|
|
|
#
|
|
|
|
|
# - can't use multiple ops per line;
|
|
|
|
|
#
|
|
|
|
|
# Dual-ABI styling rules.
|
|
|
|
|
#
|
|
|
|
|
# 1. Adhere to Unix register and stack layout [see cross-reference
|
|
|
|
|
# ABI "card" at the end for explanation].
|
|
|
|
|
# 2. Forget about "red zone," stick to more traditional blended
|
|
|
|
|
# stack frame allocation. If volatile storage is actually required
|
|
|
|
|
# that is. If not, just leave the stack as is.
|
|
|
|
|
# 3. Functions tagged with ".type name,@function" get crafted with
|
|
|
|
|
# unified Win64 prologue and epilogue automatically. If you want
|
|
|
|
|
# to take care of ABI differences yourself, tag functions as
|
|
|
|
|
# ".type name,@abi-omnipotent" instead.
|
|
|
|
|
# 4. To optimize the Win64 prologue you can specify number of input
|
|
|
|
|
# arguments as ".type name,@function,N." Keep in mind that if N is
|
|
|
|
|
# larger than 6, then you *have to* write "abi-omnipotent" code,
|
|
|
|
|
# because >6 cases can't be addressed with unified prologue.
|
|
|
|
|
# 5. Name local labels as .L*, do *not* use dynamic labels such as 1:
|
|
|
|
|
# (sorry about latter).
|
|
|
|
|
# 6. Don't use [or hand-code with .byte] "rep ret." "ret" mnemonic is
|
|
|
|
|
# required to identify the spots, where to inject Win64 epilogue!
|
|
|
|
|
# But on the pros, it's then prefixed with rep automatically:-)
|
|
|
|
|
# 7. Stick to explicit ip-relative addressing. If you have to use
|
|
|
|
|
# GOTPCREL addressing, stick to mov symbol@GOTPCREL(%rip),%r??.
|
|
|
|
|
# Both are recognized and translated to proper Win64 addressing
|
2017-02-09 19:27:49 +00:00
|
|
|
|
# modes.
|
2014-06-20 20:00:00 +01:00
|
|
|
|
#
|
|
|
|
|
# 8. In order to provide for structured exception handling unified
|
|
|
|
|
# Win64 prologue copies %rsp value to %rax. For further details
|
|
|
|
|
# see SEH paragraph at the end.
|
|
|
|
|
# 9. .init segment is allowed to contain calls to functions only.
|
|
|
|
|
# a. If function accepts more than 4 arguments *and* >4th argument
|
|
|
|
|
# is declared as non 64-bit value, do clear its upper part.
|
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
|
|
|
|
|
use strict;
|
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
|
my $flavour = shift;
|
|
|
|
|
my $output = shift;
|
|
|
|
|
if ($flavour =~ /\./) { $output = $flavour; undef $flavour; }
|
|
|
|
|
|
|
|
|
|
open STDOUT,">$output" || die "can't open $output: $!"
|
|
|
|
|
if (defined($output));
|
|
|
|
|
|
|
|
|
|
my $gas=1; $gas=0 if ($output =~ /\.asm$/);
|
|
|
|
|
my $elf=1; $elf=0 if (!$gas);
|
|
|
|
|
my $win64=0;
|
|
|
|
|
my $prefix="";
|
|
|
|
|
my $decor=".L";
|
|
|
|
|
|
|
|
|
|
my $masmref=8 + 50727*2**-32; # 8.00.50727 shipped with VS2005
|
|
|
|
|
my $masm=0;
|
|
|
|
|
my $PTR=" PTR";
|
|
|
|
|
|
|
|
|
|
my $nasmref=2.03;
|
|
|
|
|
my $nasm=0;
|
|
|
|
|
|
|
|
|
|
if ($flavour eq "mingw64") { $gas=1; $elf=0; $win64=1;
|
2015-10-14 19:03:23 +01:00
|
|
|
|
# TODO(davidben): Before supporting the
|
|
|
|
|
# mingw64 perlasm flavour, do away with this
|
|
|
|
|
# environment variable check.
|
|
|
|
|
die "mingw64 not supported";
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$prefix=`echo __USER_LABEL_PREFIX__ | $ENV{CC} -E -P -`;
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$prefix =~ s|\R$||; # Better chomp
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
elsif ($flavour eq "macosx") { $gas=1; $elf=0; $prefix="_"; $decor="L\$"; }
|
|
|
|
|
elsif ($flavour eq "masm") { $gas=0; $elf=0; $masm=$masmref; $win64=1; $decor="\$L\$"; }
|
|
|
|
|
elsif ($flavour eq "nasm") { $gas=0; $elf=0; $nasm=$nasmref; $win64=1; $decor="\$L\$"; $PTR=""; }
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
elsif (!$gas) { die "unknown flavour $flavour"; }
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
my $current_segment;
|
|
|
|
|
my $current_function;
|
|
|
|
|
my %globals;
|
|
|
|
|
|
|
|
|
|
{ package opcode; # pick up opcodes
|
|
|
|
|
sub re {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my ($class, $line) = @_;
|
|
|
|
|
my $self = {};
|
|
|
|
|
my $ret;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
if ($$line =~ /^([a-z][a-z0-9]*)/i) {
|
|
|
|
|
bless $self,$class;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$self->{op} = $1;
|
|
|
|
|
$ret = $self;
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
undef $self->{sz};
|
|
|
|
|
if ($self->{op} =~ /^(movz)x?([bw]).*/) { # movz is pain...
|
|
|
|
|
$self->{op} = $1;
|
|
|
|
|
$self->{sz} = $2;
|
|
|
|
|
} elsif ($self->{op} =~ /call|jmp/) {
|
|
|
|
|
$self->{sz} = "";
|
|
|
|
|
} elsif ($self->{op} =~ /^p/ && $' !~ /^(ush|op|insrw)/) { # SSEn
|
|
|
|
|
$self->{sz} = "";
|
2017-02-09 19:19:16 +00:00
|
|
|
|
} elsif ($self->{op} =~ /^[vk]/) { # VEX or k* such as kmov
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$self->{sz} = "";
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
} elsif ($self->{op} =~ /mov[dq]/ && $$line =~ /%xmm/) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$self->{sz} = "";
|
|
|
|
|
} elsif ($self->{op} =~ /([a-z]{3,})([qlwb])$/) {
|
|
|
|
|
$self->{op} = $1;
|
|
|
|
|
$self->{sz} = $2;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
$ret;
|
|
|
|
|
}
|
|
|
|
|
sub size {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my ($self, $sz) = @_;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$self->{sz} = $sz if (defined($sz) && !defined($self->{sz}));
|
|
|
|
|
$self->{sz};
|
|
|
|
|
}
|
|
|
|
|
sub out {
|
|
|
|
|
my $self = shift;
|
|
|
|
|
if ($gas) {
|
|
|
|
|
if ($self->{op} eq "movz") { # movz is pain...
|
|
|
|
|
sprintf "%s%s%s",$self->{op},$self->{sz},shift;
|
2017-02-09 19:38:21 +00:00
|
|
|
|
} elsif ($self->{op} =~ /^set/) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
"$self->{op}";
|
|
|
|
|
} elsif ($self->{op} eq "ret") {
|
|
|
|
|
my $epilogue = "";
|
|
|
|
|
if ($win64 && $current_function->{abi} eq "svr4") {
|
|
|
|
|
$epilogue = "movq 8(%rsp),%rdi\n\t" .
|
|
|
|
|
"movq 16(%rsp),%rsi\n\t";
|
|
|
|
|
}
|
|
|
|
|
$epilogue . ".byte 0xf3,0xc3";
|
|
|
|
|
} elsif ($self->{op} eq "call" && !$elf && $current_segment eq ".init") {
|
|
|
|
|
".p2align\t3\n\t.quad";
|
|
|
|
|
} else {
|
|
|
|
|
"$self->{op}$self->{sz}";
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
$self->{op} =~ s/^movz/movzx/;
|
|
|
|
|
if ($self->{op} eq "ret") {
|
|
|
|
|
$self->{op} = "";
|
|
|
|
|
if ($win64 && $current_function->{abi} eq "svr4") {
|
2016-06-26 19:21:34 +01:00
|
|
|
|
$self->{op} = "mov rdi,QWORD$PTR\[8+rsp\]\t;WIN64 epilogue\n\t".
|
|
|
|
|
"mov rsi,QWORD$PTR\[16+rsp\]\n\t";
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
$self->{op} .= "DB\t0F3h,0C3h\t\t;repret";
|
|
|
|
|
} elsif ($self->{op} =~ /^(pop|push)f/) {
|
|
|
|
|
$self->{op} .= $self->{sz};
|
|
|
|
|
} elsif ($self->{op} eq "call" && $current_segment eq ".CRT\$XCU") {
|
|
|
|
|
$self->{op} = "\tDQ";
|
2017-02-09 19:38:21 +00:00
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$self->{op};
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
sub mnemonic {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my ($self, $op) = @_;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$self->{op}=$op if (defined($op));
|
|
|
|
|
$self->{op};
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
{ package const; # pick up constants, which start with $
|
|
|
|
|
sub re {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my ($class, $line) = @_;
|
|
|
|
|
my $self = {};
|
|
|
|
|
my $ret;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
if ($$line =~ /^\$([^,]+)/) {
|
|
|
|
|
bless $self, $class;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$self->{value} = $1;
|
|
|
|
|
$ret = $self;
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
$ret;
|
|
|
|
|
}
|
|
|
|
|
sub out {
|
|
|
|
|
my $self = shift;
|
|
|
|
|
|
2016-03-14 23:18:14 +00:00
|
|
|
|
$self->{value} =~ s/\b(0b[0-1]+)/oct($1)/eig;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
if ($gas) {
|
|
|
|
|
# Solaris /usr/ccs/bin/as can't handle multiplications
|
|
|
|
|
# in $self->{value}
|
2016-02-26 15:48:59 +00:00
|
|
|
|
my $value = $self->{value};
|
2016-06-26 19:21:34 +01:00
|
|
|
|
no warnings; # oct might complain about overflow, ignore here...
|
2016-02-26 15:48:59 +00:00
|
|
|
|
$value =~ s/(?<![\w\$\.])(0x?[0-9a-f]+)/oct($1)/egi;
|
|
|
|
|
if ($value =~ s/([0-9]+\s*[\*\/\%]\s*[0-9]+)/eval($1)/eg) {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$self->{value} = $value;
|
2016-02-26 15:48:59 +00:00
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
sprintf "\$%s",$self->{value};
|
|
|
|
|
} else {
|
2017-05-05 23:03:06 +01:00
|
|
|
|
my $value = $self->{value};
|
|
|
|
|
$value =~ s/0x([0-9a-f]+)/0$1h/ig if ($masm);
|
|
|
|
|
sprintf "%s",$value;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
{ package ea; # pick up effective addresses: expr(%reg,%reg,scale)
|
2017-02-09 19:27:11 +00:00
|
|
|
|
|
|
|
|
|
my %szmap = ( b=>"BYTE$PTR", w=>"WORD$PTR",
|
|
|
|
|
l=>"DWORD$PTR", d=>"DWORD$PTR",
|
|
|
|
|
q=>"QWORD$PTR", o=>"OWORD$PTR",
|
|
|
|
|
x=>"XMMWORD$PTR", y=>"YMMWORD$PTR",
|
|
|
|
|
z=>"ZMMWORD$PTR" ) if (!$gas);
|
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
|
sub re {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my ($class, $line, $opcode) = @_;
|
|
|
|
|
my $self = {};
|
|
|
|
|
my $ret;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
2016-06-26 19:21:34 +01:00
|
|
|
|
# optional * ----vvv--- appears in indirect jmp/call
|
2017-02-09 19:19:16 +00:00
|
|
|
|
if ($$line =~ /^(\*?)([^\(,]*)\(([%\w,]+)\)((?:{[^}]+})*)/) {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
bless $self, $class;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$self->{asterisk} = $1;
|
|
|
|
|
$self->{label} = $2;
|
|
|
|
|
($self->{base},$self->{index},$self->{scale})=split(/,/,$3);
|
|
|
|
|
$self->{scale} = 1 if (!defined($self->{scale}));
|
2017-02-09 19:27:11 +00:00
|
|
|
|
$self->{opmask} = $4;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$ret = $self;
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
if ($win64 && $self->{label} =~ s/\@GOTPCREL//) {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
die if ($opcode->mnemonic() ne "mov");
|
|
|
|
|
$opcode->mnemonic("lea");
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
$self->{base} =~ s/^%//;
|
|
|
|
|
$self->{index} =~ s/^%// if (defined($self->{index}));
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$self->{opcode} = $opcode;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
$ret;
|
|
|
|
|
}
|
|
|
|
|
sub size {}
|
|
|
|
|
sub out {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my ($self, $sz) = @_;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
$self->{label} =~ s/([_a-z][_a-z0-9]*)/$globals{$1} or $1/gei;
|
|
|
|
|
$self->{label} =~ s/\.L/$decor/g;
|
|
|
|
|
|
|
|
|
|
# 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/;
|
|
|
|
|
|
|
|
|
|
# Solaris /usr/ccs/bin/as can't handle multiplications
|
2016-12-14 16:29:38 +00:00
|
|
|
|
# in $self->{label}...
|
2014-06-20 20:00:00 +01:00
|
|
|
|
use integer;
|
|
|
|
|
$self->{label} =~ s/(?<![\w\$\.])(0x?[0-9a-f]+)/oct($1)/egi;
|
|
|
|
|
$self->{label} =~ s/\b([0-9]+\s*[\*\/\%]\s*[0-9]+)\b/eval($1)/eg;
|
2016-12-14 16:29:38 +00:00
|
|
|
|
|
|
|
|
|
# Some assemblers insist on signed presentation of 32-bit
|
|
|
|
|
# offsets, but sign extension is a tricky business in perl...
|
|
|
|
|
if ((1<<31)<<1) {
|
|
|
|
|
$self->{label} =~ s/\b([0-9]+)\b/$1<<32>>32/eg;
|
|
|
|
|
} else {
|
|
|
|
|
$self->{label} =~ s/\b([0-9]+)\b/$1>>0/eg;
|
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
2017-02-09 19:27:11 +00:00
|
|
|
|
# if base register is %rbp or %r13, see if it's possible to
|
2017-02-16 22:12:36 +00:00
|
|
|
|
# flip base and index registers [for better performance]
|
2014-06-20 20:00:00 +01:00
|
|
|
|
if (!$self->{label} && $self->{index} && $self->{scale}==1 &&
|
|
|
|
|
$self->{base} =~ /(rbp|r13)/) {
|
|
|
|
|
$self->{base} = $self->{index}; $self->{index} = $1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ($gas) {
|
|
|
|
|
$self->{label} =~ s/^___imp_/__imp__/ if ($flavour eq "mingw64");
|
|
|
|
|
|
|
|
|
|
if (defined($self->{index})) {
|
2017-02-09 19:19:16 +00:00
|
|
|
|
sprintf "%s%s(%s,%%%s,%d)%s",
|
|
|
|
|
$self->{asterisk},$self->{label},
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$self->{base}?"%$self->{base}":"",
|
2017-02-09 19:19:16 +00:00
|
|
|
|
$self->{index},$self->{scale},
|
2017-02-09 19:27:11 +00:00
|
|
|
|
$self->{opmask};
|
2014-06-20 20:00:00 +01:00
|
|
|
|
} else {
|
2017-02-09 19:19:16 +00:00
|
|
|
|
sprintf "%s%s(%%%s)%s", $self->{asterisk},$self->{label},
|
2017-02-09 19:27:11 +00:00
|
|
|
|
$self->{base},$self->{opmask};
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
$self->{label} =~ s/\./\$/g;
|
|
|
|
|
$self->{label} =~ s/(?<![\w\$\.])0x([0-9a-f]+)/0$1h/ig;
|
|
|
|
|
$self->{label} = "($self->{label})" if ($self->{label} =~ /[\*\+\-\/]/);
|
2014-07-25 02:10:23 +01:00
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my $mnemonic = $self->{opcode}->mnemonic();
|
|
|
|
|
($self->{asterisk}) && ($sz="q") ||
|
|
|
|
|
($mnemonic =~ /^v?mov([qd])$/) && ($sz=$1) ||
|
|
|
|
|
($mnemonic =~ /^v?pinsr([qdwb])$/) && ($sz=$1) ||
|
|
|
|
|
($mnemonic =~ /^vpbroadcast([qdwb])$/) && ($sz=$1) ||
|
|
|
|
|
($mnemonic =~ /^v(?!perm)[a-z]+[fi]128$/) && ($sz="x");
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
2017-02-09 19:27:11 +00:00
|
|
|
|
$self->{opmask} =~ s/%(k[0-7])/$1/;
|
2017-02-09 19:19:16 +00:00
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
|
if (defined($self->{index})) {
|
2017-02-09 19:19:16 +00:00
|
|
|
|
sprintf "%s[%s%s*%d%s]%s",$szmap{$sz},
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$self->{label}?"$self->{label}+":"",
|
|
|
|
|
$self->{index},$self->{scale},
|
2017-02-09 19:19:16 +00:00
|
|
|
|
$self->{base}?"+$self->{base}":"",
|
2017-02-09 19:27:11 +00:00
|
|
|
|
$self->{opmask};
|
2014-06-20 20:00:00 +01:00
|
|
|
|
} elsif ($self->{base} eq "rip") {
|
|
|
|
|
sprintf "%s[%s]",$szmap{$sz},$self->{label};
|
|
|
|
|
} else {
|
2017-02-09 19:19:16 +00:00
|
|
|
|
sprintf "%s[%s%s]%s", $szmap{$sz},
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$self->{label}?"$self->{label}+":"",
|
2017-02-09 19:27:11 +00:00
|
|
|
|
$self->{base},$self->{opmask};
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
{ package register; # pick up registers, which start with %.
|
|
|
|
|
sub re {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my ($class, $line, $opcode) = @_;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
my $self = {};
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my $ret;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
# optional * ----vvv--- appears in indirect jmp/call
|
2017-02-09 19:19:16 +00:00
|
|
|
|
if ($$line =~ /^(\*?)%(\w+)((?:{[^}]+})*)/) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
bless $self,$class;
|
|
|
|
|
$self->{asterisk} = $1;
|
|
|
|
|
$self->{value} = $2;
|
2017-02-09 19:27:11 +00:00
|
|
|
|
$self->{opmask} = $3;
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$opcode->size($self->size());
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$ret = $self;
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
$ret;
|
|
|
|
|
}
|
|
|
|
|
sub size {
|
|
|
|
|
my $self = shift;
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my $ret;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
if ($self->{value} =~ /^r[\d]+b$/i) { $ret="b"; }
|
|
|
|
|
elsif ($self->{value} =~ /^r[\d]+w$/i) { $ret="w"; }
|
|
|
|
|
elsif ($self->{value} =~ /^r[\d]+d$/i) { $ret="l"; }
|
|
|
|
|
elsif ($self->{value} =~ /^r[\w]+$/i) { $ret="q"; }
|
|
|
|
|
elsif ($self->{value} =~ /^[a-d][hl]$/i){ $ret="b"; }
|
|
|
|
|
elsif ($self->{value} =~ /^[\w]{2}l$/i) { $ret="b"; }
|
|
|
|
|
elsif ($self->{value} =~ /^[\w]{2}$/i) { $ret="w"; }
|
|
|
|
|
elsif ($self->{value} =~ /^e[a-z]{2}$/i){ $ret="l"; }
|
|
|
|
|
|
|
|
|
|
$ret;
|
|
|
|
|
}
|
|
|
|
|
sub out {
|
|
|
|
|
my $self = shift;
|
2017-02-09 19:19:16 +00:00
|
|
|
|
if ($gas) { sprintf "%s%%%s%s", $self->{asterisk},
|
|
|
|
|
$self->{value},
|
2017-02-09 19:27:11 +00:00
|
|
|
|
$self->{opmask}; }
|
|
|
|
|
else { $self->{opmask} =~ s/%(k[0-7])/$1/;
|
|
|
|
|
$self->{value}.$self->{opmask}; }
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
{ package label; # pick up labels, which end with :
|
|
|
|
|
sub re {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my ($class, $line) = @_;
|
|
|
|
|
my $self = {};
|
|
|
|
|
my $ret;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
if ($$line =~ /(^[\.\w]+)\:/) {
|
|
|
|
|
bless $self,$class;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$self->{value} = $1;
|
|
|
|
|
$ret = $self;
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
$self->{value} =~ s/^\.L/$decor/;
|
|
|
|
|
}
|
|
|
|
|
$ret;
|
|
|
|
|
}
|
|
|
|
|
sub out {
|
|
|
|
|
my $self = shift;
|
|
|
|
|
|
|
|
|
|
if ($gas) {
|
|
|
|
|
my $func = ($globals{$self->{value}} or $self->{value}) . ":";
|
2017-02-09 19:27:11 +00:00
|
|
|
|
if ($win64 && $current_function->{name} eq $self->{value}
|
|
|
|
|
&& $current_function->{abi} eq "svr4") {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$func .= "\n";
|
|
|
|
|
$func .= " movq %rdi,8(%rsp)\n";
|
|
|
|
|
$func .= " movq %rsi,16(%rsp)\n";
|
|
|
|
|
$func .= " movq %rsp,%rax\n";
|
|
|
|
|
$func .= "${decor}SEH_begin_$current_function->{name}:\n";
|
|
|
|
|
my $narg = $current_function->{narg};
|
|
|
|
|
$narg=6 if (!defined($narg));
|
|
|
|
|
$func .= " movq %rcx,%rdi\n" if ($narg>0);
|
|
|
|
|
$func .= " movq %rdx,%rsi\n" if ($narg>1);
|
|
|
|
|
$func .= " movq %r8,%rdx\n" if ($narg>2);
|
|
|
|
|
$func .= " movq %r9,%rcx\n" if ($narg>3);
|
|
|
|
|
$func .= " movq 40(%rsp),%r8\n" if ($narg>4);
|
|
|
|
|
$func .= " movq 48(%rsp),%r9\n" if ($narg>5);
|
|
|
|
|
}
|
|
|
|
|
$func;
|
|
|
|
|
} elsif ($self->{value} ne "$current_function->{name}") {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
# Make all labels in masm global.
|
|
|
|
|
$self->{value} .= ":" if ($masm);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$self->{value} . ":";
|
|
|
|
|
} elsif ($win64 && $current_function->{abi} eq "svr4") {
|
|
|
|
|
my $func = "$current_function->{name}" .
|
|
|
|
|
($nasm ? ":" : "\tPROC $current_function->{scope}") .
|
|
|
|
|
"\n";
|
2016-06-26 19:21:34 +01:00
|
|
|
|
$func .= " mov QWORD$PTR\[8+rsp\],rdi\t;WIN64 prologue\n";
|
|
|
|
|
$func .= " mov QWORD$PTR\[16+rsp\],rsi\n";
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$func .= " mov rax,rsp\n";
|
|
|
|
|
$func .= "${decor}SEH_begin_$current_function->{name}:";
|
|
|
|
|
$func .= ":" if ($masm);
|
|
|
|
|
$func .= "\n";
|
|
|
|
|
my $narg = $current_function->{narg};
|
|
|
|
|
$narg=6 if (!defined($narg));
|
|
|
|
|
$func .= " mov rdi,rcx\n" if ($narg>0);
|
|
|
|
|
$func .= " mov rsi,rdx\n" if ($narg>1);
|
|
|
|
|
$func .= " mov rdx,r8\n" if ($narg>2);
|
|
|
|
|
$func .= " mov rcx,r9\n" if ($narg>3);
|
2016-06-26 19:21:34 +01:00
|
|
|
|
$func .= " mov r8,QWORD$PTR\[40+rsp\]\n" if ($narg>4);
|
|
|
|
|
$func .= " mov r9,QWORD$PTR\[48+rsp\]\n" if ($narg>5);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$func .= "\n";
|
|
|
|
|
} else {
|
|
|
|
|
"$current_function->{name}".
|
|
|
|
|
($nasm ? ":" : "\tPROC $current_function->{scope}");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2017-02-16 17:47:01 +00:00
|
|
|
|
{ package expr; # pick up expressions
|
2014-06-20 20:00:00 +01:00
|
|
|
|
sub re {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my ($class, $line, $opcode) = @_;
|
|
|
|
|
my $self = {};
|
|
|
|
|
my $ret;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
if ($$line =~ /(^[^,]+)/) {
|
|
|
|
|
bless $self,$class;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$self->{value} = $1;
|
|
|
|
|
$ret = $self;
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
$self->{value} =~ s/\@PLT// if (!$elf);
|
|
|
|
|
$self->{value} =~ s/([_a-z][_a-z0-9]*)/$globals{$1} or $1/gei;
|
|
|
|
|
$self->{value} =~ s/\.L/$decor/g;
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$self->{opcode} = $opcode;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
$ret;
|
|
|
|
|
}
|
|
|
|
|
sub out {
|
|
|
|
|
my $self = shift;
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
if ($nasm && $self->{opcode}->mnemonic()=~m/^j(?![re]cxz)/) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
"NEAR ".$self->{value};
|
|
|
|
|
} else {
|
|
|
|
|
$self->{value};
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2017-02-09 19:29:16 +00:00
|
|
|
|
{ package cfi_directive;
|
|
|
|
|
# CFI directives annotate instructions that are significant for
|
|
|
|
|
# stack unwinding procedure compliant with DWARF specification,
|
|
|
|
|
# see http://dwarfstd.org/. Besides naturally expected for this
|
|
|
|
|
# script platform-specific filtering function, this module adds
|
|
|
|
|
# three auxiliary synthetic directives not recognized by [GNU]
|
|
|
|
|
# assembler:
|
|
|
|
|
#
|
|
|
|
|
# - .cfi_push to annotate push instructions in prologue, which
|
|
|
|
|
# translates to .cfi_adjust_cfa_offset (if needed) and
|
|
|
|
|
# .cfi_offset;
|
|
|
|
|
# - .cfi_pop to annotate pop instructions in epilogue, which
|
|
|
|
|
# translates to .cfi_adjust_cfa_offset (if needed) and
|
|
|
|
|
# .cfi_restore;
|
|
|
|
|
# - [and most notably] .cfi_cfa_expression which encodes
|
|
|
|
|
# DW_CFA_def_cfa_expression and passes it to .cfi_escape as
|
|
|
|
|
# byte vector;
|
|
|
|
|
#
|
|
|
|
|
# CFA expressions were introduced in DWARF specification version
|
|
|
|
|
# 3 and describe how to deduce CFA, Canonical Frame Address. This
|
|
|
|
|
# becomes handy if your stack frame is variable and you can't
|
|
|
|
|
# spare register for [previous] frame pointer. Suggested directive
|
|
|
|
|
# syntax is made-up mix of DWARF operator suffixes [subset of]
|
|
|
|
|
# and references to registers with optional bias. Following example
|
|
|
|
|
# describes offloaded *original* stack pointer at specific offset
|
|
|
|
|
# from *current* stack pointer:
|
|
|
|
|
#
|
|
|
|
|
# .cfi_cfa_expression %rsp+40,deref,+8
|
|
|
|
|
#
|
|
|
|
|
# Final +8 has everything to do with the fact that CFA is defined
|
|
|
|
|
# as reference to top of caller's stack, and on x86_64 call to
|
|
|
|
|
# subroutine pushes 8-byte return address. In other words original
|
|
|
|
|
# stack pointer upon entry to a subroutine is 8 bytes off from CFA.
|
|
|
|
|
|
|
|
|
|
# Below constants are taken from "DWARF Expressions" section of the
|
|
|
|
|
# DWARF specification, section is numbered 7.7 in versions 3 and 4.
|
|
|
|
|
my %DW_OP_simple = ( # no-arg operators, mapped directly
|
|
|
|
|
deref => 0x06, dup => 0x12,
|
|
|
|
|
drop => 0x13, over => 0x14,
|
|
|
|
|
pick => 0x15, swap => 0x16,
|
|
|
|
|
rot => 0x17, xderef => 0x18,
|
|
|
|
|
|
|
|
|
|
abs => 0x19, and => 0x1a,
|
|
|
|
|
div => 0x1b, minus => 0x1c,
|
|
|
|
|
mod => 0x1d, mul => 0x1e,
|
|
|
|
|
neg => 0x1f, not => 0x20,
|
|
|
|
|
or => 0x21, plus => 0x22,
|
|
|
|
|
shl => 0x24, shr => 0x25,
|
|
|
|
|
shra => 0x26, xor => 0x27,
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
my %DW_OP_complex = ( # used in specific subroutines
|
|
|
|
|
constu => 0x10, # uleb128
|
|
|
|
|
consts => 0x11, # sleb128
|
|
|
|
|
plus_uconst => 0x23, # uleb128
|
|
|
|
|
lit0 => 0x30, # add 0-31 to opcode
|
|
|
|
|
reg0 => 0x50, # add 0-31 to opcode
|
|
|
|
|
breg0 => 0x70, # add 0-31 to opcole, sleb128
|
|
|
|
|
regx => 0x90, # uleb28
|
|
|
|
|
fbreg => 0x91, # sleb128
|
|
|
|
|
bregx => 0x92, # uleb128, sleb128
|
|
|
|
|
piece => 0x93, # uleb128
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
# Following constants are defined in x86_64 ABI supplement, for
|
2018-02-02 20:12:22 +00:00
|
|
|
|
# example available at https://www.uclibc.org/docs/psABI-x86_64.pdf,
|
2017-02-09 19:29:16 +00:00
|
|
|
|
# see section 3.7 "Stack Unwind Algorithm".
|
|
|
|
|
my %DW_reg_idx = (
|
|
|
|
|
"%rax"=>0, "%rdx"=>1, "%rcx"=>2, "%rbx"=>3,
|
|
|
|
|
"%rsi"=>4, "%rdi"=>5, "%rbp"=>6, "%rsp"=>7,
|
|
|
|
|
"%r8" =>8, "%r9" =>9, "%r10"=>10, "%r11"=>11,
|
|
|
|
|
"%r12"=>12, "%r13"=>13, "%r14"=>14, "%r15"=>15
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
my ($cfa_reg, $cfa_rsp);
|
|
|
|
|
|
|
|
|
|
# [us]leb128 format is variable-length integer representation base
|
|
|
|
|
# 2^128, with most significant bit of each byte being 0 denoting
|
2018-02-02 20:12:22 +00:00
|
|
|
|
# *last* most significant digit. See "Variable Length Data" in the
|
2017-02-09 19:29:16 +00:00
|
|
|
|
# DWARF specification, numbered 7.6 at least in versions 3 and 4.
|
|
|
|
|
sub sleb128 {
|
|
|
|
|
use integer; # get right shift extend sign
|
|
|
|
|
|
|
|
|
|
my $val = shift;
|
|
|
|
|
my $sign = ($val < 0) ? -1 : 0;
|
|
|
|
|
my @ret = ();
|
|
|
|
|
|
|
|
|
|
while(1) {
|
|
|
|
|
push @ret, $val&0x7f;
|
|
|
|
|
|
|
|
|
|
# see if remaining bits are same and equal to most
|
|
|
|
|
# significant bit of the current digit, if so, it's
|
|
|
|
|
# last digit...
|
|
|
|
|
last if (($val>>6) == $sign);
|
|
|
|
|
|
|
|
|
|
@ret[-1] |= 0x80;
|
|
|
|
|
$val >>= 7;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return @ret;
|
|
|
|
|
}
|
|
|
|
|
sub uleb128 {
|
|
|
|
|
my $val = shift;
|
|
|
|
|
my @ret = ();
|
|
|
|
|
|
|
|
|
|
while(1) {
|
|
|
|
|
push @ret, $val&0x7f;
|
|
|
|
|
|
|
|
|
|
# see if it's last significant digit...
|
|
|
|
|
last if (($val >>= 7) == 0);
|
|
|
|
|
|
|
|
|
|
@ret[-1] |= 0x80;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return @ret;
|
|
|
|
|
}
|
|
|
|
|
sub const {
|
|
|
|
|
my $val = shift;
|
|
|
|
|
|
|
|
|
|
if ($val >= 0 && $val < 32) {
|
|
|
|
|
return ($DW_OP_complex{lit0}+$val);
|
|
|
|
|
}
|
|
|
|
|
return ($DW_OP_complex{consts}, sleb128($val));
|
|
|
|
|
}
|
|
|
|
|
sub reg {
|
|
|
|
|
my $val = shift;
|
|
|
|
|
|
|
|
|
|
return if ($val !~ m/^(%r\w+)(?:([\+\-])((?:0x)?[0-9a-f]+))?/);
|
|
|
|
|
|
|
|
|
|
my $reg = $DW_reg_idx{$1};
|
|
|
|
|
my $off = eval ("0 $2 $3");
|
|
|
|
|
|
|
|
|
|
return (($DW_OP_complex{breg0} + $reg), sleb128($off));
|
|
|
|
|
# Yes, we use DW_OP_bregX+0 to push register value and not
|
|
|
|
|
# DW_OP_regX, because latter would require even DW_OP_piece,
|
|
|
|
|
# which would be a waste under the circumstances. If you have
|
|
|
|
|
# to use DWP_OP_reg, use "regx:N"...
|
|
|
|
|
}
|
|
|
|
|
sub cfa_expression {
|
|
|
|
|
my $line = shift;
|
|
|
|
|
my @ret;
|
|
|
|
|
|
|
|
|
|
foreach my $token (split(/,\s*/,$line)) {
|
|
|
|
|
if ($token =~ /^%r/) {
|
|
|
|
|
push @ret,reg($token);
|
2017-02-16 22:12:46 +00:00
|
|
|
|
} elsif ($token =~ /((?:0x)?[0-9a-f]+)\((%r\w+)\)/) {
|
|
|
|
|
push @ret,reg("$2+$1");
|
2017-02-09 19:29:16 +00:00
|
|
|
|
} elsif ($token =~ /(\w+):(\-?(?:0x)?[0-9a-f]+)(U?)/i) {
|
|
|
|
|
my $i = 1*eval($2);
|
|
|
|
|
push @ret,$DW_OP_complex{$1}, ($3 ? uleb128($i) : sleb128($i));
|
|
|
|
|
} elsif (my $i = 1*eval($token) or $token eq "0") {
|
|
|
|
|
if ($token =~ /^\+/) {
|
|
|
|
|
push @ret,$DW_OP_complex{plus_uconst},uleb128($i);
|
|
|
|
|
} else {
|
|
|
|
|
push @ret,const($i);
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
push @ret,$DW_OP_simple{$token};
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
# Finally we return DW_CFA_def_cfa_expression, 15, followed by
|
|
|
|
|
# length of the expression and of course the expression itself.
|
|
|
|
|
return (15,scalar(@ret),@ret);
|
|
|
|
|
}
|
|
|
|
|
sub re {
|
|
|
|
|
my ($class, $line) = @_;
|
|
|
|
|
my $self = {};
|
|
|
|
|
my $ret;
|
|
|
|
|
|
2017-02-16 22:12:41 +00:00
|
|
|
|
if ($$line =~ s/^\s*\.cfi_(\w+)\s*//) {
|
2017-02-09 19:29:16 +00:00
|
|
|
|
bless $self,$class;
|
|
|
|
|
$ret = $self;
|
|
|
|
|
undef $self->{value};
|
|
|
|
|
my $dir = $1;
|
|
|
|
|
|
|
|
|
|
SWITCH: for ($dir) {
|
|
|
|
|
# What is $cfa_rsp? Effectively it's difference between %rsp
|
|
|
|
|
# value and current CFA, Canonical Frame Address, which is
|
|
|
|
|
# why it starts with -8. Recall that CFA is top of caller's
|
|
|
|
|
# stack...
|
|
|
|
|
/startproc/ && do { ($cfa_reg, $cfa_rsp) = ("%rsp", -8); last; };
|
|
|
|
|
/endproc/ && do { ($cfa_reg, $cfa_rsp) = ("%rsp", 0); last; };
|
|
|
|
|
/def_cfa_register/
|
|
|
|
|
&& do { $cfa_reg = $$line; last; };
|
|
|
|
|
/def_cfa_offset/
|
|
|
|
|
&& do { $cfa_rsp = -1*eval($$line) if ($cfa_reg eq "%rsp");
|
|
|
|
|
last;
|
|
|
|
|
};
|
|
|
|
|
/adjust_cfa_offset/
|
|
|
|
|
&& do { $cfa_rsp -= 1*eval($$line) if ($cfa_reg eq "%rsp");
|
|
|
|
|
last;
|
|
|
|
|
};
|
2017-02-16 22:12:41 +00:00
|
|
|
|
/def_cfa/ && do { if ($$line =~ /(%r\w+)\s*,\s*(.+)/) {
|
2017-02-09 19:29:16 +00:00
|
|
|
|
$cfa_reg = $1;
|
|
|
|
|
$cfa_rsp = -1*eval($2) if ($cfa_reg eq "%rsp");
|
|
|
|
|
}
|
|
|
|
|
last;
|
|
|
|
|
};
|
|
|
|
|
/push/ && do { $dir = undef;
|
|
|
|
|
$cfa_rsp -= 8;
|
|
|
|
|
if ($cfa_reg eq "%rsp") {
|
|
|
|
|
$self->{value} = ".cfi_adjust_cfa_offset\t8\n";
|
|
|
|
|
}
|
|
|
|
|
$self->{value} .= ".cfi_offset\t$$line,$cfa_rsp";
|
|
|
|
|
last;
|
|
|
|
|
};
|
|
|
|
|
/pop/ && do { $dir = undef;
|
|
|
|
|
$cfa_rsp += 8;
|
|
|
|
|
if ($cfa_reg eq "%rsp") {
|
|
|
|
|
$self->{value} = ".cfi_adjust_cfa_offset\t-8\n";
|
|
|
|
|
}
|
|
|
|
|
$self->{value} .= ".cfi_restore\t$$line";
|
|
|
|
|
last;
|
|
|
|
|
};
|
|
|
|
|
/cfa_expression/
|
|
|
|
|
&& do { $dir = undef;
|
|
|
|
|
$self->{value} = ".cfi_escape\t" .
|
|
|
|
|
join(",", map(sprintf("0x%02x", $_),
|
|
|
|
|
cfa_expression($$line)));
|
|
|
|
|
last;
|
|
|
|
|
};
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$self->{value} = ".cfi_$dir\t$$line" if ($dir);
|
|
|
|
|
|
|
|
|
|
$$line = "";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return $ret;
|
|
|
|
|
}
|
|
|
|
|
sub out {
|
|
|
|
|
my $self = shift;
|
|
|
|
|
return ($elf ? $self->{value} : undef);
|
|
|
|
|
}
|
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
{ package directive; # pick up directives, which start with .
|
|
|
|
|
sub re {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my ($class, $line) = @_;
|
|
|
|
|
my $self = {};
|
|
|
|
|
my $ret;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
my $dir;
|
|
|
|
|
|
2017-02-09 19:29:16 +00:00
|
|
|
|
# chain-call to cfi_directive
|
|
|
|
|
$ret = cfi_directive->re($line) and return $ret;
|
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
if ($$line =~ /^\s*(\.\w+)/) {
|
|
|
|
|
bless $self,$class;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$dir = $1;
|
|
|
|
|
$ret = $self;
|
|
|
|
|
undef $self->{value};
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$$line = substr($$line,@+[0]); $$line =~ s/^\s+//;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
SWITCH: for ($dir) {
|
|
|
|
|
/\.global|\.globl|\.extern/
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
&& do { $globals{$$line} = $prefix . $$line;
|
|
|
|
|
$$line = $globals{$$line} if ($prefix);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
last;
|
|
|
|
|
};
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
/\.type/ && do { my ($sym,$type,$narg) = split(',',$$line);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
if ($type eq "\@function") {
|
|
|
|
|
undef $current_function;
|
|
|
|
|
$current_function->{name} = $sym;
|
|
|
|
|
$current_function->{abi} = "svr4";
|
|
|
|
|
$current_function->{narg} = $narg;
|
|
|
|
|
$current_function->{scope} = defined($globals{$sym})?"PUBLIC":"PRIVATE";
|
|
|
|
|
} elsif ($type eq "\@abi-omnipotent") {
|
|
|
|
|
undef $current_function;
|
|
|
|
|
$current_function->{name} = $sym;
|
|
|
|
|
$current_function->{scope} = defined($globals{$sym})?"PUBLIC":"PRIVATE";
|
|
|
|
|
}
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$$line =~ s/\@abi\-omnipotent/\@function/;
|
|
|
|
|
$$line =~ s/\@function.*/\@function/;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
last;
|
|
|
|
|
};
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
/\.asciz/ && do { if ($$line =~ /^"(.*)"$/) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$dir = ".byte";
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$$line = join(",",unpack("C*",$1),0);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
last;
|
|
|
|
|
};
|
|
|
|
|
/\.rva|\.long|\.quad/
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
&& do { $$line =~ s/([_a-z][_a-z0-9]*)/$globals{$1} or $1/gei;
|
|
|
|
|
$$line =~ s/\.L/$decor/g;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
last;
|
|
|
|
|
};
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ($gas) {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$self->{value} = $dir . "\t" . $$line;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
if ($dir =~ /\.extern/) {
|
2017-10-30 20:13:04 +00:00
|
|
|
|
if ($flavour eq "elf") {
|
|
|
|
|
$self->{value} .= "\n.hidden $$line";
|
|
|
|
|
} else {
|
|
|
|
|
$self->{value} = "";
|
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
} elsif (!$elf && $dir =~ /\.type/) {
|
|
|
|
|
$self->{value} = "";
|
|
|
|
|
$self->{value} = ".def\t" . ($globals{$1} or $1) . ";\t" .
|
|
|
|
|
(defined($globals{$1})?".scl 2;":".scl 3;") .
|
|
|
|
|
"\t.type 32;\t.endef"
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
if ($win64 && $$line =~ /([^,]+),\@function/);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
} elsif (!$elf && $dir =~ /\.size/) {
|
|
|
|
|
$self->{value} = "";
|
|
|
|
|
if (defined($current_function)) {
|
|
|
|
|
$self->{value} .= "${decor}SEH_end_$current_function->{name}:"
|
|
|
|
|
if ($win64 && $current_function->{abi} eq "svr4");
|
|
|
|
|
undef $current_function;
|
|
|
|
|
}
|
|
|
|
|
} elsif (!$elf && $dir =~ /\.align/) {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$self->{value} = ".p2align\t" . (log($$line)/log(2));
|
2014-06-20 20:00:00 +01:00
|
|
|
|
} elsif ($dir eq ".section") {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$current_segment=$$line;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
if (!$elf && $current_segment eq ".init") {
|
|
|
|
|
if ($flavour eq "macosx") { $self->{value} = ".mod_init_func"; }
|
|
|
|
|
elsif ($flavour eq "mingw64") { $self->{value} = ".section\t.ctors"; }
|
|
|
|
|
}
|
|
|
|
|
} elsif ($dir =~ /\.(text|data)/) {
|
|
|
|
|
$current_segment=".$1";
|
2014-07-31 00:02:14 +01:00
|
|
|
|
} elsif ($dir =~ /\.global|\.globl|\.extern/) {
|
|
|
|
|
if ($flavour eq "macosx") {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$self->{value} .= "\n.private_extern $$line";
|
2014-07-31 00:02:14 +01:00
|
|
|
|
} else {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$self->{value} .= "\n.hidden $$line";
|
2014-07-31 00:02:14 +01:00
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
} elsif ($dir =~ /\.hidden/) {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
if ($flavour eq "macosx") { $self->{value} = ".private_extern\t$prefix$$line"; }
|
2014-06-20 20:00:00 +01:00
|
|
|
|
elsif ($flavour eq "mingw64") { $self->{value} = ""; }
|
|
|
|
|
} elsif ($dir =~ /\.comm/) {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$self->{value} = "$dir\t$prefix$$line";
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$self->{value} =~ s|,([0-9]+),([0-9]+)$|",$1,".log($2)/log(2)|e if ($flavour eq "macosx");
|
|
|
|
|
}
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$$line = "";
|
2014-06-20 20:00:00 +01:00
|
|
|
|
return $self;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
# non-gas case or nasm/masm
|
|
|
|
|
SWITCH: for ($dir) {
|
|
|
|
|
/\.text/ && do { my $v=undef;
|
|
|
|
|
if ($nasm) {
|
|
|
|
|
$v="section .text code align=64\n";
|
|
|
|
|
} else {
|
|
|
|
|
$v="$current_segment\tENDS\n" if ($current_segment);
|
|
|
|
|
$current_segment = ".text\$";
|
|
|
|
|
$v.="$current_segment\tSEGMENT ";
|
2014-07-25 02:10:23 +01:00
|
|
|
|
$v.=$masm>=$masmref ? "ALIGN(256)" : "PAGE";
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$v.=" 'CODE'";
|
|
|
|
|
}
|
|
|
|
|
$self->{value} = $v;
|
|
|
|
|
last;
|
|
|
|
|
};
|
|
|
|
|
/\.data/ && do { my $v=undef;
|
|
|
|
|
if ($nasm) {
|
|
|
|
|
$v="section .data data align=8\n";
|
|
|
|
|
} else {
|
|
|
|
|
$v="$current_segment\tENDS\n" if ($current_segment);
|
|
|
|
|
$current_segment = "_DATA";
|
|
|
|
|
$v.="$current_segment\tSEGMENT";
|
|
|
|
|
}
|
|
|
|
|
$self->{value} = $v;
|
|
|
|
|
last;
|
|
|
|
|
};
|
|
|
|
|
/\.section/ && do { my $v=undef;
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$$line =~ s/([^,]*).*/$1/;
|
|
|
|
|
$$line = ".CRT\$XCU" if ($$line eq ".init");
|
2014-06-20 20:00:00 +01:00
|
|
|
|
if ($nasm) {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$v="section $$line";
|
|
|
|
|
if ($$line=~/\.([px])data/) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$v.=" rdata align=";
|
|
|
|
|
$v.=$1 eq "p"? 4 : 8;
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
} elsif ($$line=~/\.CRT\$/i) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$v.=" rdata align=8";
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
$v="$current_segment\tENDS\n" if ($current_segment);
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$v.="$$line\tSEGMENT";
|
|
|
|
|
if ($$line=~/\.([px])data/) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$v.=" READONLY";
|
|
|
|
|
$v.=" ALIGN(".($1 eq "p" ? 4 : 8).")" if ($masm>=$masmref);
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
} elsif ($$line=~/\.CRT\$/i) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$v.=" READONLY ";
|
|
|
|
|
$v.=$masm>=$masmref ? "ALIGN(8)" : "DWORD";
|
|
|
|
|
}
|
|
|
|
|
}
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$current_segment = $$line;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$self->{value} = $v;
|
|
|
|
|
last;
|
|
|
|
|
};
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
/\.extern/ && do { $self->{value} = "EXTERN\t".$$line;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
$self->{value} .= ":NEAR" if ($masm);
|
|
|
|
|
last;
|
|
|
|
|
};
|
|
|
|
|
/\.globl|.global/
|
|
|
|
|
&& do { $self->{value} = $masm?"PUBLIC":"global";
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$self->{value} .= "\t".$$line;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
last;
|
|
|
|
|
};
|
|
|
|
|
/\.size/ && do { if (defined($current_function)) {
|
|
|
|
|
undef $self->{value};
|
|
|
|
|
if ($current_function->{abi} eq "svr4") {
|
|
|
|
|
$self->{value}="${decor}SEH_end_$current_function->{name}:";
|
|
|
|
|
$self->{value}.=":\n" if($masm);
|
|
|
|
|
}
|
|
|
|
|
$self->{value}.="$current_function->{name}\tENDP" if($masm && $current_function->{name});
|
|
|
|
|
undef $current_function;
|
|
|
|
|
}
|
|
|
|
|
last;
|
|
|
|
|
};
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
/\.align/ && do { my $max = ($masm && $masm>=$masmref) ? 256 : 4096;
|
|
|
|
|
$self->{value} = "ALIGN\t".($$line>$max?$max:$$line);
|
|
|
|
|
last;
|
|
|
|
|
};
|
2014-06-20 20:00:00 +01:00
|
|
|
|
/\.(value|long|rva|quad)/
|
|
|
|
|
&& do { my $sz = substr($1,0,1);
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my @arr = split(/,\s*/,$$line);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
my $last = pop(@arr);
|
|
|
|
|
my $conv = sub { my $var=shift;
|
|
|
|
|
$var=~s/^(0b[0-1]+)/oct($1)/eig;
|
|
|
|
|
$var=~s/^0x([0-9a-f]+)/0$1h/ig if ($masm);
|
|
|
|
|
if ($sz eq "D" && ($current_segment=~/.[px]data/ || $dir eq ".rva"))
|
|
|
|
|
{ $var=~s/([_a-z\$\@][_a-z0-9\$\@]*)/$nasm?"$1 wrt ..imagebase":"imagerel $1"/egi; }
|
|
|
|
|
$var;
|
2017-02-09 19:38:21 +00:00
|
|
|
|
};
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
$sz =~ tr/bvlrq/BWDDQ/;
|
|
|
|
|
$self->{value} = "\tD$sz\t";
|
|
|
|
|
for (@arr) { $self->{value} .= &$conv($_).","; }
|
|
|
|
|
$self->{value} .= &$conv($last);
|
|
|
|
|
last;
|
|
|
|
|
};
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
/\.byte/ && do { my @str=split(/,\s*/,$$line);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
map(s/(0b[0-1]+)/oct($1)/eig,@str);
|
2017-02-09 19:38:21 +00:00
|
|
|
|
map(s/0x([0-9a-f]+)/0$1h/ig,@str) if ($masm);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
while ($#str>15) {
|
|
|
|
|
$self->{value}.="DB\t"
|
|
|
|
|
.join(",",@str[0..15])."\n";
|
|
|
|
|
foreach (0..15) { shift @str; }
|
|
|
|
|
}
|
|
|
|
|
$self->{value}.="DB\t"
|
|
|
|
|
.join(",",@str) if (@str);
|
|
|
|
|
last;
|
|
|
|
|
};
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
/\.comm/ && do { my @str=split(/,\s*/,$$line);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
my $v=undef;
|
|
|
|
|
if ($nasm) {
|
|
|
|
|
$v.="common $prefix@str[0] @str[1]";
|
|
|
|
|
} else {
|
|
|
|
|
$v="$current_segment\tENDS\n" if ($current_segment);
|
|
|
|
|
$current_segment = "_DATA";
|
|
|
|
|
$v.="$current_segment\tSEGMENT\n";
|
|
|
|
|
$v.="COMM @str[0]:DWORD:".@str[1]/4;
|
|
|
|
|
}
|
|
|
|
|
$self->{value} = $v;
|
|
|
|
|
last;
|
|
|
|
|
};
|
|
|
|
|
}
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$$line = "";
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$ret;
|
|
|
|
|
}
|
|
|
|
|
sub out {
|
|
|
|
|
my $self = shift;
|
|
|
|
|
$self->{value};
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
# Upon initial x86_64 introduction SSE>2 extensions were not introduced
|
|
|
|
|
# yet. In order not to be bothered by tracing exact assembler versions,
|
|
|
|
|
# but at the same time to provide a bare security minimum of AES-NI, we
|
|
|
|
|
# hard-code some instructions. Extensions past AES-NI on the other hand
|
|
|
|
|
# are traced by examining assembler version in individual perlasm
|
|
|
|
|
# modules...
|
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
|
my %regrm = ( "%eax"=>0, "%ecx"=>1, "%edx"=>2, "%ebx"=>3,
|
|
|
|
|
"%esp"=>4, "%ebp"=>5, "%esi"=>6, "%edi"=>7 );
|
|
|
|
|
|
2017-02-09 19:27:11 +00:00
|
|
|
|
sub rex {
|
|
|
|
|
my $opcode=shift;
|
|
|
|
|
my ($dst,$src,$rex)=@_;
|
|
|
|
|
|
|
|
|
|
$rex|=0x04 if($dst>=8);
|
|
|
|
|
$rex|=0x01 if($src>=8);
|
|
|
|
|
push @$opcode,($rex|0x40) if ($rex);
|
|
|
|
|
}
|
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
|
my $movq = sub { # elderly gas can't handle inter-register movq
|
|
|
|
|
my $arg = shift;
|
|
|
|
|
my @opcode=(0x66);
|
|
|
|
|
if ($arg =~ /%xmm([0-9]+),\s*%r(\w+)/) {
|
|
|
|
|
my ($src,$dst)=($1,$2);
|
|
|
|
|
if ($dst !~ /[0-9]+/) { $dst = $regrm{"%e$dst"}; }
|
|
|
|
|
rex(\@opcode,$src,$dst,0x8);
|
|
|
|
|
push @opcode,0x0f,0x7e;
|
|
|
|
|
push @opcode,0xc0|(($src&7)<<3)|($dst&7); # ModR/M
|
|
|
|
|
@opcode;
|
|
|
|
|
} elsif ($arg =~ /%r(\w+),\s*%xmm([0-9]+)/) {
|
|
|
|
|
my ($src,$dst)=($2,$1);
|
|
|
|
|
if ($dst !~ /[0-9]+/) { $dst = $regrm{"%e$dst"}; }
|
|
|
|
|
rex(\@opcode,$src,$dst,0x8);
|
|
|
|
|
push @opcode,0x0f,0x6e;
|
|
|
|
|
push @opcode,0xc0|(($src&7)<<3)|($dst&7); # ModR/M
|
|
|
|
|
@opcode;
|
|
|
|
|
} else {
|
|
|
|
|
();
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
my $pextrd = sub {
|
|
|
|
|
if (shift =~ /\$([0-9]+),\s*%xmm([0-9]+),\s*(%\w+)/) {
|
|
|
|
|
my @opcode=(0x66);
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my $imm=$1;
|
|
|
|
|
my $src=$2;
|
|
|
|
|
my $dst=$3;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
if ($dst =~ /%r([0-9]+)d/) { $dst = $1; }
|
|
|
|
|
elsif ($dst =~ /%e/) { $dst = $regrm{$dst}; }
|
|
|
|
|
rex(\@opcode,$src,$dst);
|
|
|
|
|
push @opcode,0x0f,0x3a,0x16;
|
|
|
|
|
push @opcode,0xc0|(($src&7)<<3)|($dst&7); # ModR/M
|
|
|
|
|
push @opcode,$imm;
|
|
|
|
|
@opcode;
|
|
|
|
|
} else {
|
|
|
|
|
();
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
my $pinsrd = sub {
|
|
|
|
|
if (shift =~ /\$([0-9]+),\s*(%\w+),\s*%xmm([0-9]+)/) {
|
|
|
|
|
my @opcode=(0x66);
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my $imm=$1;
|
|
|
|
|
my $src=$2;
|
|
|
|
|
my $dst=$3;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
if ($src =~ /%r([0-9]+)/) { $src = $1; }
|
|
|
|
|
elsif ($src =~ /%e/) { $src = $regrm{$src}; }
|
|
|
|
|
rex(\@opcode,$dst,$src);
|
|
|
|
|
push @opcode,0x0f,0x3a,0x22;
|
|
|
|
|
push @opcode,0xc0|(($dst&7)<<3)|($src&7); # ModR/M
|
|
|
|
|
push @opcode,$imm;
|
|
|
|
|
@opcode;
|
|
|
|
|
} else {
|
|
|
|
|
();
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
my $pshufb = sub {
|
|
|
|
|
if (shift =~ /%xmm([0-9]+),\s*%xmm([0-9]+)/) {
|
|
|
|
|
my @opcode=(0x66);
|
|
|
|
|
rex(\@opcode,$2,$1);
|
|
|
|
|
push @opcode,0x0f,0x38,0x00;
|
|
|
|
|
push @opcode,0xc0|($1&7)|(($2&7)<<3); # ModR/M
|
|
|
|
|
@opcode;
|
|
|
|
|
} else {
|
|
|
|
|
();
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
my $palignr = sub {
|
|
|
|
|
if (shift =~ /\$([0-9]+),\s*%xmm([0-9]+),\s*%xmm([0-9]+)/) {
|
|
|
|
|
my @opcode=(0x66);
|
|
|
|
|
rex(\@opcode,$3,$2);
|
|
|
|
|
push @opcode,0x0f,0x3a,0x0f;
|
|
|
|
|
push @opcode,0xc0|($2&7)|(($3&7)<<3); # ModR/M
|
|
|
|
|
push @opcode,$1;
|
|
|
|
|
@opcode;
|
|
|
|
|
} else {
|
|
|
|
|
();
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
my $pclmulqdq = sub {
|
|
|
|
|
if (shift =~ /\$([x0-9a-f]+),\s*%xmm([0-9]+),\s*%xmm([0-9]+)/) {
|
|
|
|
|
my @opcode=(0x66);
|
|
|
|
|
rex(\@opcode,$3,$2);
|
|
|
|
|
push @opcode,0x0f,0x3a,0x44;
|
|
|
|
|
push @opcode,0xc0|($2&7)|(($3&7)<<3); # ModR/M
|
|
|
|
|
my $c=$1;
|
|
|
|
|
push @opcode,$c=~/^0/?oct($c):$c;
|
|
|
|
|
@opcode;
|
|
|
|
|
} else {
|
|
|
|
|
();
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
my $rdrand = sub {
|
|
|
|
|
if (shift =~ /%[er](\w+)/) {
|
|
|
|
|
my @opcode=();
|
|
|
|
|
my $dst=$1;
|
|
|
|
|
if ($dst !~ /[0-9]+/) { $dst = $regrm{"%e$dst"}; }
|
2017-02-09 19:44:06 +00:00
|
|
|
|
rex(\@opcode,0,$dst,8);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
push @opcode,0x0f,0xc7,0xf0|($dst&7);
|
|
|
|
|
@opcode;
|
|
|
|
|
} else {
|
|
|
|
|
();
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
2014-07-25 02:10:23 +01:00
|
|
|
|
my $rdseed = sub {
|
|
|
|
|
if (shift =~ /%[er](\w+)/) {
|
|
|
|
|
my @opcode=();
|
|
|
|
|
my $dst=$1;
|
|
|
|
|
if ($dst !~ /[0-9]+/) { $dst = $regrm{"%e$dst"}; }
|
2017-02-09 19:44:06 +00:00
|
|
|
|
rex(\@opcode,0,$dst,8);
|
2014-07-25 02:10:23 +01:00
|
|
|
|
push @opcode,0x0f,0xc7,0xf8|($dst&7);
|
|
|
|
|
@opcode;
|
|
|
|
|
} else {
|
|
|
|
|
();
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
2017-02-09 19:27:11 +00:00
|
|
|
|
# Not all AVX-capable assemblers recognize AMD XOP extension. Since we
|
|
|
|
|
# are using only two instructions hand-code them in order to be excused
|
|
|
|
|
# from chasing assembler versions...
|
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
|
sub rxb {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my $opcode=shift;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
my ($dst,$src1,$src2,$rxb)=@_;
|
|
|
|
|
|
|
|
|
|
$rxb|=0x7<<5;
|
|
|
|
|
$rxb&=~(0x04<<5) if($dst>=8);
|
|
|
|
|
$rxb&=~(0x01<<5) if($src1>=8);
|
|
|
|
|
$rxb&=~(0x02<<5) if($src2>=8);
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
push @$opcode,$rxb;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
my $vprotd = sub {
|
|
|
|
|
if (shift =~ /\$([x0-9a-f]+),\s*%xmm([0-9]+),\s*%xmm([0-9]+)/) {
|
|
|
|
|
my @opcode=(0x8f);
|
|
|
|
|
rxb(\@opcode,$3,$2,-1,0x08);
|
|
|
|
|
push @opcode,0x78,0xc2;
|
|
|
|
|
push @opcode,0xc0|($2&7)|(($3&7)<<3); # ModR/M
|
|
|
|
|
my $c=$1;
|
|
|
|
|
push @opcode,$c=~/^0/?oct($c):$c;
|
|
|
|
|
@opcode;
|
|
|
|
|
} else {
|
|
|
|
|
();
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
my $vprotq = sub {
|
|
|
|
|
if (shift =~ /\$([x0-9a-f]+),\s*%xmm([0-9]+),\s*%xmm([0-9]+)/) {
|
|
|
|
|
my @opcode=(0x8f);
|
|
|
|
|
rxb(\@opcode,$3,$2,-1,0x08);
|
|
|
|
|
push @opcode,0x78,0xc3;
|
|
|
|
|
push @opcode,0xc0|($2&7)|(($3&7)<<3); # ModR/M
|
|
|
|
|
my $c=$1;
|
|
|
|
|
push @opcode,$c=~/^0/?oct($c):$c;
|
|
|
|
|
@opcode;
|
|
|
|
|
} else {
|
|
|
|
|
();
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
2017-02-09 19:27:11 +00:00
|
|
|
|
# Intel Control-flow Enforcement Technology extension. All functions and
|
|
|
|
|
# indirect branch targets will have to start with this instruction...
|
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my $endbranch = sub {
|
|
|
|
|
(0xf3,0x0f,0x1e,0xfa);
|
|
|
|
|
};
|
|
|
|
|
|
2017-02-09 19:27:11 +00:00
|
|
|
|
########################################################################
|
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
|
if ($nasm) {
|
|
|
|
|
print <<___;
|
|
|
|
|
default rel
|
|
|
|
|
%define XMMWORD
|
2014-07-25 02:10:23 +01:00
|
|
|
|
%define YMMWORD
|
|
|
|
|
%define ZMMWORD
|
2014-06-20 20:00:00 +01:00
|
|
|
|
___
|
|
|
|
|
} elsif ($masm) {
|
|
|
|
|
print <<___;
|
|
|
|
|
OPTION DOTNAME
|
|
|
|
|
___
|
|
|
|
|
}
|
2017-03-30 17:51:09 +01:00
|
|
|
|
print STDOUT "#if defined(__x86_64__) && !defined(OPENSSL_NO_ASM)\n" if ($gas);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
while(defined(my $line=<>)) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$line =~ s|\R$||; # Better chomp
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
$line =~ s|[#!].*$||; # get rid of asm-style comments...
|
|
|
|
|
$line =~ s|/\*.*\*/||; # ... and C-style comments...
|
|
|
|
|
$line =~ s|^\s+||; # ... and skip white spaces in beginning
|
|
|
|
|
$line =~ s|\s+$||; # ... and at the end
|
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
if (my $label=label->re(\$line)) { print $label->out(); }
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
if (my $directive=directive->re(\$line)) {
|
|
|
|
|
printf "%s",$directive->out();
|
|
|
|
|
} elsif (my $opcode=opcode->re(\$line)) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
my $asm = eval("\$".$opcode->mnemonic());
|
2017-02-09 19:38:21 +00:00
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
if ((ref($asm) eq 'CODE') && scalar(my @bytes=&$asm($line))) {
|
2014-06-20 20:00:00 +01:00
|
|
|
|
print $gas?".byte\t":"DB\t",join(',',@bytes),"\n";
|
|
|
|
|
next;
|
|
|
|
|
}
|
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my @args;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
ARGUMENT: while (1) {
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my $arg;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
($arg=register->re(\$line, $opcode))||
|
|
|
|
|
($arg=const->re(\$line)) ||
|
|
|
|
|
($arg=ea->re(\$line, $opcode)) ||
|
|
|
|
|
($arg=expr->re(\$line, $opcode)) ||
|
|
|
|
|
last ARGUMENT;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
push @args,$arg;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
last ARGUMENT if ($line !~ /^,/);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
$line =~ s/^,\s*//;
|
2014-06-20 20:00:00 +01:00
|
|
|
|
} # ARGUMENT:
|
|
|
|
|
|
|
|
|
|
if ($#args>=0) {
|
|
|
|
|
my $insn;
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
my $sz=$opcode->size();
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
if ($gas) {
|
|
|
|
|
$insn = $opcode->out($#args>=1?$args[$#args]->size():$sz);
|
|
|
|
|
@args = map($_->out($sz),@args);
|
|
|
|
|
printf "\t%s\t%s",$insn,join(",",@args);
|
|
|
|
|
} else {
|
|
|
|
|
$insn = $opcode->out();
|
|
|
|
|
foreach (@args) {
|
|
|
|
|
my $arg = $_->out();
|
|
|
|
|
# $insn.=$sz compensates for movq, pinsrw, ...
|
|
|
|
|
if ($arg =~ /^xmm[0-9]+$/) { $insn.=$sz; $sz="x" if(!$sz); last; }
|
|
|
|
|
if ($arg =~ /^ymm[0-9]+$/) { $insn.=$sz; $sz="y" if(!$sz); last; }
|
2014-07-25 02:10:23 +01:00
|
|
|
|
if ($arg =~ /^zmm[0-9]+$/) { $insn.=$sz; $sz="z" if(!$sz); last; }
|
2014-06-20 20:00:00 +01:00
|
|
|
|
if ($arg =~ /^mm[0-9]+$/) { $insn.=$sz; $sz="q" if(!$sz); last; }
|
|
|
|
|
}
|
|
|
|
|
@args = reverse(@args);
|
|
|
|
|
undef $sz if ($nasm && $opcode->mnemonic() eq "lea");
|
2017-05-05 23:06:19 +01:00
|
|
|
|
printf "\t%s\t%s",$insn,join(",",map($_->out($sz),@args));
|
2014-06-20 20:00:00 +01:00
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
printf "\t%s",$opcode->out();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
print $line,"\n";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
print "\n$current_segment\tENDS\n" if ($current_segment && $masm);
|
|
|
|
|
print "END\n" if ($masm);
|
2014-09-10 22:55:56 +01:00
|
|
|
|
print "#endif\n" if ($gas);
|
2014-06-20 20:00:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
close STDOUT;
|
|
|
|
|
|
|
|
|
|
#################################################
|
|
|
|
|
# Cross-reference x86_64 ABI "card"
|
|
|
|
|
#
|
|
|
|
|
# Unix Win64
|
|
|
|
|
# %rax * *
|
|
|
|
|
# %rbx - -
|
|
|
|
|
# %rcx #4 #1
|
|
|
|
|
# %rdx #3 #2
|
|
|
|
|
# %rsi #2 -
|
|
|
|
|
# %rdi #1 -
|
|
|
|
|
# %rbp - -
|
|
|
|
|
# %rsp - -
|
|
|
|
|
# %r8 #5 #3
|
|
|
|
|
# %r9 #6 #4
|
|
|
|
|
# %r10 * *
|
|
|
|
|
# %r11 * *
|
|
|
|
|
# %r12 - -
|
|
|
|
|
# %r13 - -
|
|
|
|
|
# %r14 - -
|
|
|
|
|
# %r15 - -
|
2017-02-09 19:38:21 +00:00
|
|
|
|
#
|
2014-06-20 20:00:00 +01:00
|
|
|
|
# (*) volatile register
|
|
|
|
|
# (-) preserved by callee
|
|
|
|
|
# (#) Nth argument, volatile
|
|
|
|
|
#
|
|
|
|
|
# In Unix terms top of stack is argument transfer area for arguments
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
# which could not be accommodated in registers. Or in other words 7th
|
2014-06-20 20:00:00 +01:00
|
|
|
|
# [integer] argument resides at 8(%rsp) upon function entry point.
|
|
|
|
|
# 128 bytes above %rsp constitute a "red zone" which is not touched
|
|
|
|
|
# by signal handlers and can be used as temporal storage without
|
|
|
|
|
# allocating a frame.
|
|
|
|
|
#
|
|
|
|
|
# In Win64 terms N*8 bytes on top of stack is argument transfer area,
|
|
|
|
|
# which belongs to/can be overwritten by callee. N is the number of
|
|
|
|
|
# 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]. 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
|
2017-02-16 17:47:01 +00:00
|
|
|
|
# register and stack layout, but disregards the "red zone" existence,
|
2014-06-20 20:00:00 +01:00
|
|
|
|
# it's possible to use following prologue and epilogue to "gear" from
|
|
|
|
|
# Unix to Win64 ABI in leaf functions with not more than 6 arguments.
|
|
|
|
|
#
|
|
|
|
|
# omnipotent_function:
|
|
|
|
|
# ifdef WIN64
|
|
|
|
|
# movq %rdi,8(%rsp)
|
|
|
|
|
# movq %rsi,16(%rsp)
|
|
|
|
|
# movq %rcx,%rdi ; if 1st argument is actually present
|
|
|
|
|
# movq %rdx,%rsi ; if 2nd argument is actually ...
|
|
|
|
|
# movq %r8,%rdx ; if 3rd argument is ...
|
|
|
|
|
# movq %r9,%rcx ; if 4th argument ...
|
|
|
|
|
# movq 40(%rsp),%r8 ; if 5th ...
|
|
|
|
|
# movq 48(%rsp),%r9 ; if 6th ...
|
|
|
|
|
# endif
|
|
|
|
|
# ...
|
|
|
|
|
# ifdef WIN64
|
|
|
|
|
# movq 8(%rsp),%rdi
|
|
|
|
|
# movq 16(%rsp),%rsi
|
|
|
|
|
# endif
|
|
|
|
|
# ret
|
|
|
|
|
#
|
|
|
|
|
#################################################
|
|
|
|
|
# Win64 SEH, Structured Exception Handling.
|
|
|
|
|
#
|
|
|
|
|
# Unlike on Unix systems(*) lack of Win64 stack unwinding information
|
|
|
|
|
# has undesired side-effect at run-time: if an exception is raised in
|
|
|
|
|
# assembler subroutine such as those in question (basically we're
|
|
|
|
|
# referring to segmentation violations caused by malformed input
|
|
|
|
|
# parameters), the application is briskly terminated without invoking
|
|
|
|
|
# any exception handlers, most notably without generating memory dump
|
|
|
|
|
# or any user notification whatsoever. This poses a problem. It's
|
|
|
|
|
# possible to address it by registering custom language-specific
|
|
|
|
|
# handler that would restore processor context to the state at
|
|
|
|
|
# subroutine entry point and return "exception is not handled, keep
|
|
|
|
|
# unwinding" code. Writing such handler can be a challenge... But it's
|
|
|
|
|
# doable, though requires certain coding convention. Consider following
|
|
|
|
|
# snippet:
|
|
|
|
|
#
|
|
|
|
|
# .type function,@function
|
|
|
|
|
# function:
|
|
|
|
|
# movq %rsp,%rax # copy rsp to volatile register
|
|
|
|
|
# pushq %r15 # save non-volatile registers
|
|
|
|
|
# pushq %rbx
|
|
|
|
|
# pushq %rbp
|
|
|
|
|
# movq %rsp,%r11
|
|
|
|
|
# subq %rdi,%r11 # prepare [variable] stack frame
|
|
|
|
|
# andq $-64,%r11
|
|
|
|
|
# movq %rax,0(%r11) # check for exceptions
|
|
|
|
|
# movq %r11,%rsp # allocate [variable] stack frame
|
|
|
|
|
# movq %rax,0(%rsp) # save original rsp value
|
|
|
|
|
# magic_point:
|
|
|
|
|
# ...
|
|
|
|
|
# movq 0(%rsp),%rcx # pull original rsp value
|
|
|
|
|
# movq -24(%rcx),%rbp # restore non-volatile registers
|
|
|
|
|
# movq -16(%rcx),%rbx
|
|
|
|
|
# movq -8(%rcx),%r15
|
|
|
|
|
# movq %rcx,%rsp # restore original rsp
|
2017-02-09 19:20:50 +00:00
|
|
|
|
# magic_epilogue:
|
2014-06-20 20:00:00 +01:00
|
|
|
|
# ret
|
|
|
|
|
# .size function,.-function
|
|
|
|
|
#
|
|
|
|
|
# The key is that up to magic_point copy of original rsp value remains
|
|
|
|
|
# in chosen volatile register and no non-volatile register, except for
|
|
|
|
|
# rsp, is modified. While past magic_point rsp remains constant till
|
|
|
|
|
# the very end of the function. In this case custom language-specific
|
|
|
|
|
# exception handler would look like this:
|
|
|
|
|
#
|
|
|
|
|
# EXCEPTION_DISPOSITION handler (EXCEPTION_RECORD *rec,ULONG64 frame,
|
|
|
|
|
# CONTEXT *context,DISPATCHER_CONTEXT *disp)
|
|
|
|
|
# { ULONG64 *rsp = (ULONG64 *)context->Rax;
|
2017-02-09 19:20:50 +00:00
|
|
|
|
# ULONG64 rip = context->Rip;
|
|
|
|
|
#
|
|
|
|
|
# if (rip >= magic_point)
|
|
|
|
|
# { rsp = (ULONG64 *)context->Rsp;
|
|
|
|
|
# if (rip < magic_epilogue)
|
|
|
|
|
# { rsp = (ULONG64 *)rsp[0];
|
|
|
|
|
# context->Rbp = rsp[-3];
|
|
|
|
|
# context->Rbx = rsp[-2];
|
|
|
|
|
# context->R15 = rsp[-1];
|
|
|
|
|
# }
|
2014-06-20 20:00:00 +01:00
|
|
|
|
# }
|
|
|
|
|
# context->Rsp = (ULONG64)rsp;
|
|
|
|
|
# context->Rdi = rsp[1];
|
|
|
|
|
# context->Rsi = rsp[2];
|
|
|
|
|
#
|
|
|
|
|
# memcpy (disp->ContextRecord,context,sizeof(CONTEXT));
|
|
|
|
|
# RtlVirtualUnwind(UNW_FLAG_NHANDLER,disp->ImageBase,
|
|
|
|
|
# dips->ControlPc,disp->FunctionEntry,disp->ContextRecord,
|
|
|
|
|
# &disp->HandlerData,&disp->EstablisherFrame,NULL);
|
|
|
|
|
# return ExceptionContinueSearch;
|
|
|
|
|
# }
|
|
|
|
|
#
|
|
|
|
|
# It's appropriate to implement this handler in assembler, directly in
|
|
|
|
|
# function's module. In order to do that one has to know members'
|
|
|
|
|
# offsets in CONTEXT and DISPATCHER_CONTEXT structures and some constant
|
|
|
|
|
# values. Here they are:
|
|
|
|
|
#
|
|
|
|
|
# CONTEXT.Rax 120
|
|
|
|
|
# CONTEXT.Rcx 128
|
|
|
|
|
# CONTEXT.Rdx 136
|
|
|
|
|
# CONTEXT.Rbx 144
|
|
|
|
|
# CONTEXT.Rsp 152
|
|
|
|
|
# CONTEXT.Rbp 160
|
|
|
|
|
# CONTEXT.Rsi 168
|
|
|
|
|
# CONTEXT.Rdi 176
|
|
|
|
|
# CONTEXT.R8 184
|
|
|
|
|
# CONTEXT.R9 192
|
|
|
|
|
# CONTEXT.R10 200
|
|
|
|
|
# CONTEXT.R11 208
|
|
|
|
|
# CONTEXT.R12 216
|
|
|
|
|
# CONTEXT.R13 224
|
|
|
|
|
# CONTEXT.R14 232
|
|
|
|
|
# CONTEXT.R15 240
|
|
|
|
|
# CONTEXT.Rip 248
|
|
|
|
|
# CONTEXT.Xmm6 512
|
|
|
|
|
# sizeof(CONTEXT) 1232
|
|
|
|
|
# DISPATCHER_CONTEXT.ControlPc 0
|
|
|
|
|
# DISPATCHER_CONTEXT.ImageBase 8
|
|
|
|
|
# DISPATCHER_CONTEXT.FunctionEntry 16
|
|
|
|
|
# DISPATCHER_CONTEXT.EstablisherFrame 24
|
|
|
|
|
# DISPATCHER_CONTEXT.TargetIp 32
|
|
|
|
|
# DISPATCHER_CONTEXT.ContextRecord 40
|
|
|
|
|
# DISPATCHER_CONTEXT.LanguageHandler 48
|
|
|
|
|
# DISPATCHER_CONTEXT.HandlerData 56
|
|
|
|
|
# UNW_FLAG_NHANDLER 0
|
|
|
|
|
# ExceptionContinueSearch 1
|
|
|
|
|
#
|
|
|
|
|
# In order to tie the handler to the function one has to compose
|
|
|
|
|
# couple of structures: one for .xdata segment and one for .pdata.
|
|
|
|
|
#
|
|
|
|
|
# UNWIND_INFO structure for .xdata segment would be
|
|
|
|
|
#
|
|
|
|
|
# function_unwind_info:
|
|
|
|
|
# .byte 9,0,0,0
|
|
|
|
|
# .rva handler
|
|
|
|
|
#
|
|
|
|
|
# This structure designates exception handler for a function with
|
|
|
|
|
# zero-length prologue, no stack frame or frame register.
|
|
|
|
|
#
|
|
|
|
|
# To facilitate composing of .pdata structures, auto-generated "gear"
|
|
|
|
|
# prologue copies rsp value to rax and denotes next instruction with
|
|
|
|
|
# .LSEH_begin_{function_name} label. This essentially defines the SEH
|
|
|
|
|
# styling rule mentioned in the beginning. Position of this label is
|
|
|
|
|
# chosen in such manner that possible exceptions raised in the "gear"
|
|
|
|
|
# prologue would be accounted to caller and unwound from latter's frame.
|
|
|
|
|
# End of function is marked with respective .LSEH_end_{function_name}
|
|
|
|
|
# label. To summarize, .pdata segment would contain
|
|
|
|
|
#
|
|
|
|
|
# .rva .LSEH_begin_function
|
|
|
|
|
# .rva .LSEH_end_function
|
|
|
|
|
# .rva function_unwind_info
|
|
|
|
|
#
|
Rebase x86_64-xlate.pl atop master.
This functionally pulls in a number of changes from upstream, including:
4e3d2866b6e8e7a700ea22e05840a093bfd7a4b1
1eb12c437bbeb2c748291bcd23733d4a59d5d1ca
6a4ea0022c475bbc2c7ad98a6f05f6e2e850575b
c25278db8e4c21772a0cd81f7873e767cbc6d219
e0a651945cb5a70a2abd9902c0fd3e9759d35867
d405aa2ff265965c71ce7331cf0e49d634a06924
ce3d25d3e5a7e82fd59fd30dff7acc39baed8b5e
9ba96fbb2523cb12747c559c704c58bd8f9e7982
Notably, c25278db8e4c21772a0cd81f7873e767cbc6d219 makes it enable 'use strict'.
To avoid having to deal with complex conflicts, this was done by taking a diff
of our copy of the file with the point just before
c25278db8e4c21772a0cd81f7873e767cbc6d219, and reapplying the non-reverting
parts of our diff on top of upstream's current version.
Confirmed with generate_build_files.py that this makes no changes *except*
d405aa2ff265965c71ce7331cf0e49d634a06924 causes this sort of change throughout
chacha-x86_64.pl's nasm output:
@@ -1179,7 +1179,7 @@ $L$oop8x:
vpslld ymm14,ymm0,12
vpsrld ymm0,ymm0,20
vpor ymm0,ymm14,ymm0
- vbroadcasti128 ymm14,YMMWORD[r11]
+ vbroadcasti128 ymm14,XMMWORD[r11]
vpaddd ymm13,ymm13,ymm5
vpxor ymm1,ymm13,ymm1
vpslld ymm15,ymm1,12
This appears to be correct. vbroadcasti128 takes a 128-bit-wide second
argument, so it wants XMMWORD, not YMMWORD. I suppose nasm just didn't care.
(Looking at a diff-diff may be a more useful way to review this CL.)
Change-Id: I61be0d225ddf13b5f05d1369ddda84b2f322ef9d
Reviewed-on: https://boringssl-review.googlesource.com/8392
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
2016-06-20 19:28:48 +01:00
|
|
|
|
# Reference to function_unwind_info from .xdata segment is the anchor.
|
2014-06-20 20:00:00 +01:00
|
|
|
|
# In case you wonder why references are 32-bit .rvas and not 64-bit
|
|
|
|
|
# .quads. References put into these two segments are required to be
|
|
|
|
|
# *relative* to the base address of the current binary module, a.k.a.
|
|
|
|
|
# image base. No Win64 module, be it .exe or .dll, can be larger than
|
|
|
|
|
# 2GB and thus such relative references can be and are accommodated in
|
|
|
|
|
# 32 bits.
|
|
|
|
|
#
|
|
|
|
|
# Having reviewed the example function code, one can argue that "movq
|
|
|
|
|
# %rsp,%rax" above is redundant. It is not! Keep in mind that on Unix
|
|
|
|
|
# rax would contain an undefined value. If this "offends" you, use
|
|
|
|
|
# another register and refrain from modifying rax till magic_point is
|
|
|
|
|
# reached, i.e. as if it was a non-volatile register. If more registers
|
|
|
|
|
# are required prior [variable] frame setup is completed, note that
|
|
|
|
|
# nobody says that you can have only one "magic point." You can
|
|
|
|
|
# "liberate" non-volatile registers by denoting last stack off-load
|
|
|
|
|
# instruction and reflecting it in finer grade unwind logic in handler.
|
|
|
|
|
# After all, isn't it why it's called *language-specific* handler...
|
|
|
|
|
#
|
2017-02-09 19:20:50 +00:00
|
|
|
|
# SE handlers are also involved in unwinding stack when executable is
|
|
|
|
|
# profiled or debugged. Profiling implies additional limitations that
|
|
|
|
|
# are too subtle to discuss here. For now it's sufficient to say that
|
|
|
|
|
# in order to simplify handlers one should either a) offload original
|
|
|
|
|
# %rsp to stack (like discussed above); or b) if you have a register to
|
|
|
|
|
# spare for frame pointer, choose volatile one.
|
2014-06-20 20:00:00 +01:00
|
|
|
|
#
|
|
|
|
|
# (*) Note that we're talking about run-time, not debug-time. Lack of
|
|
|
|
|
# unwind information makes debugging hard on both Windows and
|
2018-02-02 20:12:22 +00:00
|
|
|
|
# Unix. "Unlike" refers to the fact that on Unix signal handler
|
2014-06-20 20:00:00 +01:00
|
|
|
|
# will always be invoked, core dumped and appropriate exit code
|
|
|
|
|
# returned to parent (for user notification).
|