To log to a text file from a native daemon process, push the empty file beforehand to /data. Next check that the owner of the process and the location where you are writing are the same.
Certain pointers on debugging DLL's in Visual Studio Assuming you have the source code for both the calling application and the DLL. Build both the application and the DLL projects in Debug mode. On building the DLL you should get 2 files: a .dll and a .pdb. Place these 2 files in the folder containing the exe for the calling application. Or you could place it in another folder and specify its location. Please note that the pdb and dll should be created in one build. If a mismatch occurs between the two, it might not be possible to debug your application. Open the DLL's source code files in the same Visual Studio session as the calling application and put break points in them. On stepping into the code from the calling application, you will now be able to debug the code for the DLL. Another way to debug DLL's is to start from the DLL project and mention the executable that calls the DLL.
So I was adding my driver to the Linux kernel. Made a new Kconfig file and added 'menu' and 'endmenu' sections. But when I compiled the kernel I got an error saying 'endmenu in different file than menu'. Reason: There has to be a new line character after endmenu in your Kconfig file!
First go into the Android.mk file in your jni folder and add this line: LOCAL_CFLAGS += -g This is going to enable the debug compile option. You might have a separate option for logging more data. Next go into Application.mk and uncomment this line: APP_OPTIM := debug (or add it if it isnt there) This should be sufficient. Now when you run the ndk-build (You can run ndk-build V=1 to enable the verbose option), you should get the debuggable binaries. For some reason the binary I get in the libs/armeabi folder is not the debuggable one, this one has its debug options stripped out. To get the debug one grab it from obj/local/armeabi.
Comments
Post a Comment