kris/boringssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
b018908475
boringssl/util/fipstools/delocate/testdata/ppc64le-TOCWithOffset/in.s

24 lines
414 B
ArmAsm
Raw Normal View History

Switch to new delocate tool. 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>
2017-05-17 21:05:50 +01:00
.text
foo:
# TOC references may have offsets.
addis 3, 2, 5+foo@toc@ha
addi 3, 3, 10+foo@toc@l
addis 3, 2, 15+foo@toc@ha
addi 3, 3, 20+foo@toc@l
addis 4, 2, foo@toc@ha
addi 4, 4, foo@toc@l
addis 5, 2, 5+foo@toc@ha
ld 5, 10+foo@toc@l(5)
Handle TOC offsets by giving them to the linker. 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>
2017-06-01 01:02:42 +01:00
addis 4, 2, foo-10@toc@ha
addi 4, 4, foo-10@toc@l
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>
2017-06-06 21:03:53 +01:00
addis 4, 2, foo@toc@ha+25
addi 4, 4, foo@toc@l+25
addis 4, 2, 1+foo-2@toc@ha+3
addi 4, 4, 1+foo-2@toc@l+3
Reference in New Issue Copy Permalink