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 · 5 comments
Closed
Labels
Projects
Milestone

Comments

@vpachkov
Copy link
Contributor

@vpachkov 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: facebookincubator/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 vpachkov commented Oct 7, 2021

#48765 PR contains an experimental implementation of this functionality.

@randall77
Copy link
Contributor

@randall77 randall77 commented Oct 7, 2021

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

@ianlancetaylor ianlancetaylor commented Oct 8, 2021

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 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 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 Oct 13, 2021
@vpachkov
Copy link
Contributor Author

@vpachkov vpachkov commented Oct 14, 2021

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.

@vpachkov vpachkov closed this Oct 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants