[j.jemine]

Hi,

Sorry for the delay, I was unable to work for a few days.

I now have this problem that I didn’t seem to have before everytime I click the “Ok” or “Apply” button in the VisualGDB project settings dialog.

[j.jemine]

Update:

If I select “Legacy” instead of “Use default distribution (Legacy)” for the WSL distribution box, the toolchain seems correctly created and appears in the combo box. But I then have a “Please select a remote toolchain” error message.

If I switch the combo boxes to another option and back to my toolchain, the error message disappear and I can click next.

However, I then have this error:

VisualGDB version: 5.5.4.3559
Tool arguments:
/tmp/VisualGDB_ToolchainTestProgram: 1: /tmp/VisualGDB_ToolchainTestProgram: Syntax error: word unexpected (expecting “)”)

It seems to be caused by the fact that my toolchain doesn’t have C++ :

Using built-in specs.
Target: sparc-rtems4.8
Configured with: ../gcc-4.2.1/configure –target=sparc-rtems4.8 –with-gnu-as –with-as=/home/jj/rtems/bin/binutils-2.18/bin/sparc-rtems4.8-as –with-gnu-ld –with-ld=/home/jj/rtems/bin/binutils-2.18/bin/sparc-rtems4.8-ld –with-newlib –verbose –enable-threads –enable-languages=c –prefix=/home/jj/rtems/bin/gcc-4.2.1
Thread model: rtems
gcc version 4.2.1
sparc-rtems4.8-gcc: language c++ not recognized
sparc-rtems4.8-gcc: language c++ not recognized
sparc-rtems4.8-gcc: -: linker input file unused because linking not done
/tmp/VisualGDB_ToolchainTestProgram.c:1:95: warning: no newline at end of file
/home/jj/rtems/bin/binutils-2.18/bin/sparc-rtems4.8-ld: warning: cannot find entry symbol _start; not setting start address
/tmp/VisualGDB_ToolchainTestProgram: 1: /tmp/VisualGDB_ToolchainTestProgram: Syntax error: word unexpected (expecting “)”)

 

If I ignore the error, I seem to have a working project, but it uses the system toolchain instead of mine:

…\VisualGDB\Debug\CMakeFiles\3.15.2\CMakeCCompiler.cmake :

set(CMAKE_C_COMPILER "/usr/bin/cc")
set(CMAKE_C_COMPILER_ARG1 "")
set(CMAKE_C_COMPILER_ID "GNU")
set(CMAKE_C_COMPILER_VERSION "5.4.0")
set(CMAKE_C_COMPILER_VERSION_INTERNAL "")
set(CMAKE_C_COMPILER_WRAPPER "")
set(CMAKE_C_STANDARD_COMPUTED_DEFAULT "11")
set(CMAKE_C_COMPILE_FEATURES "c_std_90;c_function_prototypes;c_std_99;c_restrict;c_variadic_macros;c_std_11;c_static_assert")
set(CMAKE_C90_COMPILE_FEATURES "c_std_90;c_function_prototypes")
set(CMAKE_C99_COMPILE_FEATURES "c_std_99;c_restrict;c_variadic_macros")
set(CMAKE_C11_COMPILE_FEATURES "c_std_11;c_static_assert")

set(CMAKE_C_PLATFORM_ID "Linux")
set(CMAKE_C_SIMULATE_ID "")
set(CMAKE_C_COMPILER_FRONTEND_VARIANT "")
set(CMAKE_C_SIMULATE_VERSION "")

set(CMAKE_AR "/usr/bin/ar")
set(CMAKE_C_COMPILER_AR "/usr/bin/gcc-ar-5")
set(CMAKE_RANLIB "/usr/bin/ranlib")
set(CMAKE_C_COMPILER_RANLIB "/usr/bin/gcc-ranlib-5")
set(CMAKE_LINKER "/usr/bin/ld")

...

 

• This reply was modified 4 years ago by j.jemine.
• This reply was modified 4 years ago by j.jemine.

[j.jemine]

Here is the CustomToolchain.xml created :

