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

gccgo: switch to new export format #17573

Open
paranoiacblack opened this issue Oct 24, 2016 · 4 comments
Open

gccgo: switch to new export format #17573

paranoiacblack opened this issue Oct 24, 2016 · 4 comments
Labels
Milestone

Comments

@paranoiacblack
Copy link
Contributor

@paranoiacblack paranoiacblack commented Oct 24, 2016

cmd/compile recently switched to a non-textual export format (#13241) and now it seems like gccgo is the odd compiler out with respect to the export format. We should update gccgo's export format to match cmd/compile's.

For the team working on Go tooling, this will simplify the work these tools have to do to analyze compiled Go programs in build environments with multiple compilers. Ideally, they shouldn't have to consider that they are possibly looking at gccgo-compiled code; it should be transparent.

@paranoiacblack paranoiacblack added this to the Gccgo milestone Oct 24, 2016
@thanm
Copy link
Member

@thanm thanm commented Oct 25, 2016

This seems like a good thing to do. It does seem as though there are things in the gccgo export data that don't have directly correspondents in the cmd/compile format (notably init function handling).

@alandonovan
Copy link
Contributor

@alandonovan alandonovan commented Oct 25, 2016

Speaking of init functions, why does gccgo gather them up and present them all to the main package, rather than taking the regular and uniform approach of gc, which is (a) make each package initialize its direct dependencies and (b) make init functions idempotent?

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Oct 25, 2016

This may not be the best place for gccgo design discussions, but it's simply because the gccgo approach is more efficient for large programs.

@moazzamk
Copy link

@moazzamk moazzamk commented Jan 9, 2017

I'm willing to work on this if someone can show me what needs to be done (I don't have much experience with C/C++).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.