Forum Replies Created
-
Posts
-
Hi,
Are you able to use the non-stop mode reliably in the normal command-line mode without VisualGDB?
Hi,
This might be happening because you are building against an older platform version in NDK that installs an older gdbserver (tool required for debugging) that is incompatible with the new Android OS.
Does switching the NDK platform to a more recent one solve the problem?Hi,
Last time we checked the GDB non-stop mode, it was not very reliable and many commands did not work in it. Could you please let us know what are you trying to accomplish with using the non-stop mode? There could be a better solution to that.
Hi,
This cryptic message actually comes from Windows and means that the host name you specified cannot be found. Please try stopping your DNS cache service (net stop dnscache) or specify the IP address directly.
Hi,
We are currently still investigating the feasibility of building the 4.8 toolchain. So far we have managed to update our Raspberry Pi device to Jessie, but there are still some things to figure out before we can publish the toolchain.
Hi,
Normally VisualGDB will compute relative source file paths and put them to Makefile when updating it. Looks like in your case this mechanism is not working as expected. Could you please share your Makefile and also let us know its full path, the full path of the .cpp file and the full path of the Visual Studio project?
Hi,
It’s hard to say where exactly the problem is, but it’s somewhere between your GDB and the GDB stub. The GDBServer protocol uses hardcoded register positions, so if the stub and GDB make different assumptions about them, things will be mixed up.
We would advise using VMWare GDB stub instead (e.g. http://sysprogs.com/VisualKernel/tutorials/vmware/). You can also try explicitly compiling your GDB with XML support so that it will understand XML register descriptions reported by the stub (if Bochs supports them). If that does not help, the solution would be to dump the packets received from the GDB stub, compare the reply from Bochs with the reply from normal GDBServer and adjust the Bochs sources to make them compatible with GDB.Hi,
This is a known limitation of recent Android versions. In short, you will need 2 versions of your native tool: one for Android 4.1+ and another one for the previous versions. Running the older one on the new OSes will show the message you are experiencing. You can read more about it here: http://stackoverflow.com/questions/24818902/running-a-native-library-on-android-l-error-only-position-independent-executab
Although it is used in many production environments, it is still not as popular as the mainstream languages. Either way, feel free to give it a try with the Quick Debug feature and if you find some annoyances along that path, we should be able to fix them for you.
Hi,
Our latest Beaglebone toolchain is Debian-compatible, so you should have no problems using it for your device.
Regarding the complexity, answer depends on what are you trying to accomplish. The development tool experience (building, debugging, configuring) with VisualGDB is very similar to classical Visual Studio. The APIs, however, are completely different: if you are used to certain Windows APIs, they won’t work on the Beaglebone even with VisualGDB, i.e. you will still need to learn and use the Linux API. However, there are numerous tutorials on those and you can also ask here if you have further questions.Wait a bit more on that. Once the beta is out, I will release a self-contained source package that won’t require any further adjustments.
Hey guys, if I promise something, I don’t forget it 🙂
The new WinCDEmu beta is out. Check out the highlights here: http://wincdemu.sysprogs.org/news/4.0/
I’ve added what everything that was asked except 2 things:
* Registry cleanup for portable driver uninstallation. Simply could not reproduce it. If you can share exact repro steps, I’ll look into it more.
* Localization for the portable version. The current localization engine stores translations in separate files, but the portable version has to be 1 stand-alone file. If someone is willing to modify the sources to support localization via resources, I can show how to do this.If you have other requests or feedback on the beta, feel free to post them here.
OK guys, the Beta 1 is out so I need your feedback on it. Once we ensure it’s stable, I will release a complete source package that will include BazisLib so you won’t need to mess with installing and configuring it.
Hi,
Most likely your LD_LIBRARY_PATH is modified from .bashrc that is not processed when running commands like GDB over SSH directly (opposed to typing the command name manually in the shell). VisualGDB 4.3 Beta 2 actually detects this condition and configures a workaround automatically. Please try updating to it.
