Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

support stepping into the standard libarary #12

Open
jeremyschlatter opened this issue Apr 4, 2015 · 8 comments
Open

support stepping into the standard libarary #12

jeremyschlatter opened this issue Apr 4, 2015 · 8 comments

Comments

@jeremyschlatter
Copy link
Contributor

godebug's current procedure for running instrumented code for a package x is:

  • make a temp directory
  • make a subdirectory $TMP/src/x containing instrumented versions of the source files for x
  • run the go command, setting GOPATH=$TMP:$GOPATH. The go command finds our instrumented packages in $TMP/src and finds any other un-instrumented packages in the normal GOPATH.

That process does not work for standard library packages, though, because $GOROOT has to be a single directory.

Here's my current plan for working around this:

  • Implement the proposal from UX improvement: godebug <run, test, build> #8 of having a permanent godebug directory that contains instrumented versions of all the packages we have seen so far. Put standard library packages in the same place, or possibly in their own /goroot or /std directory.
  • From the same proposal, generate a temporary directory for every invocation of godebug and fill it with symlinks to the packages we want to instrument. The only new thing is that for all standard library packages we don't want to instrument, we will need to add a symlink to the real package in $GOROOT.
@pwaller
Copy link

pwaller commented May 8, 2015

Along these lines, I need to place a breakpoint in the standard library. I'm currently hitting net/http.ErrBodyReadAfterClose, and it's very difficult to tell why, so I want to set breakpoints in bufio and net/http, which I take it isn't possible or easy right now.

@jeffallen
Copy link
Contributor

I just hit this problem, and I wasted a significant amount of time on it. :(

@jeremyschlatter
Copy link
Contributor Author

@jeffallen sorry to hear that :( Is there some UX change we could make that would at least make it more obvious what was going on?

@jeffallen
Copy link
Contributor

Well, it would be awesone if right before you stepped into non insrumented code it told you. Don't know if this is possible without too much overhead...

@jeremyschlatter
Copy link
Contributor Author

Here's one idea: when the user runs "step", parse the next line and see if it contains a function call. Then run as normal until we hit the next godebug.Line call. If that call is in the same function as before -- we had no intervening godebug.EnterFunc or godebug.ExitFunc calls -- and we saw a function call in the code for the previous line, report to the user that it stepped over a function call, probably because the function was not instrumented.

@jeffallen
Copy link
Contributor

+1
On Jun 21, 2015 7:24 AM, "Jeremy Schlatter" notifications@github.com
wrote:

Here's one idea: when the user runs "step", parse the next line and see if
it contains a function call. Then run as normal until we hit the next
godebug.Line call. If that call is in the same function as before -- we
had no intervening godebug.EnterFunc or godebug.ExitFunc calls -- and we
saw a function call in the code for the previous line, report to the user
that it stepped over a function call, probably because the function was not
instrumented.


Reply to this email directly or view it on GitHub
#12 (comment).

@andradei
Copy link

👍 Oh how much I wish for the std lib support

@doublerebel
Copy link

👍

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants