Does anybody know how i can debug Navit. It doesn't matter if i can do it in MS Visual Studio or Eclipse. It doesn't matter if I have to do that under Windows or Ubuntu.
Navit is a C application, and can be debugged using any debugger that can debug C programs.
The details depend on your development environment (IDE/editor, compiler, operating system).
For development on Linux, popular debugger options include:
gdb (text-based)
DDD (graphical)
Eclipse CDT (graphical)
Pyclewn (vim plugin)
Some notes:
Usually you want to build in debug mode (cmake option -DCMAKE_BUILD_TYPE=Debug). This will build with symbols and disable optimizations, which makes debugging easier.
When running the navit binary without installing it, you must run it from the directory it is created in - otherwise it will not find the plugins (which are compiled to separate libraries). Take care to configure the current directory correctly in the debugger.
Related
I have installed Visual Studio 2019 and am attempting to set up a development environment that allows me to cross-compile for ARM11 on WSL, deploy it to my device, and attach Visual Studio's debugger to a custom gdb server that runs on the device. Most of the mentions of remotely debugging with GDB using Visual Studio mentions use of SSHing into the machine first. The device I am attempting to debug remotely on is not POSIX and does not have a shell to SSH into, just a built in GDB server on port 4000.
I know it works, because using WSL, the following works:
$ gdb-multiarch application.elf
GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git
<GNU Licensing crap>
Reading symbols from application.elf...done.
(gdb) target remote 192.168.43.121:4000
Remote debugging using 192.168.43.121:4000
warning: Target description specified unknown osabi "3DS"
svcWaitSynchronization () at /home/fincs/pacman-packages/libctru/src/libctru-2.0.0/libctru/source/svc.s:263
263 /home/fincs/pacman-packages/libctru/src/libctru-2.0.0/libctru/source/svc.s: No such file or directory.
(gdb) cont
Continuing.
Start calloc test... micros elapsed: 1.592000 <-- from device's stderr
Knowing that this works perfectly fine, I wanted to try to work this intro Visual Studio because I really like the IDE's debugging capabilities. Based on their description of VS's capability to interface with GDB, I figured it should be possible to hook into the debug server on my 2DS. However, all I have been able to figure out and try is to add a no-auth connection in Visual Studio's connection manager and maybe I can work it into the debug task from there, but this is what happens when I try:
So I stop here. I'm not sure what else to try. I also don't imagine that this is the final barrier, because two other things don't really match up with the gdb-multiarch process that I get working through WSL, namely that:
I don't see any way to specify to Visual Studio what symbol file to use like I do for GDB (application.elf). I suppose perhaps it will have those anyway due to being an IDE.
Since I am debugging from an x86 machine, I am not sure if Visual Studio will be able to make sense of the ARM11 gdb server. This is why I use gdb-multiarch when doing it through WSL. Using the defuault gdb doesn't yield results.
How can I move forward to allow Visual Studio to play nicely with this no-auth ARM11 gdb server?
I've downloaded the MSVC ABI version of Rust 1.7.0 and followed the guessing game section from the docs.
I notice that the builds use the native toolchain (Visual Studio 2015 Update 2 in my case) and therefore generate native PDBs (debugging symbols) consumable by native debuggers, such as WinDBG, CDB or the Visual Studio debugger. I can easily set breakpoints, step into standard library source and so on.
What I cannot do is to inspect variable values. Regardless of the debugger used, the 'Locals' display is empty.
From what I can gather, the Visual Rust/RustDT IDEs display locals when using GDB or LLDB as a backend, not the native Windows debugging engine. I'm not entirely sure if I can use these to debug Rust programs compiled for MSVC ABI (with PDBs and so on).
If I want to have the necessary debugging experience, is my only option to switch to the GNU ABI? Barring that, is there an easy way to map to Rust symbols (variable values) from the raw debugging tools (registers, memory map)?
Features don't exist until they're implemented. Rust is built upon LLVM and full PDB support has only recently been considered for LLVM. For now LLVM has only a limited PDB support, with the limitations best described on the Clang project's MSVC compatibility page. In my opinion, it's best to wait until the support is there, although for other programming languages interesting workarounds have been implemented.
I am developing an app with GCC, mostly on Windows, until I got a crash that couldn't be debugged with the MinGW toolchain build I have. I installed a Linux VM, and debugged it there, which was possible, because the libstdc++ had the symbols I required.
I'm sure the Linux build of libstdc++ was a release (optimized version), because this would be normal to be installed for all apps to use. Same with the Windows version. But how can the Linux version have the necessary debug symbols built in, or if I ask the question I really want an answer to: how can I build GCC's libstdc++ so that I can get a useful stacktrace out of it, and still have it optimized? (note: I am able to recompile GCC/MinGW, so that's not an issue)
I know visual studio has both debug and release versions, but never heard of something like that for Linux. The debug symbols are always in seperate packages as I remember.
Info: I was using Arch linux with the plain GCC packages installed (no special debug versions explicitly selected).
I'll answer this one myself: you need to configure with
--with-stdcxx-debug
This will place a in lib/bin and lib/debug a shared and import library, which contains debug info.
I have a c++/cli dll that I load at runtime and which works great in debug mode. If I try and load the dll in release mode it fails to load stating that one or more dependencies are missing. If I run depends against it I am missing MSVCR90.DLL from MSVCM90.DLL. If I check the debug version of the dll it also has the missing dependency, but against the debug (D) version.
I have made sure debug/release embed the manifest file. I read something about there being issues with the app loading the dll being build as Any CPU and the dll being built as x86, but I don't see how to set them both to x86.
I am using VS2010.
Anyway, I've been messing around for a while now and have no idea what is wrong. I'm sure someone out there knows what is going on. Let me know if I need to include additional info.
alt text http://www.freeimagehosting.net/uploads/fb31c0e256.png
UPDATE:
This ended up being the resolution to my problem: http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/07794679-159b-4363-ae94-a68fe258d827
MSVCR90 is the runtime for Visual Studio 2008. If you are running your application on your development PC, then you should have the debug and release runtimes installed (as part of Visual Studio) but it is possible something has gone awry with your install, or that VS2010 doesn't actually include the older runtimes. If you're trying to run the Release on a different PC, then it just needs the runtime installed.
Either way, you may be able to fix it by installing the Visual Studio 2008 redistributable - but make sure you get the right download for your PC (x86 or x64).
In previous versions of VS, you needed the runtime for the version you were compiling with, so if VS2010 follows this precedent you'd need MSVCR100, not MSVCR90 - which suggests that you may not have recompiled the dll with VS2010 - doing so may be another approach to get it running on your PC (using the redist that is in your VS2010 install) but beware that you will still need other users to install the appropriate (VS2010) redistributable on their PC.
As for "Any CPU" versus "x86", this is a problem only on a 64-bit computer. On those systems a 64-bit application can't link dynamically to 32-bit dlls. If you compile your application as "Any CPU" it will be JIT compiled to be 64-bit on an 64-bit OS, so will crash if it tries to call any 32-bit dlls directly. THe solution is to build the application targeting "x86" as that forces the JIT compiler to generate 32-bit code (even on a 64-bit machine) and thus ensures compatibility with the dll you wish to call. If the DLL is a managed assembly, then you can use Any CPU on both the app an dll as they will both be JITted to the same format.
It happened to me something similar running a website in Vistual Studio 2012, after migrating from Visual Studio 2010. The error message was saying that MSVCR90.DLL was missing. The solution was:
1) Delete the folder _bindeployable located at the project path.
2) Rebuild.
I hope it helps.
I have several C free software/open source libraries that I develop on Linux and OSX with the GNU toolchain (automake, conf, flex, bison, gcc, ...) but I occasionally get requests to provide Windows DLLs. I'd like to be able to provide those without having to spend a lot of time and money with Windows Visual Studio development. I do have a Windows XP virtual machine available and I also know the software is portable as occasionally I get patches to make it build in on windows.
What approaches or tools should I be using? Cross compiling on Linux? using Visual Studio Express or something else? I would prefer something that is fully automated from a SVN repository. I do not count cygwin as a solution since that does not seem to provide what Windows developers need, as far I understand the issues - linking and DLLs.
You can try Mingw with MSYS, Visual Studio (Express) with SUA (subsystem for unix application) or Cygwin to compile programs that are automake/autoconf based (./configure && make to build under linux).
Unfortunately usually the lib file they create is not compatible with other compilers, so if you want your library to work with an application that is developed using Visual Studio, then you should use the VSC++ approach. Usually a lot of GNU projects (check gnuwin32) actually have VC compatible build scripts too, than can be compiled using "nmake"
You could use MinGW or install the MSVC command line tools from Visual Studio Express.
Either of those can be driven by command line scripts.
I imagine a cross compile from Linux would also work, but I have no idea how easy (or painful) that might be to get going.
This short article shows a simple cross compile of a Windows application & running that app under Wine:
http://www.linuxjournal.com/node/1005753
The Windows Software Development Kit includes Microsoft's C/C++ compiler (command line only with no visual tools), so you don't even need Visual C++ Express Edition. The Windows SDK is a free download from Microsoft.
If you're using http://www.cmake.org/, cmake can create the Makefile (for Unix) and project file (for Visual Studio). This is what for example the KDE project is using.
Visual Studio's compiler can be started from a Windows command line with 'devenv /build debug project.csproj' on the cmake generated file. This does however require a Windows (possibly in a VM) with a (potentialy free) Visual Studio installed.