oold_le

Forum Replies Created

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • oold_le
    Participant

    Hi,

    I forgot to fill in the “target selection command”. Starting GDB and connecting works now.

    I’ll probably bundle a tool to be run before debugging and would like to know whether it’s possible to reference the path to the command via a registry value. Regular MSBuild projects allow grabbing values from the registry via “$(registry:…)”. Is that also possible in VisualGDB projects?

    oold_le
    Participant

    Hello,

    I have built a tool that takes care of uploading the file via FTP. The tool is launched via custom debug steps, followed by running a command that takes care of setting the executable permission on the file.

    For some reason, after modifying the gdbserver command in the VisualGDB properties, VisualGDB tries to debug locally with GDB, but still launched the gdbserver.

    The problem with gdbserver demanding the IP address before the port number also seems to stem from failed name resolution. It seems just the port number would work in general, but our system’s name resolution mechanism is broken.

    Also, VisualGDB detected the gdbserver not being able to bind to the port because a previous instance was still running and offered to kill it. That failed because it tried to run “killall -v gdbserver” and our killall responded with “killall: bad signal name ‘v'”. I guess I’ll just run “killall gdbserver” as pre-debug step before each session.

    in reply to: Observations when evaluating VisualGDB for our environment #36472
    oold_le
    Participant

    I can confirm that #1 and #4 are fixed now. Thank you very much!

    We will probably implement the transport for the problematic target via the plugin solution. Is it possible to only implement the file transfer that way and fall back to the default implementation for running commands on the target system? It looks to me like the access violation is only triggered by the file transfer.

    Another more or less minor issue for our workflow I’ve noticed is the debug target being configured for all project configurations. We have separate configurations for different target systems and it would be preferrable if we could save different sets of debug settings that are automatically selected via the chosen project configuration.

Viewing 3 posts - 1 through 3 (of 3 total)