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

208 lines
4.0 KiB
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
BORINGSSL_bcm_text_start:
.text
.Lfoo_local_target:
foo:
# TOC references may have offsets.
# WAS addis 3, 2, 5+foo@toc@ha
# WAS addi 3, 3, 10+foo@toc@l
addi 1, 1, -288
mflr 3
std 3, -8(1)
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
bl .Lbcm_loadtoc__dot_Lfoo_local_target__plus_10
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
std 3, -24(1)
ld 3, -8(1)
mtlr 3
ld 3, -24(1)
addi 1, 1, 288
# WAS addis 3, 2, 15+foo@toc@ha
# WAS addi 3, 3, 20+foo@toc@l
addi 1, 1, -288
mflr 3
std 3, -8(1)
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
bl .Lbcm_loadtoc__dot_Lfoo_local_target__plus_20
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
std 3, -24(1)
ld 3, -8(1)
mtlr 3
ld 3, -24(1)
addi 1, 1, 288
# WAS addis 4, 2, foo@toc@ha
# WAS addi 4, 4, foo@toc@l
addi 1, 1, -288
mflr 4
std 4, -8(1)
std 3, -16(1)
bl .Lbcm_loadtoc__dot_Lfoo_local_target
std 3, -24(1)
ld 3, -8(1)
mtlr 3
ld 4, -24(1)
ld 3, -16(1)
addi 1, 1, 288
# WAS addis 5, 2, 5+foo@toc@ha
# WAS ld 5, 10+foo@toc@l(5)
addi 1, 1, -288
mflr 5
std 5, -8(1)
std 3, -16(1)
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
bl .Lbcm_loadtoc__dot_Lfoo_local_target__plus_10
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
std 3, -24(1)
ld 3, -8(1)
mtlr 3
ld 5, -24(1)
ld 3, -16(1)
addi 1, 1, 288
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
ld 5, 0(5)
# WAS addis 4, 2, foo-10@toc@ha
# WAS addi 4, 4, foo-10@toc@l
addi 1, 1, -288
mflr 4
std 4, -8(1)
std 3, -16(1)
bl .Lbcm_loadtoc__dot_Lfoo_local_target__minus_10
std 3, -24(1)
ld 3, -8(1)
mtlr 3
ld 4, -24(1)
ld 3, -16(1)
addi 1, 1, 288
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
# WAS addis 4, 2, foo@toc@ha+25
# WAS addi 4, 4, foo@toc@l+25
addi 1, 1, -288
mflr 4
std 4, -8(1)
std 3, -16(1)
bl .Lbcm_loadtoc__dot_Lfoo_local_target__plus_25
std 3, -24(1)
ld 3, -8(1)
mtlr 3
ld 4, -24(1)
ld 3, -16(1)
addi 1, 1, 288
# WAS addis 4, 2, 1+foo-2@toc@ha+3
# WAS addi 4, 4, 1+foo-2@toc@l+3
addi 1, 1, -288
mflr 4
std 4, -8(1)
std 3, -16(1)
bl .Lbcm_loadtoc__dot_Lfoo_local_target__plus_1_minus_2_plus_3
std 3, -24(1)
ld 3, -8(1)
mtlr 3
ld 4, -24(1)
ld 3, -16(1)
addi 1, 1, 288
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
BORINGSSL_bcm_text_end:
.type bcm_loadtoc__dot_Lfoo_local_target, @function
bcm_loadtoc__dot_Lfoo_local_target:
.Lbcm_loadtoc__dot_Lfoo_local_target:
addis 3, 2, .Lfoo_local_target@toc@ha
addi 3, 3, .Lfoo_local_target@toc@l
blr
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
.type bcm_loadtoc__dot_Lfoo_local_target__plus_1_minus_2_plus_3, @function
bcm_loadtoc__dot_Lfoo_local_target__plus_1_minus_2_plus_3:
.Lbcm_loadtoc__dot_Lfoo_local_target__plus_1_minus_2_plus_3:
addis 3, 2, .Lfoo_local_target+1-2+3@toc@ha
addi 3, 3, .Lfoo_local_target+1-2+3@toc@l
blr
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
.type bcm_loadtoc__dot_Lfoo_local_target__plus_10, @function
bcm_loadtoc__dot_Lfoo_local_target__plus_10:
.Lbcm_loadtoc__dot_Lfoo_local_target__plus_10:
addis 3, 2, .Lfoo_local_target+10@toc@ha
addi 3, 3, .Lfoo_local_target+10@toc@l
blr
.type bcm_loadtoc__dot_Lfoo_local_target__plus_20, @function
bcm_loadtoc__dot_Lfoo_local_target__plus_20:
.Lbcm_loadtoc__dot_Lfoo_local_target__plus_20:
addis 3, 2, .Lfoo_local_target+20@toc@ha
addi 3, 3, .Lfoo_local_target+20@toc@l
blr
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
.type bcm_loadtoc__dot_Lfoo_local_target__plus_25, @function
bcm_loadtoc__dot_Lfoo_local_target__plus_25:
.Lbcm_loadtoc__dot_Lfoo_local_target__plus_25:
addis 3, 2, .Lfoo_local_target+25@toc@ha
addi 3, 3, .Lfoo_local_target+25@toc@l
blr
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
.type bcm_loadtoc__dot_Lfoo_local_target__minus_10, @function
bcm_loadtoc__dot_Lfoo_local_target__minus_10:
.Lbcm_loadtoc__dot_Lfoo_local_target__minus_10:
addis 3, 2, .Lfoo_local_target-10@toc@ha
addi 3, 3, .Lfoo_local_target-10@toc@l
blr
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
.LBORINGSSL_external_toc:
.quad .TOC.-.LBORINGSSL_external_toc
.type BORINGSSL_bcm_text_hash, @object
.size BORINGSSL_bcm_text_hash, 64
BORINGSSL_bcm_text_hash:
.byte 0xae
.byte 0x2c
.byte 0xea
.byte 0x2a
.byte 0xbd
.byte 0xa6
.byte 0xf3
.byte 0xec
.byte 0x97
.byte 0x7f
.byte 0x9b
.byte 0xf6
.byte 0x94
.byte 0x9a
.byte 0xfc
.byte 0x83
.byte 0x68
.byte 0x27
.byte 0xcb
.byte 0xa0
.byte 0xa0
.byte 0x9f
.byte 0x6b
.byte 0x6f
.byte 0xde
.byte 0x52
.byte 0xcd
.byte 0xe2
.byte 0xcd
.byte 0xff
.byte 0x31
.byte 0x80
.byte 0xa2
.byte 0xd4
.byte 0xc3
.byte 0x66
.byte 0xf
.byte 0xc2
.byte 0x6a
.byte 0x7b
.byte 0xf4
.byte 0xbe
.byte 0x39
.byte 0xa2
.byte 0xd7
.byte 0x25
.byte 0xdb
.byte 0x21
.byte 0x98
.byte 0xe9
.byte 0xd5
.byte 0x53
.byte 0xbf
.byte 0x5c
.byte 0x32
.byte 0x6
.byte 0x83
.byte 0x34
.byte 0xc
.byte 0x65
.byte 0x89
.byte 0x52
.byte 0xbd
.byte 0x1f
Reference in New Issue Copy Permalink