This is taken from Chromium and then pared down to remove unnecessary
bits. The Windows setup is somewhat more involved due to needing to copy
some DLL from Visual Studio.
Bug: 201
Change-Id: I0658f7a20ec4fdea007821d5ce331acd3cb494b2
Reviewed-on: https://boringssl-review.googlesource.com/20504
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
This works fine, but probably worth a test.
Change-Id: If060b473958c1664e450102cafe0ca28951bff49
Reviewed-on: https://boringssl-review.googlesource.com/20444
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Newer versions of LLVM can emit this instruction. Note that there are
two different Intel instructions, both called “movsd”. The old one is an
auto-incrementing move that doesn't take any arguments. That's not the
one that is targetted in this change.
Change-Id: Id0c96e0c7fe0f6e4feb8a72b5bc0fa40878225b9
Reviewed-on: https://boringssl-review.googlesource.com/20425
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
vmovq clears the upper 128 bits of a YMM register, while movq does not.
When translating vmovq to an XMM register, we need to use vmovq in the
final move in order to keep this behaviour.
Change-Id: I81b6eee3ee6db0ea90d7c5098fc7c4ccefaf3b12
Reviewed-on: https://boringssl-review.googlesource.com/20424
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: I692424f05f543c98a994a444f0303ea0bda7c14f
Reviewed-on: https://boringssl-review.googlesource.com/19725
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
As of https://chromium-review.googlesource.com/#/c/608869/, Chromium is
now using yasm 1.3.0, which means we can rely on it.
This is upstream's yasm-1.3.0-win32.exe which has a SHA-512 hash of:
850b26be5bbbdaeaf45ac39dd27f69f1a85e600c35afbd16b9f621396b3c7a19863ea3ff316b025b578fce0a8280eef2203306a2b3e46ee1389abb65313fb720
(I'm using such a humungous hash because if one searches for it on
Google, there is evidence that someone else in the world downloaded the
same hash.)
Change-Id: I4674080dd07d3e07f399a67e767a00fc67d4aa63
Reviewed-on: https://boringssl-review.googlesource.com/19104
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
This is in preparation for changing all the comments.
Change-Id: Id7ff24331a3b9d108402238c63eeeb462c7cd809
Reviewed-on: https://boringssl-review.googlesource.com/18945
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Go 1.9 is slated to have some backwards-incompatible changes to
html/template. See https://github.com/golang/go/issues/19952.
If I'm reading this correctly, the issue is that the context-aware auto
escaper had some magic around the 'html' filter, but it would get
confused if this was used in the wrong context.
This does not apply to us because we never used it in an attribute, etc.
Nonetheless, we can be compatible with it and tidy up markupPipeWords'
type signature. It should have had type template.HTML -> template.HTML,
not string -> template.HTML, because it expects the input to be
pre-escaped. (The old 'html' escaper, in turn, probably should have had
type string -> template.HTML, but I guess it didn't because all this
existed for a text/template migration convenience of some sort?)
I considered adding our own escapeHTML with type string -> template.HTML
and fixing markupPipeWords to be template.HTML -> template.HTML, but
markupPipeWords does not correctly handle all possible template.HTML
input. If a | were in an attribute somewhere, it would mangle the text.
Instead, I kept it of type string -> template.HTML and defined it to
perform the HTML escaping itself. This seems to produce the same output
as before in Go 1.8 and tip.
Change-Id: I90618a3c5525ae54f9fe731352fcff5856b9ba60
Reviewed-on: https://boringssl-review.googlesource.com/18944
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The following code:
int closed; /* valid iff peer != NULL */
size_t len; /* valid iff buf != NULL; 0 if peer == NULL */
size_t offset; /* valid iff buf != NULL; 0 if len == 0 */
should be rewritten as:
int closed; // valid iff peer != NULL
size_t len; // valid iff buf != NULL; 0 if peer == NULL
size_t offset; // valid iff buf != NULL; 0 if len == 0
But the existing code lost the alignment when shifting the third comment
over to follow the two-space rule. Also warn about > 80 character lines
so they may be manually fixed up.
Change-Id: Idd3b4267b972c9b8891ceefd50f6d2a0e67ed51c
Reviewed-on: https://boringssl-review.googlesource.com/18784
Reviewed-by: Adam Langley <agl@google.com>
The following code was misconverted:
BIO *peer; /* NULL if buf == NULL.
* If peer != NULL, then peer->ptr is also a bio_bio_st,
* and its "peer" member points back to us.
* peer != NULL iff init != 0 in the BIO. */
Per the criteria in the comment, this comment is eligible, which is what
we want. Only continuation lines must be prefixed by spaces. But the
loop treated the first line as immediately ineligible. Moreover, in that
case, it dropped the line on the floor rather than echoing it. Fix this
by dropping that case.
Change-Id: Ic523fe1e6bc8dde37a9897e2a93e815c11feb95a
Reviewed-on: https://boringssl-review.googlesource.com/18746
Reviewed-by: Adam Langley <agl@google.com>
Code like this:
if (// Check if the cipher is supported for the current version.
SSL_CIPHER_get_min_version(c) <= ssl3_protocol_version(ssl) &&
ssl3_protocol_version(ssl) <= SSL_CIPHER_get_max_version(c) &&
// Check the cipher is supported for the server configuration.
(c->algorithm_mkey & mask_k) &&
(c->algorithm_auth & mask_a) &&
// Check the cipher is in the |allow| list.
sk_SSL_CIPHER_find(allow, &cipher_index, c)) {
should not get an extra space.
Change-Id: I772cbcfabf2481dc8e3a8b257d85573b0b5ac1b7
Reviewed-on: https://boringssl-review.googlesource.com/18745
Reviewed-by: David Benjamin <davidben@google.com>
The changes to the assembly files are synced from upstream's
64d92d74985ebb3d0be58a9718f9e080a14a8e7f. cpu-intel.c is translated to C
from that commit and d84df594404ebbd71d21fec5526178d935e4d88d.
Change-Id: I02c8f83aa4780df301c21f011ef2d8d8300e2f2a
Reviewed-on: https://boringssl-review.googlesource.com/18411
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
A follow-up change will tweak linux_shared to run this tool on
libcrypto.so and libssl.so.
Bug: 132
Change-Id: I868551cebdc308829dee3dca12a39395c4a251ee
Reviewed-on: https://boringssl-review.googlesource.com/18407
Reviewed-by: Steven Valdez <svaldez@google.com>
This is a utility to switch comments from /* C-style */ to // C++-style.
It's purely aesthetic, but it matches how most of Google C++ looks.
Running it over libssl, the script seems to get all but one or two cases
right.
We may also wish to convert the C code for consistency while we're here.
We've accidentally put both styles of comments all over the place, so
our toolchains can tolerate // in C.
Bug: 132
Change-Id: If2f4d58c0a4ad8f9a2113705435bff90e0dabcc3
Reviewed-on: https://boringssl-review.googlesource.com/18064
Reviewed-by: David Benjamin <davidben@google.com>
This will require changes in downstream builds, but hopefully very
obvious ones (delete some code).
Bug: 129
Change-Id: Iedbae5d921d0c3979c340ed3106a63b6aa55f3bd
Reviewed-on: https://boringssl-review.googlesource.com/17670
Reviewed-by: Adam Langley <agl@google.com>
This is the last of the non-GTest tests. We never did end up writing
example files or doc.go tooling for them. And probably examples should
be in C++ at this point.
Bug: 129
Change-Id: Icbc43c9639cfed7423df20df1cdcb8c35f23fc1a
Reviewed-on: https://boringssl-review.googlesource.com/17669
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Also document what versions of everything we're using as the .sha1 files
don't say.
Change-Id: I2d496c86761f6df6acd20e1af62094b7d89e5c1d
Reviewed-on: https://boringssl-review.googlesource.com/17485
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
efa4339adde7e627370ed7c46ed00fed5d23310007ef0334ae17510d00e22b8d sde-external-8.5.0-2017-06-08-lin.tar.bz2
Change-Id: I201ca78cbbb3c769ed45705f87b6013758b68349
Reviewed-on: https://boringssl-review.googlesource.com/17484
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
Our old redirectors were emitting code to call their target functions normally.
However, the PPC ABI expects callers to set up parameter save areas for their
callees, notably if the target is a varargs function.
Instead, mimic the pattern used when calling an external function or function
pointer and avoid touching the stack.
Change-Id: Ia28c9d2b82fcd99c4a2f70f5f587d0e0463a6f0e
Reviewed-on: https://boringssl-review.googlesource.com/17284
Reviewed-by: Adam Langley <agl@google.com>
There was a typo there. Also the document's title capitalizes "64-Bit"
and "V2" funny.
Change-Id: I38a7f8d575ce2bb48dcc2ce5a4d683a7a170db87
Reviewed-on: https://boringssl-review.googlesource.com/17268
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
On POWER, r0 is wired to zero in some argument positions of some
instructions. The base register for a load is one of them. Thus, if
rewriting a load to r0, we cannot use r0 to store the base address.
This could be more efficient, but loading to r0 appears to be very rare
so I'm not going to worry about it for now.
Change-Id: I14dac96ba4c0380b166a7667b0cba918f1ae25ec
Reviewed-on: https://boringssl-review.googlesource.com/17065
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
https://boringssl-review.googlesource.com/c/12360/ made us define
BORINGSSL_SHARED_LIBRARY when building tests via Bazel. The test has now
been moved to crypto_test, where the flags are more easily under the
control of the consumer.
Change-Id: If237efca219a1f03d64dc801cc1d585556bf2d1d
Reviewed-on: https://boringssl-review.googlesource.com/16987
Reviewed-by: David Benjamin <davidben@google.com>
We've been compile-testing it for some time, and now we have a path (by
way of GTest and Chromium) to get them test coverage.
Change-Id: Ic33be8fce4bbef10cd586428e74972f230525792
Reviewed-on: https://boringssl-review.googlesource.com/16990
Reviewed-by: Kári Helgason <kthelgason@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Clang 4.0 on ppc64le generated symbols called “.LCE0” and so on.
Change-Id: I6bacf24365aa547d0ca9e5f338e4bb966df31708
Reviewed-on: https://boringssl-review.googlesource.com/17005
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This is a fairly shallow conversion because of the somewhat screwy Error
lines in the test which may target random functions like
EVP_PKEY_CTX_set_signature_md. We probably should revise this, perhaps
moving those to normal tests and leaving error codes to the core
operation itself.
BUG=129
Change-Id: I27dcc945058911b2de40cd48466d4e0366813a12
Reviewed-on: https://boringssl-review.googlesource.com/16988
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
We lost some parallelism by putting the tests into one binary and have
enough giant test vector files now that this takes some time. Shard them
back up again.
BUG=129
Change-Id: I1d196bd8c4851bf975d6b4f2f0403ae65feac884
Reviewed-on: https://boringssl-review.googlesource.com/16984
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
BUG=129
Change-Id: Ia8b0639489fea817be4bb24f0457629f0fd6a815
Reviewed-on: https://boringssl-review.googlesource.com/16947
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: I4e0da85857e820f8151e2fb50d699f14fedee97b
Reviewed-on: https://boringssl-review.googlesource.com/16966
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: I2e7b9e80419758a5ee4f53915f13334bbf8e0447
Reviewed-on: https://boringssl-review.googlesource.com/16965
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Change-Id: Ic22ea72b0134aa7884f1e75433dd5c18247f57ab
Reviewed-on: https://boringssl-review.googlesource.com/16964
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The crypto target depends on having access to the fips_fragments when
compiling bcm.c. Explicitly load and add them as a dependency of that
target.
Change-Id: Ibe6f589cc63b653c52eb2c32b445ec31996b6247
Reviewed-on: https://boringssl-review.googlesource.com/16946
Reviewed-by: Matt Braithwaite <mab@google.com>
Reviewed-by: Adam Langley <agl@google.com>
LLVM likes to emit offsets of the form foo@toc@ha+16, which we didn't
support. Generalize parseMemRef to handle this case and avoid some of
the repeated offset special-cases. Offsets are now always folded into
the SymbolRef.
This still does not quite implement a fully general GAS-compatible
parser as GAS's parser is insane. GAS in x86_64 will happily accept
things like:
1@GOTPCREL+foo
blah1@GOTPCREL-blah2+blah3-blah4+blah5 # GOTPCREL modifies blah5, rest
# of expression is an offset.
GAS actually textually pulls @GOTPCREL out of the input partway through
parsing the expression and parses the modified input! Then its normal
parser goes and maintains a running expression of a specific type and,
at each term, attempts to merge it into what it currently has. So adding
and subtracting symbols is not commutative (signs must alternate or so)
and the last symbol wins.
However its PPC64 parser is not as general and just terminates each
expression after @toc@ha and friends, except that it special-cases
foo@toc@ha+16: if it can parse one more expression after @toc@ha AND it
is a constant expression, then it is added into the running offset.
Otherwise it leaves that data unconsumed.
This is all ridiculous, so just generalize our parser slightly to cover
foo@toc@ha+16 and see how far we get from there.
Change-Id: I65970791fc10fb2638fd7be8cc841900eb997c9c
Reviewed-on: https://boringssl-review.googlesource.com/16944
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
BUG=129
Change-Id: I1fef45d662743e7210f93e4dc1bae0c55f75d3fe
Reviewed-on: https://boringssl-review.googlesource.com/16864
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
An offset > 2^15 would exceed the range of an addi immediate on ppc64le.
Thus, rather than add the offset after loading the TOC reference, have
different tocloader functions for each (symbol, offset) pair. In this
case, the linker can handle large offsets by changing the value of
foo+offset@toc@ha accordingly.
Change-Id: Iac1481bccaf55fb0c2b080eedebaf11befdae465
Reviewed-on: https://boringssl-review.googlesource.com/16784
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
At first I thought something was wrong, but some experiments with GCC
and digging into relocation definitions confirmed things were fine. In
doing so, tweak the comments so the offset is written more clearly. Both
offset+foo@toc@l and foo@toc@l+offset bind apply the @l after adding the
offset, but it's slightly less confusing with the former spelling.
Change-Id: I43b2c0b8855f64ac6ca4d95ae85bec680a19bc1c
Reviewed-on: https://boringssl-review.googlesource.com/16705
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Most importantly, this version of delocate works for ppc64le. It should
also work for x86-64, but will need significant testing to make sure
that it covers all the cases that the previous delocate.go covered.
It's less stringtastic than the old code, however the parser isn't as
nice as I would have liked. I thought that the reason we put up with
AT&T syntax with Intel is so that assembly syntax could be somewhat
consistent across platforms. At least for ppc64le, that does not appear
to be the case.
Change-Id: Ic7e3c6acc3803d19f2c3ff5620c5e39703d74212
Reviewed-on: https://boringssl-review.googlesource.com/16464
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
The symbol “rcon” should be local in order to avoid collisions and it's
much easier on delocate if some of the expressions are evalulated in
Perl rather than left in the resulting .S file.
Also fix the perlasm style so the symbols are actually local.
Change-Id: Iddfc661fc3a6504bcc5732abaa1174da89ad805e
Reviewed-on: https://boringssl-review.googlesource.com/16524
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
