I have a Linux machine which is set up to cross-compile programs for an AVR target. It's easy to run and debug programs locally:
Run the program with simavr (acts as GDB server)
Run GDB (avr-gdb) and connect it to simavr
I'd like to to recreate this flow remotely from Eclipse on a Windows machine. The Windows machine isn't really set up for development — it has Eclipse installed and the source code for my project, but it doesn't have any local C/C++ dev tools like GDB. I'd ideally like to visually debug using the local copy of the source, but by interacting with the remote GDB over SSH.
This Eclipse plugin seems to be the recommended tool for the job. Unfortunately I can't get this working. Here's what I've done:
Created a new "C/C++ Remote Application" debug configuration.
Set the "Preferred Launcher" to "Direct Remote Debugging Launcher".
Pointed "Remote C/C++ exe file path" to the location of the binary on the remote machine
Pointed "Remote workspace directory" to the location of the project source on the remote machine
This does not seem to work. When I attempt to debug with this configuration, I get this error:
Error with command: gdb --version
Cannot run program "gdb": Launching failed
This error makes sense. If I look in the "Debugger" tab of my debug configuration, the "GDB debugger" is set to gdb. If I open the file browser for the debugger, it only shows files on my local Windows machine. It looks like the configuration is set up to execute gdb on my machine.
I thought the point of the plugin was the launch GDB on a remote machine, but I can't find a way to make a debug configuration that actually does that. Any help would be appreciated.
We use the package called GDB Hardware Debugger which lets you specify which GDB you want to use and how you want to launch it. We keep its eclipse configuration as empty as possible, with the minimum required, and continue configuring GDB through its scripting option -x which offers finer-grained control. That way, you are not required to understand how and when are those eclipse fields used to run GDB. For example, we needed to perform some extra GDB settings before connecting while this plugin connects first and then uses the provided GDB script.
Related
I've installed (OSX Mojave 10.14.6.) Eclipse CDT and GNU MCU Eclipse plugin and finaly GNU Tools for ARM. My goal is to build and debug ARM code using GDB (arm-none-eabi-gdb).
I've created a Hello World project for Arm, which builds ok - but, debugging seems not to work with GDB (that comes with the Arm package). GDB gets stuck:
I have set the proper paths in Eclipse to arm-none-eabi-gdb.
I have signed the arm-none-eabi-gdb (with the same certificate that I used to sign GDB installed via brew into /usr/local/bin/gdb the day before - and it worked!).
I have also tried running Eclipse as root from command line.
Nothing helps.
The message is "Configuring GDB Aborting configuring GDB".
What to do?
Probably what is going on here is that you built to a given target (ARM based) and you're trying to run it (with gdb) on your mac (x86).
You'll need an emulator or QEMU to properly run on your mac or maybe a real board.
This is my first post to stackoverflow so apologise for any error :). I'm trying to debug a Linux Kernel using Eclipse/CDT by following the information provideed in multiple websites. However, everytime I try to debug the kernel I get a “No source available 0x....." message. (see the attached screenshot).
I run the linux kernel with a qemu virtualmachine "qemu -s -S -kernel bzImage ..."
I try to run the debug from Eclipse/CDT. For that, I configured a "C/C++ Attach to Application" debug. The application is the vmlinux file. The remote configuration of type gdbserver is configured as localhost:1234.
Altough I can't debug with Eclipse/CDT, I can debug the kernel with gdb CLI:
# gdb vmlinux
> remote target localhost:1234
> cont
Information about versions:
Linux Mint 17 KDE
Eclipse 4.4.1
CDT 8.5.0
qemu 2.0.0+dfsg-2ubuntu1.9
gcc 4.8.2-1ubuntu6
gdb 7.7.1-0ubuntu5~14.04.2
A "C/C++ Attach to Application" debug configuration is not appropriate for this setup. You could use a "C/C++ Remote Application" configuration instead, with the manual remote debugging launcher:
Open the Debug Configurations window in Eclipse and create a new a "C/C++ Remote Application" configuration
At the bottom section of the window there is the indication of which launcher is being used: if you see anything other than the manual remote debugging launcher, click on "Select other..." and in the launcher selection window select "GDB (DSF) Manual Remote Debugging Launcher"
In the Main tab of the debug configuration, in the Project field enter the Eclipse project where you have your Linux kernel, and in the C/C++ Application field enter your vmlinux file
In the Debugger tab, under Debugger Options, select the Connection tab, then select TCP as connection type, write "localhost" in the host address field, and write "1234" in the port number field
Possibly adjust the source lookup path in the Source tab
Start QEMU with the usual "-s -S" options
Now you should be able to start your debug session in Eclipse, with working symbol resolution and source lookup
I am trying to debug a C project in mint Linux using eclipse Galileo IDE.
When I try to run the project in the DEBUG mode, the process terminates as it says- debugging information is missing.
In the eclipse console following messages appear
No source available for "main() "
and
Reading symbols from /home/project/netconf/target/bin/netconfd...(no debugging symbols found)...done.
I am using the custom build command
make DEBUG=1 STATIC=1 [eclipse >project >properties > c/c++ build > builder settings]
it builds and runs fine in RELEASE mode.
I am able to build the same application using normal command line build using command terminal, using the same build options
> sudo make DEBUG=1 STATIC=1
now I can start a command line gdb session, as the debugging info is generated, but it is very difficult to debug that way.
I need to know if there is any other setting that needs to be changed, so that I can start debugging in eclipse.
Thanks in advance.
Add -d (or probably -g) to your command line. I think DEBUG=1 is defining a macro rather than generating debug info
I am having some issues with ORA*C and Cygwin.
I am trying to port this UNIX program into Windows using Cygwin.
I installed Cygwin with all the C libraries,etc.
And I also installed Oracle 10g (reason being that UNIX project is currently using that and I want to keep things 100% compatible).
If I open cmd and type proc myfile.pc etc etc It runs pretty well.
When I try to do the same thing in Cygwin terminal (or Netbeans) I get the following error:
PCC-F-NOERRFILE, unable to open error message file, facility PR2
I read somewhere in google that this has to do with the ORACLE_HOME environment variable, I tried setting this variable to:
/cygdrive/c/Oracle/product/10.2.0/client_1
or
C:\Oracle\product\10.2.0\client_1
in the windows path settings and/or my Makefile and I am still having the same issue.
Any insights?
I'm cross-compiling a project from Linux to target Windows (using mingw). The output is a DLL and p-invoking into it from C# works, but debugging is very difficult. The build outputs a .o file, which can provide symbols to gdb, but basically all I can do there is break on exceptions and find the name of the function that was executing when the exception happened; not even the full stack trace. I can't debug with WinDbg because I don't have .pdb files.
This is an open source project set up to build on Linux; I believe their build process relies on several installed Linux packages to work.
Do I have any options here? Is there a utility that can convert .o files into .pdb? Or some program that can give me more information than gdb when debugging?
Try a IDE that support mingw. For example the open source Code::blocks.
Another possibility is to do it manually: compile it with debug symbols, start you application and attach the GDB debugger to it. It is also part of the MingW32 distribution. Then you can set your breakpoints and debug your application
But I guess using Code::Block is more comfortable
By the way, the GCC compiler does not generate pdb files because it is a propietary format
What xpol means is maybe: if you have a complete mingw installation then Code::blocks can use gdb to visualize a debugging session like it is done in Visual Studio or Eclipse. See chapter "Debugger" at http://www.codeblocks.org/features
You can generate a .pdb file using cv2pdb.exe from Visual D. This works even for programs not written in D if they were compiled with mingw. Once you've downloaded and installed Visual D cv2pdb.exe can be found at C:\Program Files (x86)\VisualD\cv2pdb\cv2pdb.exe.
You can run cv2pdb.exe against an executable like this:
cv2pdb.exe -n target.exe
This will produce a file called target.pdb. Assuming both target.pdb and target.exe are in the current director, you can then use windbg like this:
windbg -sflags 0x80030377 -y . -z target.dmp
In this case I'm also passing a minidump file as target.dmp. This can be omitted. The -sflags 0x80030377 option tells windbg to load target.pdb even though it thinks it doesn't match target.exe.
Note, that it can take windbg a very long time to load target.pdb. Just wait until it no longer says *BUSY* to the left of the command entry box.
Alternatively you can try DrMinGW.