Can dlv trace print the value of the arguments passed to a function?

[aojea]

trafficstars

1. What version of Delve are you using (dlv version)?

Delve Debugger
Version: 1.21.2
Build: $Id: 98f8ab2662d926245917ade2f2bb38277315c7fc $

2. What version of Go are you using? (go version)?

1.21.3

4. What operating system and processor architecture are you using?

Linux x86

6. What did you do?

dlv trace . k8s.io --timestamp=true 

8. What did you expect to see?

The values of the parameters passed to the function

9. What did you see instead?

2023-11-27T14:56:54.338358579-08:00 > goroutine(1): main.(*repoSync).SetupDefaultGitConfigs((*main.repoSync)(0xc000099040), context.Context(*context.timerCtx) 0xb
eef000000000108)
2023-11-27T14:56:54.340307306-08:00 > goroutine(1): main.(*repoSync).Run((*main.repoSync)(0xc000099040), context.Context(*context.timerCtx) 0xbeef000000000108, "", []string len: 4, cap: 4, [...])
2023-11-27T14:56:54.3420434-08:00 > goroutine(1): [k8s.io/git-sync/pkg/cmd.Runner.WithCallDepth(k8s.io/git-sync/pkg/cmd.Runner](http://k8s.io/git-sync/pkg/cmd.Runner.WithCallDepth%28k8s.io/git-sync/pkg/cmd.Runner) {log: [k8s.io/git-sync/pkg/cmd.logintf(*k8s.io/git-sync/pkg/logging.Logger)](http://k8s.io/git-sync/pkg/cmd.logintf%28*k8s.io/git-sync/pkg/logging.Logger%29) ...}, 1)

[thockin]

In particular, that []string is pretty important:)

[aarzilli]

The trace subcommand can't do that, however the trace cli command creates a tracepoint that can be manipulated using the on command to print extra variables.

[thockin]

Should the trace command have some way to do this? Without the arguments, tracing function calls is a lot less helpful.

I am not sure exactly how one would express this, but... something?

[aarzilli]

Without the arguments, tracing function calls is a lot less helpful.

It does print arguments, but to a limited extent.

I am not sure exactly how one would express this, but... something?

Neither am I.

I don't think just changing the variable depth would be useful, because it applies to everything and it would probably be too noisy and make the trace unreadable. If you make the configuration more fine grained eventually you will get something like the cli command trace (but that already exists).

[hitzhangjie]

@thockin @aarzilli Even though the arguments isn't printed, it's still useful.

For example, we want to do some service load testing:

1. normally, the RPC timecost reported by the microservice framework is enough, but sometimes not.
   • the timecost maybe reported by time.Duration metrics or time.Duration in Tracing span.
   • or logged in the logging file Maybe the reporting, logging logic is both disabled to avoid the pressure. Maybe the opentelemetry backend is not so good to visualize the tracing and span.
2. maybe we know specific RPC process has bottleneck, for example, a function call (not an RPC call to callee), but we don't want to create span using golang runtime/trace package mannually, so profiling can't help neither.
3. What's the worst, we know there's some bottleneck, but we don't know which function call causes it. And we don't want to change code to add logging. Mabye the CI/CD system is too time-consuming, we don't want to wait it ready ... maybe we repeat this multpile times. ... Well, I need a tracing tool to report which function is called and how long it takes. And the tracing shouldn't add evident timecost to the target process. This occassion, we don't care if the parameters printed or not. see also: hitzhangjie/go-ftrace and jschwinger233/gofuncgraph, it uses ebpf-based solution just like dlv trace.

• If we don't want to affect the performance, we should use ebpf-based solution. We can still print the arguments with limititation, such as we don't dereference the struct fields to avoid more PTRACE_PEEKDATA...
• If we don't care the performance sideeffect, we can use the breakpoint-based solution, and add a little code to print the arguments in detail. But as aarzilli mentioned, trace <id> and on <id> print <args> can do this.

That's my understanding.