As the topic says. I am trying to start a debug session of a C/C++ project with TCF as the debugger.
This is what I do, (I am on windows xp)
I create a C/++ project, build it using mingw32-make.exe and generate
a binary.
Then I press Debug As->Debug Config->Target Communications Framework
In that, I specify the project name, and in the Local File Path box i give the absolute path of the C/C++ project's binary.
I give nothing in the Remote File Path since I am doing localhost.
Then I run a TCF agent (which can be obtained by building TCF agent source).
In the target tab in the debug config, I check "Use localhost as a target".
And finally press Debug.
Now when the session starts, I get a tcf nullpointerexception and session doesnt even start.
Has anyone done this type of debugging?
You compiled your project using mingw, there's no point in using tcf to do local debugging, just use CDT's default debugger gdb , specify full path to gdb(mingw/bin/gdb) in your debugger tab, and evertything should be ok
BTW. I just did a tcf local debugging as you did, it worked, only that I compiled my project using msvc toolchain. Maybe that's your problem
Related
I am compiling a C project with a container using gcc and specific toolchain.
I mount my project locally under /opt/git/myProject to the home directory of my container and then I compile it /home/user/myProject.
When I debug using vscode, it tries to open a c file under the home directory of my localhost.
Is it possible to tell to gdb (or vscode) that in fact my source file linked to the bin being debugged is under /opt/git/myProject ?
Is it possible to tell to gdb
Yes: see documentation on how to do that.
I suspect that using set substitute-path /home/user/myProject /opt/git/myProject is what you want.
In a VScode C/C++ programming setup on Windows 10 system, the "C/C++ Extension Pack", "Code Runner", "WSL" extensions are installed, which use Alpine Linux target on WSL on this PC. Alpine Linux WSL instance has the gcc dev environment, build-tools, gdb etc. installed, apart from the necessary VScode extensions needed inside WSL.
In this environment I am able to write C/C++ programs, build them, execute them, interact with them through the built-in terminal. I use the "Code Runner" "Run C/C++ file" shortcut button to build(if necessary) and run individual C/C++ program files (there is no Makefile and these are simple programs all thrown in a single folder, not in a project structure).
Recently however, I noticed that whenever I try to "Run C/C++ file", debugger is also launched and I get a screen like this (notice the 2 yellow/orange arrows indicating what I am trying to draw attention to):
I do not remember this being the case earlier, but I think this started after I tried to debug a program by setting a breakpoint, which I later cleared. I've also ensured that "Run > Remove All Breakpoints" is done, to make sure that there are absolutely no breakpoints. Therefore wondering if:
it is normal for debugger to get launched in this manner ?
if not, what exactly might have caused it ?
finally, what can I do to make sure that the debugger is not launched, when all I want to do is "Run" ?
In "Code Runner" settings file, I did not find anything that might control this behaviour, but then I am quite new to VScode so not sure if I am missing anything obvious.
I've installed Quartus and NIOS II IDE on my Linux machine. Originally I tried importing an existing NIOS II Project into Eclipse, but it just sits there spinning away and eventually tells me it can't import the project because it already exists.
I tried installing everything on a Win10 machine and the project imported OK. I did notice that some of the paths in the orignal project have backslashes. So, for example:
#include "..\subfolder\include_file.h"
Kind of thing. I wonder whether maybe it was that was causing issues.
So, I then tried creating an hello world NIOS Processor in Quartus and making a NIOS II project from scratch. Every step along the way with Eclipse was grindingly slow, but eventually worked up until the point I was able to hit Finish at which point it's just hanging with the little circle with red and blue arrows spinning round and round.
I also have a pop up window with a long list of:
Remote System Explorer Opertion
lines, and at the top it says:
The user operation is waiting for background work to complete
It seems like everything is installed correctly, I can open the NIOS II Eclipse IDE from Quartus for example. Quartus itself works nicely.
I used these instructions to installed Eclipse:
Is anyone able to give me any pointers as to why this is so incredibly slow please? My Linux machine is pretty high spec and flies. Nothing else whatsoever even vaguely struggles on it.
If there's anything I can try to give diagnostic info, am more than happy to supply. Thanks!
I found a solution here
https://askubuntu.com/questions/761604/eclipse-not-working-in-16-04
To test if this fix works, try opening a terminal, and doing
$export SWT_GTK3=0
then run eclipse-nios2. That is, do something like
$ ~/intelFPGA_lite/20.1/nios2eds/bin/eclipse-nios2
If that fixes the problem then to make the fix permanent edit eclipse.ini which for me is in intelFPGA_lite/20.1/nios2eds/bin/eclipse_nios2
In that file, between the lines openFile and --launcher.appendVmargs
insert
--launcher.GTK_version
2
So it reads:
openFile
--launcher.GTK_version
2
--launcher.appendVmargs
and save.
Worked for me!
Try using Visual Studio Code instead. It can do (almost) everything that Eclipse can do, with the added benefit that you can debug remote. E.g. in my setup, I develop exclusively using macOS. I have Quartus installed in a Ubuntu 20.04 VM and VSCODE allows me to develop and debug as if I'm running Quartus natively in macOS.
I'll provide a rough 'how-to' below.
I strongly suggest using a Ubuntu environment for Quartus (other linux environments should work too: I've tested Arch and Manjaro). The Windows install is a royal pain to get working, regardless of IDE choice. I haven't tried the Windows version since 20.1 but nothing worked out of the box and it took many hours or messing with config files to fix it. Also, the Windows version isn't native anyway - it's actually running in Ubuntu via WSL.
Make sure you have installed your required version of Quartus - this should work for Pro, Standard and Lite editions. You can skip the manual installation of NiosII Build Tools for Eclipse if you'd like but I would actually recommend installing it. It can still be useful, if only for creating a new project, BSP etc.
Install VSCODE along with the C/C++ Extension provided by Microsoft (and the Visual Studio Code Remote - SSH extension if you intend to use that feature)
Create a new project using Eclipse (or skip, if you already have a project)
Open VSCODE, select open and navigate to the software directory of your project.
VSCODE will open your project and you should see your application directory and BSP directory.
From here, you can work on your code with full linting, auto completion etc.
If you need to regenerate your BSP, you can either do that using Eclipse or just run the command-line tool instead.
Compiling
If you allowed Eclipse to create your project for you, it will have produced a makefile in your application directory. Compiling is as simple as running 'make' from the application directory. I like to keep a terminal window open within VSCODE so I can run various tools as I work so this is usually how I can compile code. If, instead, you'd like to integrate this into VSCODE, you can define a task (https://code.visualstudio.com/docs/editor/tasks).
Eclipse automatically adds new sources that you create to the makefile. VSCODE won't do this - however, I personally don't think this is a bad thing. I don't like IDEs messing with my makefiles, I want fully control over them myself. So when you create a new source file, just remember to add it to the makefile. There is probably a way to get VSCODE to add sources files automatically (you can run commands on save etc) - but I have no motivation to try to figure this out.
Debugging
It is also possible to debug Nios2 software live on the target via the USB-Blaster using VSCODE. To do this, open the launch.json file in the .vscode folder of your project. If this file does not exist, just create it. The path should be:
<project root dir>/.vscode/launch.json
Copy the following into the launch.json file:
{
"version": "0.2.0",
"configurations": [
{
"name": "app",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/app/app.elf",
"stopAtEntry": true,
"cwd": "${workspaceFolder}",
"MIMode": "gdb",
"miDebuggerServerAddress": "localhost:2334",
"miDebuggerPath": "/PATH/TO/intelFPGA/20.1/nios2eds/bin/gnu/H-x86_64-pc-linux-gnu/bin/nios2-elf-gdb",
"debugServerPath": "/PATH/TO/intelFPGA/20.1/quartus/bin/nios2-gdb-server",
"debugServerArgs": "--tcpport 2334 --reset-target --tcppersist",
}
]
}
This file is a list of debug targets and settings. You can add any number of configurations here, but easiest to just start with one for now. The configuration above is called 'app', you can change this to suit your own project if you wish.
Update the "program" entry with the path to your applications elf
file
Update the "miDebuggerPath" path with the path the nios2-elf-gdb on
your system. This is the gdb client for Nios2
Update the "debugServerPath" path with the path the nios2-gdb-server.
This is the gdb server for Nios2
Save the file and now click on the "run and debug" button on the left
side control panel in VSCODE
You'll see play button at the top of the screen next to the configuration you just defined in launch.json. Hit the play button - this will start an instance of the gdb server, followed by the gdb client and connect the two. If all goes well, your target will run and stop in main.
VSCODE will provide you with a set of debug tools for stepping, watching variables, call stack - all that good stuff. On the right hand side, you can view the debug console which will allow you to enter commands directly into the gdb console. Note, you have to prepend your commands with -exec. E.g. to print the value of a variable x, you would type:
-exec print x
Caveat
There is a problem with this debugging method: nios2-gdb-server doesn't always exit cleanly and as a result the port doesn't close. If you try to start another debug session, the server won't start because the port is in use. Eclipse solves this problem by randomizing the port everytime it launches the gdb. I have not found a way to do that VSCODE yet.
I find easiest way around this is to run the gdb server manually when I need it. Comment out the two 'debugServer' lines above. Open a second terminal in VSCODE and run:
nios2-gdb-server --tcpport 2334 --reset-target --tcppersist
This will keep the server running even when you stop debugging. If you start another debug session, it will reconnect to the same server instance.
Update: rioV8 provided a helpful solution to this problem which involves using a vscode extension to generate a random environment variable which can used be used in place of the port numbers. The solution is here.
Before each debugging cycle I have to run gdbserver on remote target (Linux). So I was thinking to make script that would call python program that would connect over ssh and would run gdbserver.
I cant find any options to run command before debug and I also try to change .gdbinit file but I am unable tu run python script whit that. Since I am using crosscompiler I cant to get other gdb whit such support.
You don't need to run Python to invoke an external command from GDB. This (in .gdbinit) should work:
shell ssh remote-host gdbserver :12345 /path/to/binary/on/remote &
target remote remote-host:12345
If you do need more complicated ssh setup and need Python for that, you can certainly get it with
shell python your_script.py
If you can't get any external program called from your gdbinit, I see one way of doing it within Eclipse that might work (I didn't tested) but it is not really straightforward...
Create an External Tool configuration that launches your gdbserver program (Python or whatever command line script)
Create a C/C++ application launcher that launch your application to debug
Create a launch group that will call the two previously configured configurations.
Launch the group in debug mode
Eclipse 4.7.0 can connect to SSH and launch gdbserver automatically with the automatic launcher set when creating a new debug connection, without the need for any custom scripts.
I have explained the setup in great detail at: Remote debugging C++ applications with Eclipse CDT/RSE/RDT
Here is my situation:
I am developing PHP CLI scripts on a distant server using Eclipse IDE with the RSE plugin (allows to edit files directly on the server).
Now I need to debug these scripts in a similar fashion than in Java (break points, show the variables content, ...).
I found something that could do the job: XDebug and PDT (Eclipse plugin). The problem is that when I try to launch the debug mode Eclipse says that there is no PHP debugger on the local machine. I guess it should be installed on the server machine.
I would like to know if it's possible to use PDT and XDebug to debug remote scripts and, if it's the case, how to configure them to do so. If not, I'd like to know if other solutions exist. It seems like XDebug uses TCP so it should be possible to debug remotely. I can change my IDE if necessary.
The server runs Ubuntu 10.04 with php5-cli and the dev machine with eclipse runs Win7 32bit.
Thanks
Yes this is possible, you need to enable xdebug in the remote server's PHP.ini file and make sure that the xdebug port (default 9000) is not blocked by any firewalls.
xdebug's page on setting up remote debugging.
Here is the complete procedure for the people who have the same problem:
First, install RSE by following the instructions on this website: http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.rse.doc.user/gettingstarted/g1installing.html
Follow the instructions on this HowTo to install XDebug on the server:
http://ubuntuforums.org/showthread.php?t=525257
Install PDT on Eclipse and do the following changes:
- under Windows/Preferences, go under PHP/Debug and change PHP Debugger to XDebug
- under Windows/Preferences, go under PHP/Debug/Installed Debuggers and configure XDebug. Change the field "Accept remote session (JIT)" to "any".
Open the Remote System Explorer perspective, select your scripts directories and create a project from them (Right Click, Create Remote Project). It will now appear in the PHP perspective.
Let Eclipse run and go to the server (e.g. via SSH). Run the script you want to debug. A Window will then appear on Eclipse proposing you to choose with which "local" (remote via RSE in our case) file you want to link the running script to. Normally, the default script proposed should be the correct one, because it is the one running on the server.
You should now have visual debugging with Eclipse for your PHP-CLI scripts!
Do you want to debug while being able to interact with the script on CLI or do you just want to start it and then step through the code? I guess your question is referring to the problem that you can't access the script directly through a URL. If that's your problem, then I guess the easiest solution would be to debug a usual PHP-web-site which requires your script. Then you can launch XDebug with that web-site initially and step into the script through the require/include-statement.
index.php:
<?php require_once("../../../../../dir1/[...]/cliscript.php");
Best regards
Raffael