I am trying to do remote debugging in CDT Environment of Eclipse Juno on Windows 7, whereas the remote machine is running under Linux. So much to the general purpose, unfortunately the exact setting is much more complicated so that I have been struggling for over a week now with this issue and none of the solutions provided in search results is sufficient.
So, here is my exact setting (very sorry for that long text!):
I have a C++ application Y which I develop and build on machine A.
I move the .so file (debug build) to machine B, which is running under Linux. I do not have the source code available there.
I am not starting my application Y explicitely on machine B. There exists another application Z that is started first, then I trigger a specific function so that my application Y is loaded dynamically. Actually it is done from a database stored procedure, but I will leave out these details to avoid fully puzzling you...
I have my local machine C running under Windows from which I want to debug. I have a copy of Y's source code and executable there, but not from application Z.
I cannot change these settings.
Now, I have installed gdbserver (GNU gdbserver (GDB) SUSE (7.2-3.3)) on machine B, gdb on machine C - compiled it with matching target and host as found in common tutorials, the version output says the following:
GNU gdb (GDB) 7.6.50.20130508-cvs (cygwin-special)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-cygwin".
I installed the Eclipse plugin for running and debugging remote applications. I have set up everything as suggested in http://wiki.eclipse.org/CDT/User/FAQ#How_do_I_debug_a_remote_application.3F
When I now start my debugging session, gdbserver and application Z are successfully started on machine B from within Eclipse. I can also trigger my application Y by invoking the stored procedure. But the following problems and questions arise here:
When starting the debugger, it says:
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
Created trace state variable $trace_timestamp for target's variable 1.
I have read something about including shared libraries somewhere, but I did not fully understand what shared libraries are meant here. Maybe that issue is also related to the next point.
I do not know where to include my source code so that it is available for setting breakpoints etc. during the debugging session. Since I do not have an Eclipse project, I know I just need to include the path to it somewhere. I added the code's root folder to the debug configuration's source lookup path, but this does not seem to work.
In Eclipse's debug configuration, I enter the path to the C++ application I want to start. For the command on the remote machine, I need to enter application Z since I cannot start my application Y explicitely. So I entered my application Y's path in the field for my local C++ application. Is that correct?
When starting the debugging session and triggering my application Y from outside, nothing happens in the debugger. My application Y is running and delivers results, but I do not get anything in the debugger's console. I would like to set breakpoints, but since my source code is not found I do not know how...
I tried to do a gdb debugging directly on the remote machine (starting applicatioin Z, triggering application Y from outside) and tried to set breakpoints at specific functions from my application Y. But this did not work either. Nevertheless, I did not get the warning mentioned above.
So now I am stuck here and do not know what to do. I have read lots of threads and blogs, but none of them has such a specific setting as I have, so there is always missing some detail.
I really, really, really appreciate your help.
Instead of breakpoint, put sleep() somewhere in you code then attach it to GDB while it's sleeping.
Related
There is a bug that I would like to fix that only occurs on Windows Server without a GUI running. I have set up a Windows Server 2019 machine on Google Compute Engine that reproduces the bug, and would like to debug it.
Ideally, I would like to use gdb, but seeing as the program was built with Visual Studio 2019, gdb can't read the debugging symbols.
I don't have a Windows machine, so using Visual Studio will be difficult. I could set up a VM, but if there's an in-terminal way to do this that would be preferred.
I did a pretty thorough Google search, but it didn't turn up anything. Is there really no Windows solution for debugging C++ code headlessly?
MS has 2 console debuggers called CDB and NTSD so you don't actually need Visual Studio GUI to do the debugging. In fact there are a lot of debugging environments in Windows from MS beside the usual Visual Studio. Just install them in your Windows Server and control them remotely from your terminal
You can also debug MSVC-compiled code with LLDB since the PDB format has been published long time ago and LLVM on Windows does support it. No idea about current LLDB on Linux though
And since you have the source code, sometimes the old-school printf debugger is the best way to analyze the issue
If you can get a Windows VM it'll be much better to do remote debugging. In fact almost all debuggers support that feature including GDB or LLDB, so even if you don't have the source code you can still run any Windows debugger and step through the instructions instead of high-level code lines from a remote machine
An alternative way is to take a memory dump and debug later. After getting the dump file, just drag it into your VS solution or any debugging tool like WinDbg and then select "Start Debugging". Now you can step through instructions/code lines and examine variables' values, or jump to an arbitrary function's stack frame just as if you're really running the malfunctioning app
There are many ways to dump a process' memory. You can set Windows to automatically save a dump file when your app crashes, or just capture memory snapshots manually during runtime. Comparing 2 snapshots is also useful for detecting leaked memory. For more information on how to do that read
Collecting User-Mode Dumps
Steps to Catch a Simple “Crash Dump” of a Crashing Process
There's also an easy way to take a dump of a live process using task manager (or any other similar tools)
I want to setup the following environment: I've got a STM32H753I-EVAL2 eval board, connected on a Windows PC. Until now I was developping and debugging locally on this PC with STM32CubeIDE. For several reasons my code source is on a Linux server (Samba mounting) so it takes forever to build a project. Hence I want to develop on the linux server from my Windows machine.
Compiling is working fine (and is way faster) but the issue is about debugging. I know it is possible to debug remotely, the Debug Configuration window from Eclipse (I'm using OpenOcd) allows to connect to a remote GDB server. What I don't know is how to start a GDB server on the Windows machine that will connect to the STM32 board ?
Sorry for the "answer to myself" but I think it might be useful for others (and even to me when I have forgotten in a few weeks ;) ).
Here is how to do.
on host side (on the machine where the eval board is physically plugged in) you have to manually launch the GDB server application that comes with STM32CubeIDE installation. See STMicro application note UM2576 for details. The default command line is:
ST-LINK_gdbserver.exe -d -v -cp "C:\ST\STM32CubeIDE_1.0.0.19w12patch\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.0.0.201903011553\tools\bin"
Now you've done the hardest. On server/remote side you have to setup the Debug Configuration to use OpenOcd with option "Connect to remote GDB server" and simply enter IP address and port number (which is not 3333 by default but 61234, but it can be modified).
This setup is working fine, even if I encoutered some instabilities during debugging once in a while.
I see two (maybe three) options
Use an alternate GDB server (see below)
Run the GDB server from STMCubeIDE in isolation (see OP's answer for Windows, this answer for Linux)
GDB Serial (not really an option right now but I'll share my experience so far)
I have used the second option to succesfully debug my target using arbitary GDBs such as gdb-multiarch command line and in the (non STMCube-ified) Eclipse CDT
Alternative GDB Servers
You could try STLink open source. I did. The problem is, your device might not be supported properly. I built 1.6.1 from Github to enable support for STM32G03x device. While moving to this version enabled it to detect the device, and I can use st-flash to program the device, the debugger is unusable (try and alter a register, it alters the wrong one, try and single step a program, it crashes immediately).
Do try it though .. it's easy and quick to install (or build), so it's worth checking if your device will work correctly with it.
Openocd is another option, but seems not to support SWD connection. I tried a build that allegedly had a patch for this but no luck.
If you can get one of these open source alternatives to work, they have another advantage, you may be able run them on something like a Raspberry PI, which means you don't have to get a PC physically close to your target.
Run the GDB server from STMCubeIDE in isolation
For Windows, see the OP's answer. For Linux, I do this alter the pathnames to suit your installation
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/native/linux_x64/ /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/ST-LINK_gdbserver -p 61234 -l 1 -d -s -cp /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.linux64_1.5.0.202011040924/tools/bin -m 0 -k
How did I get to this? Firstly launched a debugging session from STMCubeIDE, then ran
ps aux | grep gdbserver
Then we can see how Eclipse (STMCube) is launching the gdbserver and work from there.
If you find it complains about a .so file, locate that file from the STMCube installation and ensure the path to the directory containing it is in LD_LIBRARY_PATH (as per my example)
You can also launch the program with --help to show more options.
If add -e (persistent) you can disconnect and reconnect a GDB client without resetting the target (it will reset on initial invocation of the gdb server though, even without -k).
GDB Serial
This is where the target implements the GDB server end of the protocol. The GDB stub usually runs in an exception handler. This would usually be your breakpoint handler but you can also make it the default handler for unhandled exceptions, or, for example, the ctrl-c interrupt.
I have done a lot of Googling about this recently and basically when people ask about it on forums they usually get responses along the lines of "Here be dragons" or "Why don't you use JTAG?"
So the drivers for this, you might like to know, are in the GDB sources git://sourceware.org/git/binutils-gdb.git under gdb/stubs. The documentation is here. There isn't a stub implementation there for arm. Which is sad really, I used to use GDB remote serial regularly where I worked, and some of those targets were indeed ARM. The operating system was ecos.
So could ecos GDB stubs be ported to bare metal? Having giving it a good coat of looking at, I believe yes they could. The stubs are based on the ones from the GDB sources but they are heavily polluted with Ecos and Redboot build macros and copyright (the ogiringals were written by HP and released without copyright). We don't know what bugs the Ecos stubs may contain (I fixed at least one back in the day and I don't recall whether I submitted a patch). We don't know if they really support the latests architectures properly. And, we don't know if, after that, they simply use up too much memory - my STM32 has 8K of SRAM and I already see buffers that have a default size of 2K (not saying that's necessary but you see how work needs to be done here..)
So this third option, I will revisit this one day but for now, for me, it's a nope.
TL;DR: is there a step by step tutorial to do remote code debugging using Eclipse Neon?
I have the source code in a Linux machine with a GCC dev environment. Normally, I ssh to the box, edit the file, and compile/debug using gdb, and it works, but it is a bit clunky for me.
I am now trying to debug the code from my Windows machine using the latest Eclipse version (Neon as of this writing).
I've tried following the instructions online (like this one), but they all seem to point towards (cross-)compiling the code locally, deploying it remotely and debugging there. This is not what I'm after. I essentially want to use Eclipse as a remote text editor+gdb interface, with the building and compiling being done in the remote system.
I've installed CDT, plus pretty much any plugin remotely related to remote development
Remote System Explorer
Remote Launch
GCC Cross compiler support
Remote (over TCF/TE) Run/Debug Launcher
Direct Remote C++ Debugging
TCF C/C++ Debugger
TM Terminal
So far, I can connect to the remote system, create a Remote Project and edit the source code.
I don't need Eclipse to compile the code (I can do that separately) but I'm unable to debug the code.
Using C/C++ Remote Application fails in many creative ways when trying to find gdb in the remote system.
Using GDB (DSF) Automatic Remote Debugging Launcher ends in a java.lang.NullPointerException, which also invalidates the configuration
Using Direct Remote Debugging Launcher asks about a remote workspace, then complains with "Error with command: gdb --version Cannot run program "gdb": Launching failed"
Remote Application complains about the Process/Image field. Setting it to the binary output doesn't enable the Debug button, so no dice.
TCF is dead in the water. It doesn't recognize the SSH connections I set up on RSE, it asks for the username password (I use public keys) and root password (?!) Even when entering that info, it fails to continue.
On a whim, I tried NetBeans, and followed the instructions here, and got it working in five minutes. The mode I'm following is the "Full Remote Development" according to NetBeans. The reason I'll still need to stick to Eclipse is that it is the dev environment that we use in the company, and it makes little sense to me to add another IDE to do something that Eclipse by all rights should do no problem.
What I find is that the walkthroughs for Eclipse I've found are either
Using plugins that are now either deprecated, not supported or have been completely reworked. Eclipse crashes and burns on these.
Trying to compile locally and deploy remotely, doing things like embedded even, but that's not what I'm looking for.
Using the Eclipse DStore client-server combo, which is essentially an alternative to SSH, but not what I'm looking for either.
I'm then hoping someone has written/found a tutorial that is relatively simple to follow (it is, after all, a relatively simple thing to do, as NetBeans has proven), and that works on any version of Eclipse.
I'll consider using an older version of Eclipse, but if so, please be specific in which version I should use, and which plugins I should install.
I'm trying to debug an android app that call native code to do some GL rendering. The native code is existing code that I'm trying to port (and that I don't really know that well). I've got the existing code compiling, linking, and installing correctly, and I've got some native functions that call in to that code that are being correctly called from my Java code. I'm getting a segfault that I'm trying to track down, and having some problems getting gdb to set a breakpoint in the program. This is on windows XP with Cygwin - and I should probably mention I'm still learning gdb.
I started with the directions at http://honeypod.blogspot.com/2008/01/debug-native-application-for-android.html; here's what I'm currently doing.
Start the app in the emulator.
In a cmd prompt:
> adb forward tcp:1234 tcp:1234
> adb shell
# gdbserver localhost:1234 --attach 2120
gdbserver localhost:1234 --attach 2120
Attached; pid = 2120
Listening on port 1234
In a cygwin shell:
arm-eabi-4.2.1/bin/arm-eabi-gdb.exe out/apps/app-android/libDM.so
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-cygwin --target=arm-elf-linux"...
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
warning: shared library handler failed to enable breakpoint
0xafe0da04 in AppRefCounted::unref () at ../../stlport/stl/_iosfwd.h:39
39 class basic_ostream;
Current language: auto; currently c++
(gdb) b Java_com_app_AppRenderer_onCreate
Breakpoint 1 at 0xafff1b1a: file apps/app-android/../../../app-Android/jni/DMJNI/DMInterface.cpp, line 75.
(gdb) c
Continuing.
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0xafff1b1a: Input/Output error.
So it looks like the breakpoint gets set ok, and that the symbols are ok, but maybe the address is wrong when it tries to insert the breakpoint. I've tried several variations of different commands from the webpage referenced above, but so far, no luck.
Any ideas what's going on?
Thanks
Essentially, at this point with NDK 1.6, I've found that there just isn't support for this kind of debugging strictly with the NDK. However, if you use the PDK (platform development kit), you can do this kind of debugging with native code. We haven't tried the PDK, because generating a map file worked well enough for us (see this SO question), but if you do go that route, check the NDK google group for more details.
We're using the Eclipse CDT 5 C++ IDE on Windows to develop a C++ application on a remote AIX host.
Eclipse CDT has the ability to perform remote debugging using gdbserver. Unfortunately, gdbserver is not supported on AIX.
Is anyone familiar with a way to debug remotely using Eclipse CDT without gdbserver? Perhaps using an SSH shell connection to gdb?
finally I got gdb run remotly anyhow now. At the Bug-symbol on the taskbar I took Debug Configurations - GDB Hardware Debugging.
In Main C/C++ Applications I set the full path on the Samba share of the executable (X:\abin\vlmi9506). I also set a linked folder on X:\abin in the project. Then I modified my batch-script in GDB Setup. It's not directly calling gdb in the plink-session but a unix-shell-script, which opens gdb. By this I have the possibility to set some unix environment-variables for the program before doing debug. The call in my batch:
plink.exe prevoax1 -l suttera -pw XXXXX -i /proj/user/dev/suttera/vl/9506/test/vlmi9506ddd.run 20155 dev o m
In the unix script I started gdb with the command line params from eclipse, that I found in my former tryals. The call in the shell command looks like this:
gdb -nw -i mi -cd=$LVarPathExec $LVarPathExec/vlmi9506
Then IBM just gives gdb 6.0 for AIX. I found version 6.8 in the net at http://www.perzl.org/aix/index.php?n=Main.Gdb. Our Admin installed it.
I can now step through the program and watch variables. I even can write gdb-commands directly in the console-view. yabadabadooooooo
Hope that helps to others as well. Can not tell, what was really the winner-action.
But each answer gives more new questions. Now I got 3 of them.
When I start the debug config I have to click restart in the toolbar to come really in the main procedure. Is it possible to come directly in main without restarting?
On AIX our programs are first preprocessed for embedded sql. The preprocessed c-source is put in another directory. When I duble-click the line to set a breakpoint, I get the warning "unresolved breakpoint" and in the gdb-console I see, that the break is set to the preprocessed source which is wrong. Is it possible to set the breakpoints on the right source?
We are using CICS on AIX. With the xldb-Debugger and the CDCN-command of CICS we manage that debugging is started, when we come in our programs. Is it possible to get that remotely (in plink) with gdb-eclipse as well?
I wouldn't normally take a shot in the dark on a question I can't really test the answer to, but since this one has sat around for a day, I'll give it a shot. It seems from looking at:
http://wiki.eclipse.org/TM_and_RSE_FAQ#How_can_I_do_Remote_Debugging_with_CDT.3F
...that even if the CDT has changed since that wiki page was made, you should still be able to change the debug command to:
ssh remotehost gdb
instead of using TM which uses gdbserver. This will probably be slightly slower than the TM remote debugging since that actually uses a local gdb, but on the other hand this way you won't have to NFS or SMB mount your source code to make it available to the local debugger (and if you're on a LAN it probably won't matter anyhow).
There's also a reference TCF implementation for linux, which you may or may not have any luck recompiling for AIX, but it allows for remote debugging if gdbserver is otherwise not available:
http://wiki.eclipse.org/DSDP/TM/TCF_FAQ
tried also to remotly debug an aix-appl with windows eclipse-cdt-gdb.
Got blocked at the end with unix/windows path-problems. Maybe my result can help u a little further - maybe you already got it work. I'm interested in your comment. asked on eclipse news portal- following the answer of martin oberhuber (thanks again) tried dsp dd (also blocked with path problem) and set an request in eclipse bugzilla.
here the link to news:
http://www.eclipse.org/newsportal/article.php?id=406&group=eclipse.dsdp.tm
Here my bugzilla:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=252758
At the moment we still debug localy with xldb but I am trying ddd-gdb at the moment. At least locally gdb is running.