Currently there is a PR that adds a new option --follow-calls to trace the children of the function that matches the regular expression upto the desired depth being reviewed in here- https://github.com/go-delve/delve/pull/3594
As of now, it supports very limited tracing of defer calls such as deferreturns and if the function in which the defer closure is defined matches the regular expression it traces the deferred functions as well.
This is a follow up issue to the PR that adds complete support to trace defer calls.
The main challenge in here is that the defer call mechanics does not operate as the regular calls because the interplay between the registers and the stack comes into the picture in this case making it a more involved task to compute the function (address) that is deferred.
Some of the initial ideas are mentioned in https://github.com/go-delve/delve/pull/3594#discussion_r1619531496
This involves pattern recognition to catch places in the assembly where the deferred function address is being computed and loaded into the stack. And from there we can get the name of the function and add it to the trace list.
Since the assembly looks different on different architectures we will need to likewise parse the information differently depending on the architecture and glean the function address from that.
Currently there is a PR that adds a new option --follow-calls to trace the children of the function that matches the regular expression upto the desired depth being reviewed in here- https://github.com/go-delve/delve/pull/3594
As of now, it supports very limited tracing of defer calls such as deferreturns and if the function in which the defer closure is defined matches the regular expression it traces the deferred functions as well.
This is a follow up issue to the PR that adds complete support to trace defer calls.
The main challenge in here is that the defer call mechanics does not operate as the regular calls because the interplay between the registers and the stack comes into the picture in this case making it a more involved task to compute the function (address) that is deferred. Some of the initial ideas are mentioned in https://github.com/go-delve/delve/pull/3594#discussion_r1619531496 This involves pattern recognition to catch places in the assembly where the deferred function address is being computed and loaded into the stack. And from there we can get the name of the function and add it to the trace list. Since the assembly looks different on different architectures we will need to likewise parse the information differently depending on the architecture and glean the function address from that.