Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
runtime: Windows: pprof output is broken in cgo packages for go test -cpuprofile #18416
Old issue: #16891
I'm concerned that even with embedded symbols in 1.8, this will still be an issue.
Please answer these questions before submitting your issue. Thanks!
The issue seems to be related to use of the
I tested with a bare CGo sample, and also a control.
On the old issue, rsc wrote:
Now you write:
But there's no mention of go1.8 in this bug report(?). You only show results from 1.6 and 1.7.
Did you try tip (the current master, soon-to-be go1.8)? Can you reproduce this on tip?
I made sure to remove the existing binary and profile.
I copied the "bug" versions of your file but changed the package to issue18416.
With current tip:
I am not seeing the result you report, where you get no results.
However, I am running on GNU/Linux, so this may be somehow Windows-specific.
I can reproduce this too. Only on windows/386, and, yes, it is broken by ed8f0e5. I have built issue18416.test.exe with
that all PE symbols in bad.exe have superfluous underscore in front of them.
So cmd/internal/objfile won't find any symbols in that executable. All correspondent go tools (nm, objdump, maybe others) would be broken too. This is for cgo only. We have a test for this in cmd/nm, but it does not test cgo.
I will let others decide what to do here. Please, let me know if I can help in any way. Thank you.
The mangling scheme was established by Microsoft, and has been informally followed by other compilers including Digital Mars, Borland, and GNU GCC, when compiling code for the Windows platforms. The scheme even applies to other languages, such as Pascal, D, Delphi, Fortran, and C#. This allows subroutines written in those languages to call, or be called by, existing Windows libraries using a calling convention different from their default.
When compiling the following C examples:
32 bit compilers emit, respectively:
In the stdcall and fastcall mangling schemes, the function is encoded as _name@X and @name@X respectively, where X is the number of bytes, in decimal, of the argument(s) in the parameter list (including those passed in registers, for fastcall). In the case of cdecl, the function name is merely prefixed by an underscore.
The 64-bit convention on Windows (Microsoft C) has no leading underscore.
I do not plan on fixing the broken tools, since that is the responsibility of the people that made them. I don't like the convention Microsoft established, but that is nonetheless what they did.