[support]

Hi,

It is always very hard to diagnose such problems without seeing the full GDB log because in most of the cases the root cause is some tiniest difference between different representations of a path. Can you reproduce the problem on a ‘hello, world’ project on the same machine? The only thing we can do is show you the GDB logs on our side demonstrating normal VisualGDB behavior so that you can compare them with yours and search for abnormalities.

Regarding the breakpoint that is shown as unresolved, looks like it corresponds to multiple addresses, but GDB does not report them in a way VisualGDB expects it. Here’s a sample response from setting a breakpoint in a template function that has 2 instances:

^done,bkpt={number="4",type="breakpoint",disp="keep",enabled="y",addr="",times="0",original-location="/tmp/VisualGDB/e/PROJECTS/TEMP/LinuxProject10/LinuxProject10/LinuxProject10.cpp:7"},{number="4.1",enabled="y",addr="0x080486fd",func="f<1>()",file="LinuxProject10.cpp",fullname="/tmp/VisualGDB/e/PROJECTS/TEMP/LinuxProject10/LinuxProject10/LinuxProject10.cpp",line="7"},{number="4.2",enabled="y",addr="0x08048707",func="f<2>()",file="LinuxProject10.cpp",fullname="/tmp/VisualGDB/e/PROJECTS/TEMP/LinuxProject10/LinuxProject10/LinuxProject10.cpp",line="7"}

Your output looks different. Which platform/GDB version are you using?

Regarding path mapping, here’s a sample path mapping that maps /tmp/test to c:something:
[attachment=1:1xtzhfzt]pathmapping.png[/attachment:1xtzhfzt]
Here’s how the /tmp/test/test.h is mapped to c:somethingtest.h:
[attachment=0:1xtzhfzt]sourcelist.png[/attachment:1xtzhfzt]

Does it work for you with exactly the same paths? Do you have any symbolic links involved (e.g. /tmp is mapped to /system/tmp and while you set /tmp, GDB reports it as /system/tmp)?

If a breakpoint shows as resolved but is not hit, does the code at the address reported by GDB match the expected function body (e.g. is it equivalent to the disassembly of your ELF file)? If yes, does placing a manual breakpoint there (asm (“int3”); if you are using GCC) work? Can the memory be write-protected so that GDB fails to set the breakpoint?

Are you running GDB on your target machine or are you using a gdbserver? Are you using a .vgdbsettings file or quick debug?

[support]

Hi,

The sources don’t need to be copied the the debug machine. Does the breakpoint reply contain the address it was resolved to or is it marked as ‘pending’? Can you send us the full GDB log? This will help us diagnose the problem further.
The manual mapping should work with any path prefix (try restarting debug session if it’s not updated immediately). E.g. if you want to map /usr/buildmachineproject/code/somefolder to c:projectcodesomefolder, you need to create the following mapping:

Linux path: /usr/buildmachineproject/code
Windows path: c:projectcode

If this still does not work, please send us the screenshots of your source file mapping window and the window showing incorrectly mapped paths.

[support]

Hi,

Your mapping seems to be set correctly and should work. Please follow the instructions below to diagnose it:
1. In the GDB Session window select ‘all GDB interaction’ so that VisualGDB shows the commands it sends to GDB automatically.
2. Set a breakpoint in a problematic file. VisualGDB will issue a -break-insert command. GDB will report whether it has been resolved.
3. If the breakpoint shows as unresolved, please run the following commands:
* info shared – this will show the loaded shared libraries. Ensure that the library that contains your code is loaded.
* info sources – this will list all source files known to GDB

If your library is not listed in the output of ‘info shared’ it has not been loaded yet, so please ensure it gets loaded and then repeat setting the breakpoint. If the library is shown and has the symbols loaded, but the ‘info sources’ does not list your source file among the source files, there is some problem with your symbols (either GCC is a lot newer or older than GDB or you are missing the -ggdb flag or you are stripping some symbols during build). If the file is shown, please compare the exact path of the file reported by ‘info sources’ with the path that VisualGDB used in the ‘-break-insert’ command. If they don’t match, you need to adjust the path mapping until they match.

[support]

Hi,

By design this should not happen. However in some cases (e.g. MacOS where /tmp is a symbolic link to /private/tmp) the path reported by GDB can be different from the path used to transfer/build files, so VisualGDB won’t detect that it’s mapped.

Does the problem reproduce if you create a new project from scratch? Could you please send us the .vgdbsettings file from that project? Could you also provide us with a GDB log (select ‘all GDB interaction’ in the GDB Session window)?

[support]

Hi,

This looks very strange. Could you please start GDB manually and run the following commands:

b main
run

