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>
