Comments (12)
The generated source can be perhaps kept under $GOPATH/godebug/$IMPORT/PATH
? This will allow to just scan directory for changes against the counterparts under $GOPATH/godebug and only regenerate source if you must, of course, this means some changes to the import path of projects though.
What do you think?
from godebug.
That's a nice idea. I had been working on a version that throws away the generated code every time, but I think something like this can work.
We can do it without rewriting import paths, too. $GOPATH
can point to multiple directories. We can have a special godebug
directory that contains generated source in godebug/src
and compiled versions in godebug/pkg
. Then when the user runs godebug <run | test | build>
, we can set GOPATH=<godebug-dir>:$GOPATH
in the environment for the go
command and it will use the debug-instrumented packages instead of the normal ones. This avoids both regenerating and recompiling code for packages that haven't changed.
I want godebug to support instrumenting a subset of the packages in the program, though, and that subset can be different each time the user runs the command. So I want the go
command to ignore any packages in the godebug
directory that the user has not chosen to instrument for this run. My proposal for that is to recursively hide all of the subdirectories of the godebug
directory, probably by prepending '.' to their names, and then temporarily unhiding the directories we want to instrument just before running the go
command.
A downside of my proposal is that concurrent runs of the godebug tool will interfere with each other. One workaround for that is to have godebug check a lock file on startup, and if it finds another instance running it does all of its work in a new temporary directory.
from godebug.
I like the idea of multi GOPATH better.
The issue of concurrency can be mitigated with having a GOPATH per project under godebug
with packages selected for instrumentation linked from the godebug/{src,pkg}
from godebug.
How ever you do it, I would make it really easy to know, in fact it should be blindingly obvious, if a binary contains any debug information from godebug at all.
You don't want to accidentally release a build with debug info in it. Both for security and for performance.
from godebug.
@glycerine good point. I thought about this a bit and have two proposals:
godebug build
always outputs a binary file that ends in ".godebug"- The godebug library has an
init()
function that prints a prompt and waits for confirmation before continuing. This prompt is disabled for anygodebug test
andgodebug run
commands that do not produce binaries. Example prompt is something like:
Welcome to godebug!
For help, type "help". To run the program until the first breakpoint, type "run".
(godebug) _
If stdin is closed, the program is halted.
Thoughts?
from godebug.
@omeid that's a good idea. A downside of GOPATH directory per package is that it results in a quadratic search for packages. For example, if a build transitively includes 100 packages and all of them are godebug-enabled, then the go
tool will do 100 package lookups that each check on average 50 directories.
But even for 100 packages this isn't much work. It would take thousands of packages, all instrumented in the same build, for this to become a problem. That seems unrealistic for now.
from godebug.
Another factor worth noting: the go
tool supports packages outside of the GOPATH workspace. It would be nice for godebug to support them, too. I think we should use temporary directories for that case.
from godebug.
@jeremyschlatter I don't see how you would be looking up more than one directory, you keep the instrumented source in godebug/src
and only symlink them to the required projects. This way there will be only one instrumented source of every project at a time.
from godebug.
@omeid ah, I think I misunderstood your suggestion. Is this what you are envisioning?
my-real-gopath/
src/
pkg1/
pkg2/
pkg3/
pkg/
pkg1.a
pkg2.a
pkg3.a
godebug/
src/
pkg1/
pkg2/
pkg3/
pkg/
pkg1.a
pkg2.a
pkg3.a
tmp/
synthesized-gopath-1/
src/
pkg2/ <- symlink to godebug/src/pkg2
pkg3/ <- symlink to godebug/src/pkg3
pkg/
pkg2.a <- symlink to godebug/pkg/pkg2.a
pkg3.a <- symlink to godebug/pkg/pkg3.a
synthesized-gopath-2/
src/
pkg3/ <- symlink to godebug/src/pkg3
pkg/
pkg3.a <- symlink to godebug/pkg/pkg3.a
Each time godebug runs it generates a temporary GOPATH directory that contains symlinks to only the packages that we want to instrument, then prepends that directory to the user's GOPATH. The go
tool does at most one extra lookup for each package.
^ This is cleaner than what I was thinking. Is this the same thing you were imagining?
from godebug.
Yup, that is exactly what I meant by having a GOPATH per project under godebug with packages selected for instrumentation linked from the godebug/{src,pkg}.
from godebug.
@jeremyschlatter Sounds good--together those two precautions should catch most unintended debug -compiles.
from godebug.
godebug run
and godebug test
have now been implemented, using temporary directories for now.
from godebug.
Related Issues (20)
- Does it work on Windows? HOT 4
- Feature Request: Auto-print after breakpoint HOT 1
- Windows binaries lack .exe extension
- Functions defined as part of an array or slice literal are not instrumented
- Can't convert variables to other types to inspect with print command HOT 2
- --ldflags is not supported HOT 1
- godebug not found HOT 2
- Auto instrument packages with breakpoints
- Can't get `godebug test` to work on Terraform codebase
- Doesn't handle bad recover usage
- Godebug does not work with vendoring HOT 5
- syntax highlighting
- search package only in base gopath HOT 3
- Website not updated
- cannot find package "golang_org/x/net/route" HOT 1
- godebug does not work with code that imports net/http (since go 1.6) HOT 10
- godebug fails after addition of net/http package HOT 1
- cgdb like TUI for godebug.
- So what's the deal? HOT 3
- question a bout debuger HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from godebug.