<?xml version="1.0"?>
<CustomToolchain xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Toolchain>
<UnixSystem>true</UnixSystem>
<RequireCtrlBreak>false</RequireCtrlBreak>
<ArgumentEscapingMode>Normal</ArgumentEscapingMode>
<Name>sparc-rtems4.8</Name>
<UniqueID>com.sysprogs.imported.sparc-rtems4.8</UniqueID>
<Location>/opt/sparc-rtems4.8/bin/sparc-rtems4.8-</Location>
<GCC>/opt/sparc-rtems4.8/bin/sparc-rtems4.8-gcc</GCC>
<GXX>/opt/sparc-rtems4.8/bin/sparc-rtems4.8-g++</GXX>
<GDB>/opt/sparc-rtems4.8/bin/sparc-rtems4.8-gdb</GDB>
<AR>/opt/sparc-rtems4.8/bin/sparc-rtems4.8-ar</AR>
<OBJCOPY>/opt/sparc-rtems4.8/bin/sparc-rtems4.8-objcopy</OBJCOPY>
<Make>make</Make>
<ShellMode>Direct</ShellMode>
</Toolchain>
<Type>Linux</Type>
<Target>sparc-rtems4.8</Target>
<Version>
<GCC>4.2.1</GCC>
<GDB>6.6</GDB>
<Revision>0</Revision>
</Version>
<IsShared>false</IsShared>
</CustomToolchain>

• This reply was modified 4 years ago by j.jemine.
• This reply was modified 4 years ago by j.jemine.

[j.jemine]

Sure

 

[j.jemine]

Wow, that was quick 🙂

EDIT: I had a problem but it was my mistake. I think it’s working. It’s pretty late here, I’ll keep you updated.

• This reply was modified 4 years ago by j.jemine.

[j.jemine]

Oh I see, it’s because we’re still running on Windows 1803, and the arguments to WSL have changed in 1903.

For this particular command, it just works if I remove the “–“. I don’t know if that would fix every use case of WSL by VisualGDB ?

Could VisualGDB detect the version of wsl.exe and use “–” only when required ?

Thanks.

[j.jemine]

Here is the output of the compilation command

C:\Users\jj>C:\windows\system32\wsl.exe -- gcc -std=gnu99 "/mnt/c/Program Files (x86)/Sysprogs/VisualGDB/TargetTools/LinuxAppLauncher.c" -o /tmp/LinuxAppLauncher-v3 -lutil
/bin/bash: --: invalid option
Usage: /bin/bash [GNU long option] [option] ...
/bin/bash [GNU long option] [option] script-file ...
GNU long options:
--debug
--debugger
--dump-po-strings
--dump-strings
--help
--init-file
--login
--noediting
--noprofile
--norc
--posix
--rcfile
--restricted
--verbose
--version
Shell options:
-ilrsD or -c command or -O shopt_option (invocation only)
-abefhkmnptuvxBCHP or -o option

• This reply was modified 4 years, 1 month ago by j.jemine.

[j.jemine]

This is great ! Thanks !

[j.jemine]

I was having the problem when adding a new project to an existing solution.

It worked when I created the same project in a blank environment. I then copy-pasted the .vgdbsettings files.

[j.jemine]

Good to know 🙂

Perfect, thanks!

[j.jemine]

Hi,

It’s almost working:

• My virtual threads are correctly enumerated in the ‘Threads’ window
• The displayed callstack of each thread is the callstack of the thread that reached the breakpoint (same story for the program counter).
• It feels slow, breaking into the code takes significantly more time, but I think it’s not VisualGDB’s fault: the interactions with the GDB stub are slow.

I’m going to debug my GetSavedRegisters() method to be sure that I’m returning correct values.

I’m guessing that you’re giving the register values to GDB to produce a callstack ? Could you give me a little more details about this so I can try to reproduce the process manually ?

I think that I probably have a mismatch between the name of the registers that I give and what GDB expects.

 

Another question:

Since my GDB stub is slow, I’d like to avoid calling IGlobalExpressionEvaluator.EvaluateIntegralExpression too often.

Are my VirtualThread re-used between debug breaks ? Or is IVirtualThreadProvider.GetVirtualThreads called everytime that I break into the code ? (in which case I could use a single lazy evaluation for each thread)

 

Thanks for your time!

[j.jemine]

Hi,

Is there any reason you cannot setup a locally built project for your target?

We’re working with a space qualified RTEMS toolchain, re-compiling it for Windows would break the qualification. We can only work with the provided qualified Linux binaries.

 

We could also add experimental support for virtual threads to Linux projects if this helps.

Yes, that would be perfect!

[j.jemine]

My gdb executable is also on Linux only

[j.jemine]

It works, thanks.

[j.jemine]

Ok thank you !

[Author]

Posts