Explore better starting points for debugged process

[derekparker]

trafficstars

Currently, we stop the process as soon as it is execed, so it really isn't anywhere useful. The reason we do not continue directly to main.main is because that would skip package init functions, which users may want to debug. Possible solutions include:

1. Continue directly to main.main, but optionally provide a flag to prevent this
2. Continue directly to runtime.main which would not be user code, but should (iirc) be before any package initialization, and would provide useful feedback when executing commands in the debugger.
3. Do nothing, and either print a startup message telling user to set a breakpoint, or otherwise consider it a documentation problem instead of a software one.

I'm open to suggestions, I want whatever ultimately makes the user experience better.

[jussij]

Speaking as a Windows user, my preference would be for the the debugger to stop on main.main entry point, only because this mimics how the Visual Studio debugger works.

However, to also let developers debug the earlier startup process, as I would expect the debugger to stop on any breakpoints set in that startup code (once again mimicking how the Visual Studio debugger works).

Using this approach, it should still be fairly easy for developers wanting debug the startup process, as they would have access to the stack as soon as the main.main point is hit:

stack
0  0x0000000000401240 in main.main
   at C:/Go/src/github.com/jussij/DelveTest/main.go:15
1  0x000000000042b669 in runtime.main
   at c:/go/src/runtime/proc.go:111
2  0x0000000000456610 in runtime.goexit
   at c:/go/src/runtime/asm_amd64.s:1721

They could use that stack information to navigate back into the startup code, looking for a place to put a breakpoint.

[derekparker]

@jussij that seems reasonable to me, overall. Default to stopping at main, if you want to checkout an init function or something, then you can set a breakpoint there.

[jussij]

I tried out this auto-advance change on Windows 10 and it is working perfectly. Great stuff :)

[aarzilli]

I think at this point the ship has sailed, the current behavior has existed for too long and thus we should not auto-advance to main.main, or runtime.main or anything else. I think we should close this.

[hick]

most Go programmers pay more attention for the Go code written by themselves indeed.

BUT some Go programmers concern on something deeper like Go runtime, especially for those want to inspect Go under the hood , like the Go contributors, or someone want to be a Go contributor.

how about add a config parameter to show more choices?

or maybe the third way is good and convinient for both the delve developers and the delve users, now I did not find a dlv way to get thr program entry point liek "info files" in gdb, maybe I can use " readelf -s a_go_bin | grep _rt0_amd64_linux" to find it, comparing gdb's output of info files:

or add sub-command like "config entry" to display or switch the stop point, may be delve can notice the startup message:

vagrant@u20-ehick:/data/hick/go/my/dlvme$ dlv debug dlvme
Type 'help' for list of commands.

change like this

vagrant@u20-ehick:/data/hick/go/my/dlvme$ dlv debug dlvme
Type 'help' for list of commands,   'config entry' for deeper stop point

or "'config entry' for deeper stop point" just in the context of 'help' message

thanks for your works for such a good debug tool for Go :)

[thockin]

I'd like to see a commandline flag to set initial breakpoints. E.g. I know I want to stop at foo.Bar - load and run to that point. It's a small convenience.

[derekparker]

I'd like to see a commandline flag to set initial breakpoints. E.g. I know I want to stop at foo.Bar - load and run to that point. It's a small convenience.

You can already do this today via the --init flag. Point that at a text file containing Delve commands you'd like to execute when the session starts up.

[thockin]

Oh nice. Can it be done without a file?

On Wed, Jan 5, 2022, 7:08 AM Derek Parker @.***> wrote:

I'd like to see a commandline flag to set initial breakpoints. E.g. I know I want to stop at foo.Bar - load and run to that point. It's a small convenience.

You can already do this today via the --init flag. Point that at a text file containing Delve commands you'd like to execute when the session starts up.

— Reply to this email directly, view it on GitHub https://github.com/go-delve/delve/issues/374#issuecomment-1005767480, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKWAVGDV54OUIBRL5RIIIDUURNGBANCNFSM4BZTBDZA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[aarzilli]

Oh nice. Can it be done without a file?

--init <(echo ...)

[thockin]

indeed, that solves the need I had :)

[aarzilli]

Closing this, at this point doing extra stuff after startup would be too much of a backwards incompatible change.