[support]

Hi,

Thanks, we will add this to our knowledge base.

Regarding ‘bt’, we use –stack–list–frames simply because it returns structured output that can be easily parsed; with ‘bt’ it could be tricky to separate arguments from function names, etc (e.g. when having namespaces and templates). If you believe using ‘bt’ makes a substantial difference, we could add a method to our extensibility API to replace the normal ‘list frames’ operation and you can experiment with writing a plugin based on the ‘bt’ command.

[support]

Hi All,

We have investigated this further and it looks like one of the recent OpenSSL releases broke backward compatibility in the logic related to RSA keys. We have rebuilt the libssh2 library using an older OpenSSL and it should work normally.
Please try this build: VisualGDB-5.2.11.1187.msi

[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.

[Author]

Posts