[support]

Hi,

This might be some sort of plugin interference. Can you try doing the same on a different machine with a clean VS installation (or under a different user account on the same machine)? If the behavior is not reproduced, please try disabling other VS plugins. If this solves the problem, please try enabling them one-by-one to see which one causes the issue.

[support]

Hi,

Perhaps this is a different issue? Could you please attach a screenshot so that we could see if this can be reproduced?

[support]

Hi,

Most likely the problem you are observing happens because you run the ‘c’ command in the GDB console window instead of using the Visual Studio GUI to continue execution (F5). This breaks synchronization between VS and the GDB session and makes your debug session look it is hanging.

We understand that it might be confusing, so we have added support for parsing and redirecting the c, n, s and f commands to the upcoming VisualGDB 5.2 beta 3.

If you want to always load some extra symbols before debugging, you can add those commands to the Additional GDB Commands page of VisualGDB Project Properties or use the interactive mode of the Quick Debug command to run any custom commands you want in the console mode and then let VisualGDB take control once everything is set up.

[support]

Hi,

Thanks for confirming this. Looks like either something in your project prevents this optimization from turning on, or some other VS extension is requesting information about all threads.

Typically doing a single step even in a multi-threaded environment should result in something like this:

-stack-select-frame 0
^done
-thread-select 1
^done,new-thread-id="1",frame={level="0",addr="0x00000000004008d4",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffeb48"}],file="LinuxProject3.cpp",fullname="/tmp/VisualGDB/f/PROJECTS/TEMP/LinuxProject3/LinuxProject3.cpp",line="7"}
-exec-next
^running
*running,thread-id="all"
*stopped,reason="end-stepping-range",frame={addr="0x00000000004008ef",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffeb48"}],file="LinuxProject3.cpp",fullname="/tmp/VisualGDB/f/PROJECTS/TEMP/LinuxProject3/LinuxProject3.cpp",line="8"},thread-id="1",stopped-threads="all",core="0"
-stack-list-frames --thread 1
^done,stack=[frame={level="0",addr="0x00000000004008ef",func="main",file="LinuxProject3.cpp",fullname="/tmp/VisualGDB/f/PROJECTS/TEMP/LinuxProject3/LinuxProject3.cpp",line="8"}]
-stack-list-arguments --thread 1 0
^done,stack-args=[frame={level="0",args=[name="argc",name="argv"]}]

Could you please check if you get more than one “-stack-list-frames” command per step with this basic program and your toolchain:

#include <iostream>
#include <pthread.h>
#include <unistd.h>

using namespace std;

void *thread(void *)
{
    for (;;)
    {
        usleep(100000);        
    }
}

int main(int argc, char *argv[])
{
    pthread_t thr;
    pthread_create(&thr, 0, thread, 0);
    char sz[] = "Hello, World!";    //Hover mouse over "sz" while debugging to see its contents
    cout << sz << endl;    //<================= Put a breakpoint here
    for (;;)
    {
        usleep(100000);        
    }
    return 0;
}

[support]

Hi,

Perhaps the linker just reports the wrong function? Please try relocating ALL the functions from _divdi3.o in libgcc.a

[support]

Hi,

You can do that by creating another project with the new toolchain and copying the ToolchainID value from its stm32.xml file to the old project’s stm32.xml.

[support]

Hi,

Please try resetting the Visual Studio fonts & colors cache by deleting the HKCU\Software\Microsoft\VisualStudio\14.0\FontsAndColors\Cache key.

This should force VS to reload the correct colors.

[support]

Hi,

You can try using the tty command.

[support]

Hi,

Strange. Could you post the entire error message and a few lines above/below?

[support]

Hi,

Yes, the biggest feature from the Custom edition is the integrated unit test support. It also supports advanced real-time watch and many other usability features.

You can find a full list of the Custom edition features here: http://visualgdb.com/buy/custom

[support]

Hi,

Sorry, checked the std::printf() instead of std::snprintf(). Yes, our toolchain indeed does not have _GLIBCXX_USE_C99 and  _GLIBCXX_USE_C99_MATH_TR1 enabled (which is the default configuration for GCC), so those functions are not available under the std:: namespace.

You should be still able to use them via the regular C syntax (e.g. snprintf(…) or nanf(…)).

[support]

Hi,

Sorry, tried reproducing that with “f:\projects\temp\EmbeddedProject-16” and did not get anything to fail. Perhaps the problem is triggered by something else? Could you please clarify which wizard and what other settings were you using?

The new Beta 2 was indeed not handling relative paths in the “NMake output” properly. We have fixed this in the development branch and will include this fix in Beta 3.

Can you verify that the Threads window in Visual Studio is closed when you get the multiple ‘-stack-list-frames’ commands?

[support]

Hi,

We have added this feature to the v5.2 version. Please try the latest VisualGDB 5.2 Beta 2. You can switch the toolchain on the Makefile Settings page of your VisualGDB Project Properties.

[support]

Hi,

Perhaps this is something auto-generated by the compiler? Please try reverting the settings to a point when the code builds successfully, enable the generation of Map files and check the .map file for any references to ‘_udivmoddi4’. It should mention the .o or .a file that contains the function.

[support]

Hi,

You can configure VisualGDB to upload that extra directory by adding a custom pre-build step to your project (requires Custom edition or higher). Alternatively you can create a dummy Linux project that will have that directory selected as the main source directory and won’t actually build anything. Then each time Visual Studio tries to build that project, the directory will be uploaded automatically.

[Author]

Posts