search

cs01 / gdbgui

Browser-based frontend to gdb (gnu debugger). Add breakpoints, view the stack, visualize data structures, and more in C, C++, Go, Rust, and Fortran. Run gdbgui from the terminal and a new tab will open in your browser.
https://gdbgui.com
GNU General Public License v3.0
9.9k stars 499 forks source link

Add support for remote debugging with long-living "gdbserver --multi" #330

Open berkakinci opened 4 years ago

berkakinci commented 4 years ago

Is your feature request related to a problem? Please describe. Remote debugging is almost necessary for working with targets of other architectures. When using gdbserver without "--multi" option, the binary can only be run once. This requires going back and forth to the target device console window to reset and rerun every time. Currently, when attempting to connect to "gdbserver --multi", there is an error in the gdb console. It suggests I use "extended-remote."

Describe the solution you'd like I would like to be able to "connect to gdbserver" that's running with "--multi" option, then select the remote executable. This would allow me to control the first run and parameters (hopefully) from within gdbgui. I could restart the executable and debug multiple times. All from within gdbgui.

Describe alternatives you've considered I currently work around this by entering a series of commands in the (gdb) console at the bottom of the web gui:

target extended-remote <ip>:<port>
file <binary_name>
set remote exec-file <binary_name>
break main
run <args>

From that point, everything in gdbgui seems to work normally. Essentially, this feature request is (at a minimum) automating these commands. If there was a way to do "browse for remote executables" etc, that would be great.

Additional context This is a snip of my current use case:

# On Target:
gdbserver --multi :<port>

# Invoke GDBGUI on dev server with cross-compile tools:
gdbgui --remote --gdb </path/to/arch-cross-gdb>

# On GDBGUI (gdb) prompt:
target extended-remote <ip>:<port>
file <binary_name>
set remote exec-file <binary_name>
break main
run <args>
GitMensch commented 2 years ago

I second this use case. Entering localhost:51235, then clicking on "Connect to gdbserver" results in

The target is not running (try extended-remote?)

Entering extended-remote localhost:51235, then clicking on "Connect to gdbserver" results in

extended-remote localhost:51235: No such file or directory.

Suggestion: Check if the first word is extended-remote and if it is execute the command prefixed with target, this would not blow the UI at all, but removes the manual attach in the gdb window

stefanct commented 10 months ago

This is literally the first thing I tried in gdbgui. :( The good thing is that you can do most/all of the workaround on the command line:

gdbgui -g "gdb-multiarch\
  -ex 'target extended-remote <ip>:<port>'\
  -ex 'set remote exec-file <remote-path to binary>'\
  -ex 'set substitute-path <map-this> <to-here>'"
  <binary path>