j.jemine

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 17 total)
  • Author
    Posts
  • in reply to: Imported Toolchain not Shown #27863
    j.jemine
    Participant

    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.

    in reply to: Imported Toolchain not Shown #27806
    j.jemine
    Participant

    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, 8 months ago by j.jemine.
    • This reply was modified 4 years, 8 months ago by j.jemine.
    in reply to: Imported Toolchain not Shown #27803
    j.jemine
    Participant

    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, 8 months ago by j.jemine.
    • This reply was modified 4 years, 8 months ago by j.jemine.
    in reply to: Imported Toolchain not Shown #27802
    j.jemine
    Participant

    Sure

     

    in reply to: Unable to use WSL #27790
    j.jemine
    Participant

    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, 8 months ago by j.jemine.
    in reply to: Unable to use WSL #27788
    j.jemine
    Participant

    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.

    in reply to: Unable to use WSL #27786
    j.jemine
    Participant

    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, 8 months ago by j.jemine.
    in reply to: Instabilities with cmake #27784
    j.jemine
    Participant

    This is great ! Thanks !

    j.jemine
    Participant

    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.

    in reply to: Feature request: user name variable #8911
    j.jemine
    Participant

    Good to know 🙂

    Perfect, thanks!

    in reply to: Embedded thread and remote compilation #8135
    j.jemine
    Participant

    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!

    in reply to: Embedded thread and remote compilation #8120
    j.jemine
    Participant

    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!

    in reply to: Embedded thread and remote compilation #8102
    j.jemine
    Participant

    My gdb executable is also on Linux only

    in reply to: User variables expansion in #7383
    j.jemine
    Participant

    It works, thanks.

    in reply to: Makefile's and SourceControl integration #7375
    j.jemine
    Participant

    Ok thank you !

Viewing 15 posts - 1 through 15 (of 17 total)