CODEWITHSUNDEEP
windowslinuxgdbeclipse-cdtgdbserver
rewbs
rewbs

Reputation: 1990

Remotely debugging a Linux process from Windows with gdb and gdbserver: what exactly is needed on the Windows side?

I am running Eclipse CDT on Windows to develop C code that is built & tested on remote Linux systems. Currently, the code is never compiled on Windows.

I am able to use CDT to begin the remote process on the Linux target under gdbserver, and then attach gdb from the Windows host. However, gdb immediately fails with errors like:

warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB.  Attempting to continue with the default i386 settings.
[...]
Remote 'g' packet reply is too long: 74afe9bff0aee9bf02000000f4af4a00a0aee9bf[...]

Debugging between two Linux systems works fine, so it's clear that I'm doing something wrong on the Windows host side. My specific questions are:

Thanks,

-R

More info: The RSE FAQ provides some pointers, but unfortunately I'm still blocked. The FAQ describes two approaches:

I have also raised this issue on the CDT forum.

Upvotes: 26

Views: 21528

Answers (7)

Massimo Sbano
Massimo Sbano

Reputation: 1

I solved the issue by installing gdb-multiarch on Cygwin. This version of GDB supports debugging across multiple architectures. It runs well on any architecture that is supported by gdb-multiarch (as listed below).

To see the architectures supported by gdb-multiarch, use the set architecture command without any arguments.

This will display a list of supported architectures. You can then choose the appropriate one for your debugging needs.

To install gdb-multiarch on Cygwin, use the Cygwin setup installer, search for gdb-multiarch in the package list, and install it. For more information about gdb-multiarch, refer to the official GDB documentation.

Upvotes: 0

tutejszy
tutejszy

Reputation: 642

I failed to build on Windows, but found quite easy building it under Linux. To summarize and complete @Eugene response: First, prepare sources:

wget http://ftp.gnu.org/gnu/gdb/gdb-<ver>.tar.xz
tar -xJvf gdb-<ver>.tar.xz
mkdir -p gdb-<ver>/build/x86_64-redhat-linux-gnu
cd gdb-<ver>/build/x86_64-redhat-linux-gnu

Download Windows compiler:

sudo apt-get install mingw-w64

Check out the target configuration platform you want to debug your binaries (what to put in --target parameter):

echo ${BASH_VERSINFO[5]}

Prepare makefiles targeted for your desired platform but running on different host. We compiling it static so that it doesn't depend on any DLLs or other libraries. Also we disabling building other binaries as gdb wiki suggests: 

../../configure --host=x86_64-w64-mingw32 --target=x86_64-pc-linux-gnu --enable-static=yes --disable-interprocess-agent --disable-binutils --disable-ld --disable-gold --disable-gas --disable-sim --disable-gprof

finally, build (takes like 30-60 min):

make LDFLAGS=-static

You can find your debugger in gdb folder. It is also good to strip it of debugging symbols as after building executable is huge:

strip -s gdb/gdb.exe

Voila! gdb.exe ready to run in Windows and remotely debug Linux executables!

Upvotes: 5

Martin
Martin

Reputation: 3602

Software development is generally much easier on linux than it is on windows. But that's off topic.

What is important when you debug cross compiled binaries is that you use gdb from cross compiler - not host gdb. You can not for example use gdb built for windows to debug a linux process (well you can but it is not recommended). You need to use the cross compiler gdb to debug the remote process (which is part of the same toolchain that was used to build the binary). As you are saying that you never compile on windows, I'm pretty certain this could be your problem. The easiest way for you to get it working is to just use the gdb from command line on the remote machine, where you compile, and do your debugging over ssh.

Upvotes: 0

Eugene Weiss
Eugene Weiss

Reputation: 101

Just rebuild gdb with target platform supporting. You can use Cygwin for this. Example for RHEL target platform:

> wget http://ftp.gnu.org/gnu/gdb/gdb-<ver>.tar.xz
> tar -xJvf gdb-<ver>.tar.xz
> mkdir -p gdb-<ver>/build/x86_64-redhat-linux-gnu
> cd gdb-<ver>/build/x86_64-redhat-linux-gnu
> ../../configure --target=x86_64-redhat-linux-gnu
> make && make install
> x86_64-redhat-linux-gnu-gdb.exe --version

Don't forget to reconfigure your toolchain after this. To obtain the target configuration name, you can use:

> echo ${BASH_VERSINFO[5]}

Upvotes: 10

TheRealOrange
TheRealOrange

Reputation: 115

Visual Studio Community Edition 2017 features GDB cross-compiling and debugging tools. Couple this with a Linux server or the Windows Linux sub-system and you can reliably develop C code for Linux systems. check out this guide.

Upvotes: 1

Mohamed Abdelazim
Mohamed Abdelazim

Reputation: 69

Now there is a plugin http://marketplace.eclipse.org/content/direct-remote-c-debugging

Which allows you to launch gdb on the server remotely over ssh. It takes care about path mapping and others things.

You don't need gdb server to be running remotely

Upvotes: 5

bmargulies
bmargulies

Reputation: 100161

Setting up a cross-compile or cross-debug environment with gcc/gdb is a very difficult problem, and it's almost never the most efficient solution. Putting a linux VM on your windows box, and debugging there, will be much less work. If you need, really, to debug 'over there', I'd suggest just ssh-ing and using command-line gdb. If you can't have source over there, remote-debugging from a linux VM under your control would be practical.

Upvotes: 1

Related Questions