Will the breakpoint be hit? If yes, please run GDB in MI mode (gdb –interpreter mi ) and run the following commands:

-break-insert main
-exec-run

Will this break in main()? In either case please provide us with the relevant GDB logs so that we could diagnose the problem further.

BTW, are you building a 32-bit version of the app or a 64-bit version? You may need to specify ‘-arch xxx’ in GDB command-line arguments to select the bitness manually.

[support]

Hi,

It’s hard to tell where you got all the malware you are mentioning, but certainly not from the WinCDEmu site. Unlike many other vendors we don’t embed any toolbars or adware in WinCDEmu. WinCDEmu is supported purely through ads on its website and download page. You may have clicked at an ad that linked to some adware; if you believe it’s a malware, please give a link to the site you downloaded it from to Google AdSense support so that they can ban it.

[support]

Hi,

Yes, this would require quite a lot of effort making a new generator for CMake. Currently we have no plans of doing that, however if anyone from the community volunteers to provide such support, we will provide them as much help as we can.

Note that the .vgdbsettings file also contains debugging settings, so it’s hard to generate it purely based on the cmake file.

[support]

Hi,

You need to install the SSH server on Ubuntu:

sudo apt-get install openssh-server
sudo service ssh start

[support]

Hi,

What level of CMake support would you like? Just wizard/makefile updating or something more specific?

[support]

Hi,

The problem is that printf() inside itself uses ‘double’. Although you pass a float there, it reads ‘%f’ in your string and somehow converts it to double. You cannot change this behavior by modifying your program as it is located inside the printf() that is a part of the standard library. You could either modify the standard library used by GCC (which is somewhat cumbersome), or simply use another open-source implementation of printf() (there should be plenty of those available online).

[support]

Hi,

This problem means that the standard C library has been compiled in a way that treats the ‘%f’ format in a way that uses the double type. We would recommend simply using an alternative implementation of sprintf() from some open-source library and tweaking it so that it only uses the float type.

[support]

Hi,

Unfortunately this is a limitation of Windows. Although we could workaround it by using UNC names internally, Visual Studio will still not be able to open those files. Please note that this should not affect your build: the kernel is built on the Linux system and those files will simply not be overwritten. Please let us know if you encounter some of files with reserved names that are essential for debugging. We will then add support for renaming them during import (e.g. con_.h) and seamlessly mapping the names during file transfer and debugging. This is bit cumbersome, however it looks like the only way to work around the Windows/VS limitation.

[support]

Hi,

Thanks for reporting it, we will include a fix in the next maintenance release.
Regarding VisualDDK, we have no current plans of releasing further versions, as Microsoft includes Visual Studio support in the latest WDK and many people consider VisualDDK obsolete. We may eventually invest in that direction, but certainly not within the next year, as we are now focusing on increasing usability of VisualGDB.

When we decided to stop active development of VIsualDDK, we made it open-source. If you are interested in making a VS2013-compatible version, you can simply use the source code and replace registry keys/assembly references. If you have any questions about building it, feel free to ask on the corresponding forum.

[support]

The current design supports two levels of nesting:
1. You can define register sets that support registers. This is implemented and fully supported.
2. You can define bit ranges inside each register. Each bit range can be mapped to a combo box with predefined values or a check box. This is supported by the VisualGDB back-end but we don’t have GUI for it yet.

Here’s the definition of the hardware register-related types in VisualGDB:

    public class HardwareSubRegister
{
public string Name;
public int FirstBit;
public int SizeInBits;

/// 


/// Only valid when contains array of (1 << SizeinBits) strings.

/// If set, instead of showing one of the actual integral values, a corresponding string

/// should be displayed and a combobox should be used.

/// 


public string[] KnownValues;



[XmlIgnore]

public HardwareRegister ParentRegister;

}



public class HardwareRegister

{

public string Name;

public int SizeInBits;

public string Address;          //0x...

public string GDBExpression;    //Optional, can be derived from Address

public bool ReadOnly;

public HardwareSubRegister[] SubRegisters;

}



public class HardwareRegisterSet

{

public string UserFriendlyName; //If not set, not displayed either

public HardwareRegister[] Registers;

}

Do you think this format supports all the grouping you need? If no, please give us an example of grouping that is not supported. If yes, please give us a sample XML file with the grouping you want so that we could add this feature to our GUI.

[support]

The problem most likely happens because your toolchain maps the file paths in a way unknown to VisualGDB.
Please use the ‘breakpoint diagnostics’ feature (see this tutorial for more details, it is about Linux, but it should be similar to your case). If the diagnostics feature does not help, please run the info sources command and post its output here so that we could help you with setting up file mapping.

[Author]

Posts