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
trace.py support for args with Go's gc compiler #934
Comments
If you're looking for datapoints, I used to (go 1.0) rely on gccgo when I needed to link in external C libraries, but nowadays native go is my go-to. |
I'd go for a helper syntax like But there's also always the general remark that we keep pushing the trace/argdist syntax further and further, and there has to be a point where we recommend a dedicated script. @brendangregg |
We also use I'd be happy to do the work to get this functionality added to the |
Someone just told me about this, possible for go 1.8: https://go-review.googlesource.com/#/c/28832/
Maybe Go is going to switch to the x86_84 ABI? |
@kelleyk I think having |
I think that the details of the new Go ABI are still up in the air, and from golang/go#18597 it sounds like the change is motivated by performance and not by standardization. There is some mention of making the new ABI a superset of the platform ABI, but also not a lot of hesitation to stray when useful (by, for example, skipping the 160-byte save area on s390x). It also seems like it would land in @goldshtn Thanks for the guidance! Let me see if I can find a minute to take a stab at |
I ran across this and started toying with a PR. What I'm finding is that the changes required to |
@nyarly Anything that works would be better than having no solution at all, but I think having a separate tool in the long run would not be great. If you're so inclined, you could hack on gotrace.py temporarily, just to see if the approach works, but I think we should have a single tool that can support both use cases. And if it means a massive refactoring of trace.py's (admittedly already hacky) code, I'm afraid that's just a prerequisite for this work. Merging gotrace.py risks diverging in a way that's detrimental to our goals here, in my opinion. |
I agree that separate tooling is sub-optimal. Candidly, I think refactoring |
Implemented #1719 as a first cut of this. |
trace's arg# aliases work with Go when compiled with gccgo ("gccgo -o hello hello.go"). But Go's gc compiler ("go build hello.go") uses a different function calling convention, based on the Plan 9 compiler.
Is it important to fix this? Does everyone run gccgo binaries (where trace already works), because they are expected to be faster, and not Go's compiler? I don't know. I've added a prio:low tag for now.
I wrote some quick docs on the issues here: http://www.brendangregg.com/blog/2017-01-31/golang-bcc-bpf-function-tracing.html
And included a proof of concept:
The change I made was a dirty hack, and needs to be rewritten properly. I'd done this:
They should be "goarg1", "goarg1", etc. I suspect this also needs to be done differently so that they can be used in tests, eg, "(goarg1 == 42)". And this should use macros instead of ctx->sp.
I'd also check the following resources to confirm that this approach is valid:
The text was updated successfully, but these errors were encountered: