| commit | 055375ef2629d1547324113968f824a76879c927 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Tue Jun 06 16:03:53 2017 -0400 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Tue Jun 06 22:48:26 2017 +0000 |
| tree | 9259da4a43f5c8a1eba1f2821972204dcdd3e34e | |
| parent | b0bb83a583d2f68e30ffcacbff5141feabed7c54 [diff] |
Support more complex offset / symbol section interleavings.
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>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
There are other files in this directory which might be helpful: