Errorf treats its argument as a format string and so “%rax” is a
problem.
Change-Id: I863ef361f07d0b8a348994efe45869202d0b31f1
Reviewed-on: https://boringssl-review.googlesource.com/24944
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
(This can be generated with -mavx2.)
Change-Id: I6d92d9e93eb448357342ef86d050321f0ef40f9e
Reviewed-on: https://boringssl-review.googlesource.com/24504
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>
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>
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>
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>
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>
5c38c05b26 caused foo@GOTPCREL for
external foo to resolve to bcm_redirector_foo. This is morally
equivalent to using foo@PLT when a pointer to foo is needed. But this
does not work if foo is data. Notably, this ended up mangling
OPENSSL_ia32cap_P because it failed to recognize it as an symbol in the
library (but external to the module). It also mangles some things that
ASan emits.
(It also breaks non-NULL function pointer comparisons, but those are
silly.)
Instead, apply a variation of the OPENSSL_ia32cap_addr_delta trick that
works for the GOT. "addr_delta" is really weird, so I'm calling this an
"external relocation". This causes fprintf(stderr) to work and also
seems to keep ASan compiling. I was unable to reproduce the case that
5c38c05b26 added the bcm_redirector_foo
transform for.
Also tighten up the pattern. No need to reference a bit of memory twice
since we just loaded it into a register.
Change-Id: If5520fc0887e83e23a08828e40fbbed9e47d912e
Reviewed-on: https://boringssl-review.googlesource.com/16345
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>
This makes things a little easier for some of our tooling.
Change-Id: Ia7e73daf0a5150b106cf9b03b10cae194cb8fc5a
Reviewed-on: https://boringssl-review.googlesource.com/15104
Reviewed-by: Matt Braithwaite <mab@google.com>
Reviewed-by: Adam Langley <agl@google.com>
