I'm having problems debugging a JNI application. I've read several threads in StackOverflow, like this one, this one or this one. I've also tried to start gdb in a separated shell and attach it to the running java process. In both cases, the problem is the same: GDB can't find the sources to debug. Things tried
Add "dir" line to gdbinit, pointing to C++ sources folder
Adding the C++ sources folder to the GDB debbuging configuration in Eclipse, in the "Sources" tab.
Adding set environment LD_LIBRARY_PATH=/path/to/library.so, being library.so the library file built from C++ source files
Attach ddd to the java process, but then I get an error because pthread_join.c is not found in the working directory. I don't have this file in my hard disk. I don't know what is this about.
Nothing worked. I've spent several days on this. I know my bug is in the C++ code called by the JNI wrapper, but I can't debug it. Any hints? If helps, I'm running Eclipse Juno in Debian 7 under a Parallels VM on Mac OS.
Many thanks in advance,
You need to have debug information in your native library. You should pass -g to your compiler and linker to have this information in the executable. You may also want to add -O0.
As an alternative to attaching to the Java process, you can create a C++ app and debug it directly. You just need to link in the functions you want to test. In the main function, create the VM, register the functions with RegisterNatives, and kick off a Java test class the uses them.
Hopefully, the debugger has no problem finding the sources since it is just part of the normal compile/link/debug loop of a C++ app.
I would suggest to start with the latest ADT bundle. You can even download the Mac version, so you will not even need Parallels (see a detailed instructions). Then, choose Debug Android Native Application in launch menu.
Related
Is there a way or steps to follow to integrate a yocto SDK (standard or extensible) with VSCode? I want to cross-compile, remote connect, and debug a C/C++ application within VSCode for target hardware using a yocto generated Linux image. Is this possible? I know of the bitbake extension but couldn't find one for the SDK. Thank you!
Conservatively, I would say it depends on the level of integration you want to achieve but I use regularly VS Code to edit and build, sometime to debug C applications using a Yocto toolchain, that's really easy for Makefile projects for example.
Assuming you do not ask for Yocto integration into VS Code (I don't know if something exists) but really to use the tools generated by the SDK from Yocto and that you already are familiar with Yocto toolchain usage.
I personally compile on Linux server remotely from a Windows PC. The server contains therefore my projects and the Yocto toolchain.
I use for that the nice Remote SSH extension from Microsoft on VS Code. From there, I can edit easily the files, compile and a terminal is available (that's out of the scope of your question however).
So if working as me or directly in Linux, you can create a Makefile/CMake project for example. The C/C++ VS Code extension is a must have.
Each time you start working, you source the Yocto SDK toolchain and compile directly using make from the terminal window of VSCode. If you want to automatize the build step, you can use the task feature of VS which allows you to launch build script for example.
Regarding the remote connect, the terminal window of VS can also have multiple sub-windows with various connections like SSH to the target. The build script can also use scp to send the generated binary directly to the target but your question is vague regarding what you want to do.
Finally for the debug aspect, GDB is well supported in VS Code and the official doc is a good start as well as the C++ debugging doc.
On the Yocto side, you need to add gdbserver to the image running on the target, it can be done by adding the following to your conf/local.conf:
EXTRA_IMAGE_FEATURES += "tools-debug"
If you want to have debug information for the shared libs on the target, you also need to add:
EXTRA_IMAGE_FEATURES += "dbg-pkgs"
Finally, the SDK must be generated with the same options as the image running on the target and will contain the cross-gdb tool like -gdb to be used on the host side.
So that's possible but requires some setup especially the debug part. As far as I know, there is not a VS Code extension managing all these steps for you automagically.
I recently started using qemu and it's a great tool when you don't have the required hardware to run your firmware (currently using it for cortex-m3).
Now what I want to do is to do some test coverage with it. I tried using GNUC ARM Eclipse, and I've been successfull compiling and executing the code in qemu, but whenever I add the -fprofile-arcs -ftest-coverage flags (for the project and then for the desired file to run coverage) I am able to create the .gcno file, which means that after executing my code it will generate a .gcda file and then I should be able to see the coverage.
Thtat's where everything goes wrong. I was able to generate a .gcda file but whenever I try to open any of them, eclipse tells me that it wasn't able to open the file because it was null. I've tried replicating the procedure in another computer, but I haven't been successful creating the gcda file (probably different binaries).
At this point I don't really know how to proceed. Should I abandon ARM Eclipse and stick to makefiles (is it possibll to run gcov this way?) or am I missing something really small that is fixable?
PS: I using windows 7 64 bits, the latest versions available on the GNU ARM Eclipse website. Also the idea of doing it via makefiles just occurred to me (it was a stresfull day, it's really late) so I haven't tried it yet, I've only tried executing the code, but without coverage.
As far as I know, qemu is not able to generate DWARF information. But there is a project with the proposal of code coverage with qemu: Couverture Project
When you use qemu as a user space emulator (see also the qemu documentation) you actually can measure the code coverage as usual. In this mode qemu has the full access to the host file system.
For a CMake project you can simply use the CROSSCOMPILING_EMULATOR property of your test executable, e.g.:
if(CMAKE_CROSSCOMPILING)
set_target_properties(mytest
PROPERTIES
CROSSCOMPILING_EMULATOR "qemu-${CMAKE_SYSTEM_PROCESSOR};-L;$ENV{SDKTARGETSYSROOT}"
)
endif()
With this setting ctest will use qemu for running the test and will write the .gcda files to the usual location in your build directory.
usually I deploy my Java apps as a bundle which contains the JVM, so there's no need to install a JVM on the system.
Btw: This is no jnlp applet, this is a normal Swing Application.
I did this using ant's fx:deploy. This already works for 64bit systems.
My problem is, that I want to deploy this application to a 32bit system and don't get it to work.
Here's what I did:
I've set up a clean Windows 7 (32bit) instance and installed a 32bit JVM. Now i ran my ant script to build a bundled Java app and it built a App.exe.
But when I tried to start this exe by double clicking, I get the following message box
If I click OK, I get another message box
After this the app is terminated.
I did not find anything searching the web relating to bundling for 32/64 bit systems.
So I would be very glad if someone can point me in the right direction.
Many thanks in advance!
Greetings, -chris-
Looks like a known bug fixed for an upcoming JavaFX version (currently known as 2.2.40):
RT-25715 The Windows launcher generated by the packager fails to load msvcr100.dll on 32-bit OS
RT-22610 .exe created by fx:deploy can't be executed due to missing msvcr100.dll
On the bug case, the user mentions a work-around:
If I give a try to the workaround documented in RT-22610, which is to copy runtime\jre\bin\msvcr100.dll side to my application's launcher binary, it fixes it.
I think the bug is fixed in JDK 8, so another possible work-around is to download a JDK 8 early access release and use the packaging tools from there to package a Java 7 application (though I have never tried that and am not sure if it would work).
Just a small modification to #jewelsea's Fix:
copying msvcr100.dll into the app/ folder instead putting it right next to the exe also works, and at least it is somewhat hidden away then.
If you're generating an MSI you can hack the WXS file used by WIX to automatically copy msvcr100.dll into the app folder. Making FX Deploy verbose will tell you where it's putting the temporary WXS file you can copy and modify and use to override the WXS like you would the program icon for example.
For the past week, i have been hunting a free development environment for STM32F1xx, which is supported by FreeRTOS. And no success yet :( .
Now I've found this: http://www.stf12.org/developers/ODeV.html
It's an Eclipse configuration for STM32 compiling and debugging, and there is a FreeRTOS demo too. Perfect!
So I downloaded a preconfigered version of eclipse and tried to compile a demo project to get this error:
Cannot run program "cs-make": Launching failed.
Depressing. Please help, i am very bad at configuring IDE's, compilers and linkers so this has to be newbie-friendly :)
The Eclipse project is configured for CodeSourcery toolchain. You need to install CodeSourcery compiler toolchain from: http://www.mentor.com/embedded-software/codesourcery. Choose Lite Edition, ARM-NONE-EABI package. After the installation make sure you can start cs-make from command prompt (by typing it's name there). Generally, you want all toolchain programs to be accessible from command prompt, which implies that their installation path must be in system PATH variable.
P.S.
Make sure the path DOES NOT contain spaces like standard Windows programs directory "C:\Program Files", instead install the tools in a directory like "C:\arm-none-eabi", "C:\ARM_tools" or something like that.
Ah, thank you got it to work now!
And I ran into another problem too. When I tried to compile another error came up saying something like: "C:\Program is no file or directory". I Solved it by placing all compilers and OpenOCD in the root of my C-drive. I think it's because the make doesn't understand spaces in the make file, if anyone else get the same problem.
I am working with Lejos and java Eclipse on Windows 7. As my machine is 64 bit it will not allow me run the standard Lejos driver as an Eclipse plugin I installed it as an external tool . I followed this super helpfull tutorial http://www.youtube.com/watch?v=hEFA0DdFhm8 However for my project I need to be able to regularly send instructions to my Nxt brick. is there anyway that I can call external tools from the main application while it is running ??Alternatively is it possible to call batch files in main programs or even make command line arguments while a program is running ??? I have read allot of forums on this and no where have I found the solution to my problem, if people have any Idea I would appreciate the help,
Thanks.
Right after allot of reading around there is and article on java world
http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html?page=1
that sums up beautifully what you should and shouldn't do .. hope this is helpfull for anyone coming after me ......