Reply to topic

KDevelop remote building and debugging

User avatar massimob
Registered Member
Posts
3
Karma
0
Having a target reference machine with a custom make and fixed toolchain, I would like to build and debug via remote access instead of cloning the toolchain locally. Having the same compiler locally that would still not be the exact environment like the reference system.

However for having the latest KDevelop on a recent DE I'd like to run KDevelop locally.

C++ sources are available on both sides via NFS.

The remote building I got working by Project->Custom BuildSystem: Action "Build, Executable "~/bin/remote_build", Arguments "/mnt/nfs/workspace/foo".

~/bin/remote_build
Code: Select all
#!/usr/bin/env bash
LOCATION=${1:-/mnt/nfs/workspace/foo}
ssh -q target-srv << EOF
cd $LOCATION
custom_make all
EOF


However using gdb for remote debugging doesn't work as expected. There would be 2 approaches. One is the KDevelop-official way by using gdbserver on the target. The other approach would be to control a gdb session inside a ssh session.

Trying the gdbserver approach:
Run->Configure Launches->Add New->Compiled Binary->Debug: Debugger executable "", Shell script "", Gdb config script "~/gdb/foo_config", Run shell script "~/bin/remote_gdbserver", Run gdb script "~/gdb/script".

~/gdb/foo_config
Code: Select all
file /opt/bin/foo


~/bin/remote_gdbserver
Starting the remote gdbserver
Code: Select all
#!/usr/bin/env bash
server="target-srv"
target="foo"
ssh "$server" "gdbserver --remote-debug --attach localhost:8888 \$(pgrep -fo $target)"


~/gdb/script
Connecting the gdb client to the gdbserver
Code: Select all
shell sleep 2
target remote target-srv:8888


This does attach successfully to the process, but after continue the connection is lost. I was able to reproduce that with a gdb session. CTRL+C does not pause after continue and in the next step does close the connection.
I tried all combinations of
Code: Select all
(gdb) handle SIGINT stop noprint nopass
but I can't get gdb paused which KDevelop requires for adding new breakpoints for instance. A local gdb on the target server works fine. I was also able to remote debug some other process with the same gdb and the pause was working. Only the combination of my own process and the gdbserver is not able to get paused:
Code: Select all
server $ gdbserver --multi --attach localhost:8888 $(pgrep -f my_app)

client $ gdb
target extended-remote localhost:8888
Remote debugging using localhost:8888
Reading /lib64/libdl.so.2 from remote target...
Reading /lib64/libSegFault.so from remote target...
...
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
0x00007f6b26857923 in __select_nocancel () from target:/lib64/libc.so.6
(gdb) where
#0  0x00007f6b26857923 in __select_nocancel () from target:/lib64/libc.so.6
...
#9  0x00000000004497ee in main (argc=14, argv=0x7ffe8e4b0af8) at main.cpp:245

(gdb) c
Continuing.

^C^CThe target is not responding to interrupt requests.
Stop debugging it? (y or n) y
Disconnected from target.

Last edited by massimob on Thu Mar 16, 2017 12:27 pm, edited 2 times in total.
User avatar massimob
Registered Member
Posts
3
Karma
0

Re: Remote building and debugging

Thu Mar 02, 2017 3:05 pm
Going to try approach nr. 2: Using gdb inside an ssh session:

Run->Configure Launches->New Compiled Binary Launcher->Debug: Debugger executable "", Shell script "~/bin/remote_debug".

~/bin/remote_debug
Going to drop the ${@:2} parameter as KDevelop is passing the gdb command to the script:
Code: Select all
#!/usr/bin/env bash
server="target-srv"
target="foo"
ssh "$server" "gdb ${@:2} $target \$(pgrep -fo $target)"


It seems that KDevelop is starting the ssh-Session but trying to read some version, while gdb is already attaching and starting:
You need gdb 7.0.0 or higher
You are using: Reading symbols from foo...

So using this approach with a script starting gdb inside ssh is even worse as I can't pass it an gdb script for attaching to the process...

Any idea?
User avatar massimob
Registered Member
Posts
3
Karma
0

Re: Remote building and debugging

Tue Mar 14, 2017 3:14 pm
As KDevelop seems to parse a plain starting gdb without attaching at once, I replaced the gdb line in the script with
Code: Select all
ssh "$server" "gdb ${@:2}"

But now it fails with starting the executable.
Ok, looking at Launch Configurations->Global->NewCompiledBinaryLauncher->Executable, it seems to require one. What should I do if I don't need to start an executable but only need to start a gdb attaching to a remote one? I tried passing a dummy script that does nothing but echo, but KDevelop even fails to run this, eventhough it exists locally:
Code: Select all
Could not start debugger:
/home/mb/dummy: No such file or directory.
crunch
Registered Member
Posts
1
Karma
0

gdb doesn't break at breakpoints

Wed Jun 21, 2017 7:37 pm
I haven't gone to the command level as massimob does - I've been running gdb from the kdevelop GUI which I started in an SSH Mobaxterm (on a Windows 10 machine) connected to a (Fedora 25) machine where the source and executable reside. In my case, breakpoints don't stop execution - maybe the response time from the presentation host is more than a programmed wait time? Or am I missing a configuration param somewhere?

 
Reply to topic

Bookmarks



Who is online

Registered users: arkascha, Baidu [Spider], Bing [Bot], egor, gfielding, Google [Bot], minson, naturepi, nicolaf, nlutterman, rblackwell, Section_8, Sogou [Bot]