Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Boran Car
    @borancar
    Hey guys, sorry if this question has been asked before. I am using https://please.build/ (similar to and inspired by Bazel) to build Golang programs. please likes to put relative paths from the repo root to the source files in the DWARF information and I have not seen a way to override this behavior. I am trying to debug using GoLand's external connection, but when setting breakpoints, GoLand will give the absolute path from the root of the filesystem (/) (following https://github.com/derekparker/delve/blob/master/Documentation/api/ClientHowto.md#using-rpcservercreatebreakpoint) and dlv will reject it because the DWARF information contains only relative paths to repo root. Since I haven't seen an option to modify what GoLand gives, I was thinking along the lines of a delve override inside the RPCServer - is such an approach OK or is there something I'm fundamentally missing?
    Alessandro Arzilli
    @aarzilli
    I'd like to see what the DWARF inside those executables looks like
    Boran Car
    @borancar

    here's a sample (I'm assuming you want readelf --debug-dump=decodedline | grep CU::

    CU: woz_tv/db/db.go:
    CU: woz_tv/db/product/product.go:

    When GoLand contacts via the RPC, it asks for
    /home/boran/git/project/woz_tv/db/db.go

    And these result in location not found

    (again, I'm unable to use idiomatic go folder structure due to a hard constraint)

    If I modify service/rpc2/server.go, func (s *RPCServer) CreateBreakpoint(arg CreateBreakpointIn, out *CreateBreakpointOut) error { to actually strip the /home/boran/git/project/, it works
    Alessandro Arzilli
    @aarzilli
    I'm not convinced that delve is the right place to handle this, IMHO delve is doing what the DWARF is saying, IMHO the problem is that your IDE doesn't understand your build system
    Boran Car
    @borancar
    I totally agree with this. Note that however, the easier solution for me is to have delve locally supporting workarounds (nothing new regarding workarounds in the software world, right?). The question is what is the stance on delve and workarounds?
    Boran Car
    @borancar
    The proposed workaround here would be for delve to trim the working directory from the location it receives via RPC if a certain flag is passed or config parameter set.
    Alessandro Arzilli
    @aarzilli
    the problem with including this workaround is that it needs configuration and at the moment a headless instance of delve doesn't read any configuration
    Boran Car
    @borancar
    could technically be a CLI argument, but ignoring the work that needs to be done (and that I would happily take), would this stand ground as a request and a PR from an ideological perspective?
    Alessandro Arzilli
    @aarzilli
    Definitely not in rpc2/server.go, maybe in debugger.go. I'd vote against it, you'd have to convince Derek.
    Boran Car
    @borancar
    Gotcha, thanks!
    Alessandro Arzilli
    @aarzilli
    the thing is that we already have a mechanism to mess with file paths, but it operates client-side instead of server-side
    therealssj
    @therealssj
    hello :)
    I was looking at the cli commands and dont you guys think that its a bit clustered having all the definitions in a single file https://github.com/derekparker/delve/blob/master/cmd/dlv/cmds/commands.go
    can I directly send a PR for a little cleanup proposal?
    split up the commands into separate files etc
    Omkarnath
    @Omie
    Hi, I got back to work on #1256 ( derekparker/delve#1256 ). Equivalent of display command of gdb. I looked at similar implementation of commands and wanted to confirm if I am on right track for this feature
    Seems like I have to add core functionality in proc/native/proc.go just like breakpoints' has. and keep map/list of display expressions and then expose the functionality through multiple layers viz, service/debugger/debugger.go, service/rpc2/server. service/rpc2/client, service/client.go (interface), and pkg/terminal/command.go
    • some In and Out types for client server, + required types in service/api/types etc
    I suppose this is how it should be implemented, hence any client will be able to consume the functionality
    Omkarnath
    @Omie
    I wanted to quickly confirm the approach
    Alessandro Arzilli
    @aarzilli
    @Omie: I really don't think you need to add things to proc.go, I'm pretty sure it can be done entirely in command.go, just keep a list of variables there and evaluate it when continue/next/step/stepout finishes
    Omkarnath
    @Omie
    @aarzilli thanks for getting back
    that means feature is limited to command client. Fine with it though, just making sure this is a conscious decision
    Alessandro Arzilli
    @aarzilli
    @Omie other clients have already implemented their own version of display, all they have to do is manage their own list of expressions, there isn't a big advantage to using a API to do it server side
    Omkarnath
    @Omie
    Fair, will do
    valentinewallace
    @valentinewallace
    Heya, I'm trying to use delve but getting "no source available" when i do dlv test -- -test.v and then list. and when i try to set breakpoints it says "location not found." any tips? thank you!
    valentinewallace
    @valentinewallace
    never mind, it "just works" if you use vscode
    u35tpus
    @u35tpus

    hi guys
    dlv is great thing.
    just one question.

    When I start dlv with my go binary, dlv hangs until I connect from debugger.
    dlv debug --listen=:40000 --log --log-output=/var/log/dlv.log --headless=true --api-version=2 cmd/pudge/pudge.go
    API server listening at: [::]:40000

    is there any way to let dlv just continue running until remote debugger connects?

    u35tpus
    @u35tpus
    oh. found it
    --accept-multiclient --continue
    onequid
    @onequid
    Hello guys. Found that quiting program executed with dlv exec will just kill the process without doing the "graceful shutdown" if there is. Is it designed so?
    It happens on my Linux machine.
    Alessandro Arzilli
    @aarzilli
    @OneQuid yes, the "graceful shutdown" is a result of your process receiving a SIGINT (probably) which delve doesn't send.
    onequid
    @onequid
    @aarzilli Thank you. However when dlv attach is used (probably with args --api-version=2 --accept-multiclient=true), the process would receive the sys Signals. Does it sound good that dlv exec and dlv debug(This would behave similar with dlv exec) would send sys signals as well?
    Seth Bromberger
    @sbromberger
    hi :)
    Sylvain Rabot
    @sylr
    Hi
    I am trying to tweak terraformto fork their plugin with delve in the to be able to debug the plugins
    It works but terraform is waiting for the plugin to output some json
    It seems that this json is intercepted by delve but not forwared to terraform
    because I see the json in my shell but terraform still hangs
    so I’m wondering what I have to do to make delve forward the stdout of the plugin to the father process
     | |   \-+= 22577 s.rabot -zsh
     | |     \-+= 57717 s.rabot terraform plan
     | |       \-+- 57719 s.rabot /Users/s.rabot/go/bin/dlv exec --headless --listen=127.0.0.1:2346 --api-version=2 --log-dest=/dev/console -- /Users/s.rabot/go/bin/terraform-provider-azurerm
     | |         \-+= 57720 s.rabot /Library/Developer/CommandLineTools/Library/PrivateFrameworks/LLDB.framework/Versions/A/Resources/debugserver --stdio-path /dev/tty -F -R 127.0.0.1:51650 -- /Users/s.rabot/go/bin/terraform-provider-azurerm
     | |           \--- 57721 s.rabot /Users/s.rabot/go/bin/terraform-provider-azurerm
    pablochacin
    @pablochacin
    Hi @sylr I'm now facing a similar issue. I need to debug a tf plugin. Would you mind to share how did you setup terraform to use launch delve instead of the plugin? As for the problem with returning the json, did you manage to solve it? Thanks in advance
    chainhelen
    @chainhelen
    @pablochacin go-delve/delve#1880
    pablochacin
    @pablochacin

    @pablochacin go-delve/delve#1880

    Thanks @chainhelen I'll keep a look at it.

    liangsj
    @liangsj
    i want to know how to use dlv connect
    when i run 'dlv attach $pid --headless --api-version=2 --log --listen=:8181' in romote
    and i run dlv connect $hostname:port in local
    when i use command list after breakpoint and continue. I cannot find my work
    iterm2 shows xx files not find