cmd/link: new c-shared relocations of the ELF ABI on LoongArch #58784
Comments
|
@golang/loong64 @cherrymui |
|
We recommend removing support for stack-based relocation. The work of the LoongArch community is still in its initial stage. And, there are still very few users based on stack-style relocations, the impact of deletion is not very great. If we continue to use the old relocation, it may be more difficult to deal with this part in the future, finally, it will become a historical burden. |
|
Change https://go.dev/cl/425474 mentions this issue: |
|
Change https://go.dev/cl/425479 mentions this issue: |
|
Change https://go.dev/cl/425478 mentions this issue: |
|
Change https://go.dev/cl/425475 mentions this issue: |
|
Change https://go.dev/cl/425476 mentions this issue: |
|
Change https://go.dev/cl/425477 mentions this issue: |
|
For the record, I'm also in support of getting rid of support for the stack-based relocation scheme. Although the old world is still on it, no upstream project is aware of it, and in effect the new world already requires recent enough toolchain versions so that support for the ELF psABI v2.0 relocs can be assumed. This will in practice harm no end user, due to the new world's currently small and technical user base, and will allow us to shed large amount of technical debt. I've spoken privately with the Loongson team and the decision is something we all agree on. |
|
I think it's better to use the English documentation link: |
|
I also support limeidan's suggestion to remove stack-based relocation. At present, in addition to the above debian, gentoo, loong64 builder, the Linux kernel has used the new relocation to load modules(torvalds/linux@0a75e5d). |
|
Sounds fine to me. Thanks. So you estimate that it will affect very small amount of users? And updating the C toolchain is relatively straightforward? Do you think Go 1.21 release (Aug 2023) is a good time for this, or do it in a later release so the new C toolchain is more widely available? Thanks. |
|
Yes, currently there are very few LoongArch users using the community source code. The users of the community code are basically upstream developers or based on experimental nature, not a production environment, so timely changes have little impact. For golang, the update of the C toolchain only involves the upgrade of binutils, which is relatively simple. I think it's a good time to support new relocations in Go 1.21:
Thanks. |
|
Change https://go.dev/cl/455017 mentions this issue: |
|
Change https://go.dev/cl/455016 mentions this issue: |
AFAIK yes, we've always been discouraging casual end-users from trying the new-world for the last 2 years.
Yes. All new-world distros stick to latest toolchains in general (sometimes even chasing weekly snapshots, as been the case with Gentoo/LoongArch's GCC 13). All are already switched to psABI v2.
Given the current development pace of new-world distros, Aug 2023 most certainly works, since both binutils 2.40 and gcc 13 would be officially released for a while then, and distros are expected to pick up the versions real quick. Many are already done after all... |
The LoongArch ELF psABI v2.00 revamped the relocation design, largely moving to using the `pcalau12i + addi/ld/st` pair for PC-relative addressing within +/- 32 bits. The "pcala" in `pcalau12i` stands for "PC-aligned add"; the instruction's semantics happen to coincide with arm64's `adrp`. Add support for emitting this instruction as part of the relevant addressing ops, for use with new reloc types later. Updates golang#58784 Change-Id: Ic1747cd9745aad0d1abb9bd78400cd5ff5978bc8
…psABI v2 relocs The LoongArch ELF psABI v2 [1] relocs are vastly simplified from the v1 which involved a stack machine for computing the reloc values, but the details of PC-relative addressing are changed as well. Specifically, the `pcaddu12i` instruction is substituted with the `pcalau12i`, which is like arm64's `adrp` -- meaning the lower bits of a symbol's address now have to be absolute and not PC-relative. However, the little bit of added complexity apart, the obvious advantage is that only 1 reloc needs to be emitted for every kind of external reloc we care about, which can mean substantial space savings, and no open-coded stack ops has to remain any more. While at it, update the preset value for the output ELF's flags to indicate the psABI update. This prevents legacy toolchains from seeing the new reloc types too. Updates golang#58784 [1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html Change-Id: I5c13bc710eaf58293a32e930dd33feff2ef14c28
These c-shared related CLs are follow up of CLs 455016, 455017, 455018. Here we follow the LoongArch ELF psABI v2 standard, which requires the support of the PCALAU12I instruction. Updates golang#53301 Updates golang#58784 Change-Id: I7f1ddbf3b2470d610f12069d147aa9b3a6a96f32
Updates golang#53301 Updates golang#58784 Change-Id: I78a90155b17d7d8be04e8ba5e4d75e27d15b3311
…ns on loong64 Updates golang#53301 Updates golang#58784 Change-Id: Ifcb40871f609531dfd8b568db9ac14da9b451742
Updates golang#53301 Updates golang#58784 Change-Id: I4b726b0cc09e5e008b92b3e0a8a7bdd103b062c4
…ture and test on loong64 Linux kernel on loong64 has no Dup2 syscall support, so we use Dup3 to replace it like arm64 and riscv64. Updates golang#53301 Updates golang#58784 Change-Id: I4e0be140a71b86f4626ed39d76cf3ac78f842018
…psABI v2 relocs The LoongArch ELF psABI v2 [1] relocs are vastly simplified from the v1 which involved a stack machine for computing the reloc values, but the details of PC-relative addressing are changed as well. Specifically, the `pcaddu12i` instruction is substituted with the `pcalau12i`, which is like arm64's `adrp` -- meaning the lower bits of a symbol's address now have to be absolute and not PC-relative. However, apart from the little bit of added complexity, the obvious advantage is that only 1 reloc needs to be emitted for every kind of external reloc we care about. This can mean substantial space savings (each RELA reloc occupies 24 bytes), and no open-coded stack ops has to remain any more. While at it, update the preset value for the output ELF's flags to indicate the psABI update. Fixes golang#58784 [1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html Change-Id: I5c13bc710eaf58293a32e930dd33feff2ef14c28
|
Change https://go.dev/cl/480875 mentions this issue: |
|
CL #480875 also uses a new relocation implementation in accessing GOT, which makes the code look more concise. |
These c-shared related CLs are follow up of CLs 455016, 455017, 455018. Here we follow the LoongArch ELF psABI v2 standard, which requires the support of the PCALAU12I instruction. Updates golang#53301 Updates golang#58784 Change-Id: I7f1ddbf3b2470d610f12069d147aa9b3a6a96f32
Updates golang#53301 Updates golang#58784 Change-Id: I78a90155b17d7d8be04e8ba5e4d75e27d15b3311
…ns on loong64 Updates golang#53301 Updates golang#58784 Change-Id: Ifcb40871f609531dfd8b568db9ac14da9b451742
Updates golang#53301 Updates golang#58784 Change-Id: I4b726b0cc09e5e008b92b3e0a8a7bdd103b062c4
…ture and test on loong64 Linux kernel on loong64 has no Dup2 syscall support, so we use Dup3 to replace it like arm64 and riscv64. Updates golang#53301 Updates golang#58784 Change-Id: I4e0be140a71b86f4626ed39d76cf3ac78f842018
…e on loong64 Updates golang#58784 Change-Id: Ic98d10a512fea0c3ca321ab52693d9f6775126a6
|
I updated in CL 483455 the cross toolchain that generates the zerors_GOOS_GOARCH.go file dependencies in sys, which also uses the new relocation type. Thanks. |
These c-shared related CLs are follow up of CLs 455016, 455017, 455018. Here we follow the LoongArch ELF psABI v2 standard, which requires the support of the PCALAU12I instruction. Updates #53301 Updates #58784 Change-Id: I7f1ddbf3b2470d610f12069d147aa9b3a6a96f32 Reviewed-on: https://go-review.googlesource.com/c/go/+/425474 Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: WANG Xuerui <git@xen0n.name> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
These c-shared related CLs are follow up of CLs 455016, 455017, 455018. Here we follow the LoongArch ELF psABI v2 standard, which requires the support of the PCALAU12I instruction. Updates golang#53301 Updates golang#58784 Change-Id: I7f1ddbf3b2470d610f12069d147aa9b3a6a96f32
…ns on loong64 Updates golang#53301 Updates golang#58784 Change-Id: Ifcb40871f609531dfd8b568db9ac14da9b451742
…for --buildmode=c-shared on loong64 Updates #53301 Updates #58784 Change-Id: Ifcb40871f609531dfd8b568db9ac14da9b451742 Reviewed-on: https://go-review.googlesource.com/c/go/+/425476 Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Benny Siegert <bsiegert@gmail.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> Run-TryBot: WANG Xuerui <git@xen0n.name> Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: WANG Xuerui <git@xen0n.name>
…ture and test on loong64 Linux kernel on loong64 has no Dup2 syscall support, so we use Dup3 to replace it like arm64 and riscv64. Updates #53301 Fixes #58784 Change-Id: I4e0be140a71b86f4626ed39d76cf3ac78f842018 Reviewed-on: https://go-review.googlesource.com/c/go/+/425478 Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: WANG Xuerui <git@xen0n.name> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn> Run-TryBot: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: xiaodong liu <teaofmoli@gmail.com> Reviewed-by: WANG Xuerui <git@xen0n.name>
…e on loong64 Updates golang#58784 Change-Id: Ic98d10a512fea0c3ca321ab52693d9f6775126a6
The LoongArch ELF psABI v2.00 revamped the relocation design, largely moving to using the `pcalau12i + addi/ld/st` pair for PC-relative addressing within +/- 32 bits. The "pcala" in `pcalau12i` stands for "PC-aligned add"; the instruction's semantics happen to coincide with arm64's `adrp`. Add support for emitting this instruction as part of the relevant addressing ops, for use with new reloc types later. Updates golang#58784 Change-Id: Ic1747cd9745aad0d1abb9bd78400cd5ff5978bc8 Reviewed-on: https://go-review.googlesource.com/c/go/+/455016 Reviewed-by: abner chenc <chenguoqi@loongson.cn> Auto-Submit: Wayne Zuo <wdvxdr@golangcn.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Wayne Zuo <wdvxdr@golangcn.org> Reviewed-by: xiaodong liu <teaofmoli@gmail.com> Reviewed-by: Meidan Li <limeidan@loongson.cn> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit b4ac4b4)
…psABI v2 relocs The LoongArch ELF psABI v2 [1] relocs are vastly simplified from the v1 which involved a stack machine for computing the reloc values, but the details of PC-relative addressing are changed as well. Specifically, the `pcaddu12i` instruction is substituted with the `pcalau12i`, which is like arm64's `adrp` -- meaning the lower bits of a symbol's address now have to be absolute and not PC-relative. However, apart from the little bit of added complexity, the obvious advantage is that only 1 reloc needs to be emitted for every kind of external reloc we care about. This can mean substantial space savings (each RELA reloc occupies 24 bytes), and no open-coded stack ops has to remain any more. While at it, update the preset value for the output ELF's flags to indicate the psABI update. Fixes golang#58784 [1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html Change-Id: I5c13bc710eaf58293a32e930dd33feff2ef14c28 Reviewed-on: https://go-review.googlesource.com/c/go/+/455017 Run-TryBot: Ben Shi <powerman1st@163.com> Reviewed-by: xiaodong liu <teaofmoli@gmail.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Meidan Li <limeidan@loongson.cn> Auto-Submit: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> (cherry picked from commit a3dd959)
These c-shared related CLs are follow up of CLs 455016, 455017, 455018. Here we follow the LoongArch ELF psABI v2 standard, which requires the support of the PCALAU12I instruction. Updates golang#53301 Updates golang#58784 Change-Id: I7f1ddbf3b2470d610f12069d147aa9b3a6a96f32 Reviewed-on: https://go-review.googlesource.com/c/go/+/425474 Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: WANG Xuerui <git@xen0n.name> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit 80eeec6)
…, cmd/link: add support for --buildmode=c-shared on loong64 Updates golang#53301 Updates golang#58784 Change-Id: Ifcb40871f609531dfd8b568db9ac14da9b451742 Reviewed-on: https://go-review.googlesource.com/c/go/+/425476 Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Benny Siegert <bsiegert@gmail.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> Run-TryBot: WANG Xuerui <git@xen0n.name> Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: WANG Xuerui <git@xen0n.name> (cherry picked from commit 1f908bd)
…red: enable c-shared feature and test on loong64 Linux kernel on loong64 has no Dup2 syscall support, so we use Dup3 to replace it like arm64 and riscv64. Updates golang#53301 Fixes golang#58784 Change-Id: I4e0be140a71b86f4626ed39d76cf3ac78f842018 Reviewed-on: https://go-review.googlesource.com/c/go/+/425478 Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: WANG Xuerui <git@xen0n.name> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn> Run-TryBot: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: xiaodong liu <teaofmoli@gmail.com> Reviewed-by: WANG Xuerui <git@xen0n.name> (cherry picked from commit b3a194a)
…e on loong64 Updates golang#58784 Change-Id: Ic98d10a512fea0c3ca321ab52693d9f6775126a6
…e on loong64 Updates golang#58784 Change-Id: Ic98d10a512fea0c3ca321ab52693d9f6775126a6
…e on loong64 Updates #58784 Change-Id: Ic98d10a512fea0c3ca321ab52693d9f6775126a6 Reviewed-on: https://go-review.googlesource.com/c/go/+/480875 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Meidan Li <limeidan@loongson.cn> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: WANG Xuerui <git@xen0n.name> Reviewed-by: WANG Xuerui <git@xen0n.name>
Hi everyone,
This Issue is opened to discuss relocation-related issues in the LoongArch ELF ABI.
Here's the section on relocations from the LoongArch ELF ABI documentation:
https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_relocations
Initially, in order to easily understand the relocation process when linking binary files (the linker reads the relocation table linearly, which can be naturally associated with stack operations), LoongArch adopts a relocation mechanism based on a data stack, also, considering the reusability, the granularity of these relocations is small.
However, in subsequent practice, it was found that this approach will lead to a large increase in the number of relocations in the binary file.
Therefore, LoongArch has added relocation types from No. 64 to No. 100 on the original basis. These relocations have a large operation granularity, and they can directly implement a single function without stack operations, which solves the problem of excessive relocations.
Regarding compatibility:
Binutils supported LoongArch when version 2.38 was released. Since v2.40, it supports the new relocation of LoongArch. The original relocation has not been deleted, so v2.40 and later versions can also support early relocation. Released v2.38 and v2.39 do not support the new relocations.
User machine:
The upcoming debian12 already uses binutils-2.40, and LoongArch is currently being submitted on the debian development branch. It is foreseeable that in the future debian version that supports LoongArch (maybe debian13), the binutils used in it must support the newly added relocation .
The latest Gentoo system that has been released uses binutils-2.40.
The loong64 builders we are using also support the new relocations.
The text was updated successfully, but these errors were encountered: