Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: cmd/link: create an information section with eface type struct addresses #48840

Closed
vpachkov opened this issue Oct 7, 2021 · 6 comments

Comments

@vpachkov
Copy link
Contributor

vpachkov commented Oct 7, 2021

Unlike iface, which has itab structure and we could get to type struct (runtime/type.go), eface doesn't have one and the code (compiled with pic) gets type address directly, using lea instructions on x86.

Example : lea 0x100050(%rip), %rax # 200500 <type.*+0x1234>

To handle it I propose to create an information section (debug type, that could be stripped) with an array of eface type structures, so it could be easily found in a binary file.

This information is required for further handling of Golang executables by post-link-optimizer tools like Bolt to make it possible to read actual information about eface types and account it during further basic blocks reordering.

Golang support for Bolt was announced here: facebookarchive/BOLT#154 (comment)

Currently, we are close to upstream Golang support in Bolt, but it requires changes described in this proposal.

@gopherbot gopherbot added this to the Proposal milestone Oct 7, 2021
@vpachkov
Copy link
Contributor Author

vpachkov commented Oct 7, 2021

#48765 PR contains an experimental implementation of this functionality.

@randall77
Copy link
Contributor

Note that #48532 is probably going to need a similar (but probably more invasive) fix.

@ianlancetaylor ianlancetaylor changed the title Proposal: Create an information section with eface type struct addresses proposal: create an information section with eface type struct addresses Oct 8, 2021
@ianlancetaylor
Copy link
Contributor

What do you mean by "eface type structures"?

Currently a value of empty interface type is a pair of pointers. The first pointer points to the runtime._type structure that describes the type stored in the interface. This is the same as the underlying structure held in a reflect.Type interface value returned by reflect.TypeOf.

Those type structures can already be identified in an executable by looking for the runtime.types symbol (up to the runtime.etypes symbol).

Do you need something more than that? If so, what?

@ianlancetaylor ianlancetaylor added this to Incoming in Proposals (old) Oct 8, 2021
@rsc rsc changed the title proposal: create an information section with eface type struct addresses proposal: cmd/link: create an information section with eface type struct addresses Oct 13, 2021
@rsc
Copy link
Contributor

rsc commented Oct 13, 2021

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

@rsc rsc moved this from Incoming to Active in Proposals (old) Oct 13, 2021
@vpachkov
Copy link
Contributor Author

What do you mean by "eface type structures"?

Currently a value of empty interface type is a pair of pointers. The first pointer points to the runtime._type structure that describes the type stored in the interface. This is the same as the underlying structure held in a reflect.Type interface value returned by reflect.TypeOf.

Those type structures can already be identified in an executable by looking for the runtime.types symbol (up to the runtime.etypes symbol).

Do you need something more than that? If so, what?

Thank you for your reply! I looked closely at the cmd/link part and found out that every type is placed inside runtime.types. Indeed, all the types stored in runtime2.eface structure can be found there.

@rsc rsc moved this from Active to Declined in Proposals (old) Oct 20, 2021
@rsc
Copy link
Contributor

rsc commented Oct 20, 2021

This proposal has been declined as retracted.
— rsc for the proposal review group

@golang golang locked and limited conversation to collaborators Oct 20, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
No open projects
Development

No branches or pull requests

5 participants