Forum Replies Created
-
Posts
-
Hi,
I presume, you mean VisualGDB, not WinGDB. Yes, simply click “resynchronize toolchain” on the Build Settings page of VisualGDB Project Properties and VisualGDB will automatically fetch those files for you.
Hi,
You can specify NDK_MODULE_PATH via Make arguments in VisualGDB Project Properties (Build Settings page).
Hi,
You can specify NDK_MODULE_PATH via Make arguments in VisualGDB Project Properties (Build Settings page).
It might be possible in theory, but in practice many Cygwin-specific functionality will simply crash randomly because it will expect certain process-wide preparations to be made by the host executable (that will not be made as your EXE is not cygwin-based). You could try investigating and fixing those crashes, but using MinGW would be a much easier solution.
You do not need to copy the source code to the target machine. Although GDB running there won’t be able to locate the source files, it will report the file paths to VisualGDB. And as long as VisualGDB has the correct path mappings (configured via VisualGDB Project Properties), it will be able to map those paths to the correct source files on the Windows machine.
Hi,
Thanks for reporting this. Looks like VisualGDB missed one step in detecting the new library locations introduced in Android 5.0. Please try VisualGDB 5.0 Preview 4 and let us know if it works.
Hi,
Are you trying to load a Cygwin DLL into a non-Cygwin EXE? If yes, this is unsupported and can cause very strange bugs. I would recommend building your code with MinGW instead of Cygwin. It does not emulate certain Unix-world things like fork(), but is much easier to integrate with existing code from the Windows world.
Hi,
We tried reproducing it on a basic Windows project, but could not get VisualGDB to issue wrong frame commands. Can you reproduce it with a basic MinGW-based application? Does it also happen with GDB 7.0+ (VisualGDB should use the –frame argument instead of -stack-select-frame)?
Hi,
Please try this build: http://visualgdb.com/tmp/VisualGDB-5.0.3.312.msi
If cleaning is still not working, please provide a build log and double-check that the gradlew.bat file is present in the directory that VisualGDB reports.
If android:debuggable is still added, please check the build log, it should now print the full path of the AndroidManifest.xml it is editing. Please let us know which file version is VisualGDB trying to edit.
We used zipalign because assemble did not seem to work properly on some older version of Gradle. As it seems to work now, we have changed it to assemble and added a setting that allows overriding it.
Please double-check the COM port settings in the Windows Device Manager and ensure that the speed and the parity settings match the settings on the Linux side.
The general outline of building a cross-toolchain is described in http://gnutoolchains.com/building.
However in most of the cases you will face multiple build errors, as the GNU tools are quite fragile and often incompatible and require ad hoc fixing. We do offer a custom toolchain building service. I.e. if you provide us with a snapshot of your Linux system, we would build an equivalent Windows cross-toolchain for you. Please contact our sales to get a quote for that.
You can alternatively use VisualGDB with clang. As clang command-line options are compatible with gcc, simply replace the gcc executables with clang executables in debug.mak and release.mak
Hi,
Please try the following build: http://visualgdb.com/tmp/VisualGDB-5.0.3.310.msi
We have made the following changes:
- When using Gradle build subsystem, VisualGDB now uses the $(SourceDir)\$(GradleAppSubdirectory)\build\intermediates\manifests\full\$(GradleFlavor)\$(GradleBuildName)\AndroidManifest.xml file to determine the package/activity names and other settings. I.e. all changes caused by the Gradle flavor will be now read correctly. The path (that appears to be hardcoded in Gradle) can be currently modified by editing the .vgdbsettings file manually.
- VisualGDB now uses the zipalign$(GradleFlavor)$(GradleBuildName) as the gradle task name. The GradleFlavor can be defined via VisualGDB Project Properties as before.
- VisualGDB now does not edit the AndroidManifest.xml file if it has successfully found a generated manifest file from the intermediates folder.
- You can specify additional arguments to Gradle by adding a VisualGDBProjectSettings2/Build/AdditionalGradleArguments element to the .vgdbsettings file (no GUI setting for it yet).
- In case of multiple apk files VisualGDB checks whether the $(app subdirectory)-$(gradle flavor)-Debug.apk file is present. If it is found, it is automatically selected without showing any extra windows.
- If VisualGDB has to rebuild the .jar file, it now displays the file that caused the rebuild.
The build output is actually still available if you select ‘build’ in the “show output from” field. Opening VisualGDB Project Properties switches the output view to VisualGDB internal output.
Looks like your kernel is configured without kgdb support. Please enable it via kernel configuration interface and then build kgdboe again with the new headers.
The SIGSEGV is most likely caused by the workaround VisualGDB utilizes to fix issues with library symbol loading. Please try switching the workaround method or disabling it completely.
VisualGDB rebuilds the .jar file when any of the .so files that go into it has a more recent timestamp than the .jar file itself. Please double-check why your .so files get rebuilt.
Regarding the gradle flavor issues, we will do a full investigation/analysis of that after we release the new clang-based IntelliSense engine. Before that we should be able to provide hotfixes that should make debugging possible with reasonable manual adjustments. Could you make and send us a small small repro case demostrating the broken build/launch for a custom flavor? We should be able to release a hotfix based on it very quickly.
Hi,
As your scenario (debugging a completely custom kernel) is very rare, we will most likely not create a separate product supporting it. However what we can do is extend the VisualGDB plugin interface so that you could add your custom tool windows and use the convenient VisualGDB SDK interfaces to query various data from the GDB session. Let us know if that works for you.
