Forum Replies Created
-
Posts
-
I also see that the $(DeployDir) when used in my custom shortcuts seems fixed at /tmp and does not change with Debug Settings -> Deployment -> Base Deployment Directory. I don’t see where /tmp is set anywhere else, so I’m assuming $(DeployDir) is tied to that field, but maybe not? I don’t see $(DeployDir) mentioned here: (https://visualgdb.com/documentation/variables/)
Thanks. I can see that DeployHost is properly populated. However, if I change the value of DeployHost to a new host (using the host aliases GUI), and then re-run my custom shortcut script, it continues to expand to the old value until I unload and reload the project. Is this the expected behavior?
I can work around getting that dialog coming up each time with the ‘full custom’ setup.
Unfortunately, to get that to work I have to fill out the ‘Target selection command:”, and the macro for my host alias “TargetMachine” does not seem to be accessible, so I have to hardcode my debug target name in there. That won’t work well for a group of developers, I don’t think.
I have noticed that host aliases also don’t seem to be available when writing temporary scripts in custom shortcuts or post-build rules, etc. That would be useful.
Clearing the ‘debugged’ executable field causes a dialog to come up that says:
“The project settings are not configured to debug the startup or selected target. Do you want to fix the debug settings?”
Answering yes puts you back where you started, and No works, but you get prompted every time you try to debug. Can we get that to stop happening?
I can also put the full path to mono in the SDK sysroot (the mono that actually on the target), and this also seems to work, so it clearly doesn’t like pointing to the /usr/bin/mono on the build machine.
OK, in order to make the command line version fail, all I need to do is pass the gdb argument –args “/usr/bin/mono”. The –interpreter argument doesn’t matter.
dwstark@earthtux:~$ $GDB --args "/usr/bin/mono" GNU gdb (GDB) 11.2 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-keysight-linux --target=aarch64-keysight-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/mono... (No debugging symbols found in /usr/bin/mono) (gdb) target remote ffox-fluyt-npi03:2201 Remote debugging using ffox-fluyt-npi03:2201 warning: Build ID mismatch between current exec-file /usr/bin/mono and automatically determined exec-file /usr/bin/mono-sgen exec-file-mismatch handling is currently "ask" Load new symbol table from "/usr/bin/mono-sgen"? (y or n) y Reading symbols from /usr/bin/mono-sgen... (No debugging symbols found in /usr/bin/mono-sgen) Reading /lib64/ld-linux-x86-64.so.2 from remote target... warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. 0x0000fffff7fd9cc0 in ?? () (gdb) b MSDriver_CreateDriver Function "MSDriver_CreateDriver" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (MSDriver_CreateDriver) pending. (gdb) c Continuing. Warning: Cannot insert breakpoint -1. Cannot access memory at address 0x2cf80 Command aborted. (gdb)
Note that the same SDK is configured in the CMake tab of VisualGDB project properties as is sourced in the above command line example that works.
dwstark@earthtux:~$ export | grep SYSROOT declare -x OECORE_NATIVE_SYSROOT="/opt/ffox/qjet/ffox-instrument/4.0-2.0.0/sysroots/x86_64-keysight-linux" declare -x OECORE_TARGET_SYSROOT="/opt/ffox/qjet/ffox-instrument/4.0-2.0.0/sysroots/cortexa53-keysight-linux" declare -x PKG_CONFIG_SYSROOT_DIR="/opt/ffox/qjet/ffox-instrument/4.0-2.0.0/sysroots/cortexa53-keysight-linux" declare -x SDKTARGETSYSROOT="/opt/ffox/qjet/ffox-instrument/4.0-2.0.0/sysroots/cortexa53-keysight-linux" dwstark@earthtux:~$ ls -la /opt/ffox/qjet/ffox-instrument/current lrwxrwxrwx 1 root root 9 Aug 15 15:19 /opt/ffox/qjet/ffox-instrument/current -> 4.0-2.0.0/ dwstark@earthtux:~$
Thank you. I will look into symbols for the loader library.
In the mean time, I notice that I gdb works if I just run it manually. I can attach to the remote, set a breakpoint in my .so, run to the breakpoint, and then continue. Seems like that should not work according to what you have said above.
On the target:
ffox-fluyt-npi03:/tmp/test$ gdbserver :2201 /usr/bin/mono /tmp/test/ffox2.exe --run-native Process /usr/bin/mono created; pid = 32464 Listening on port 2201
On the build machine:
dwstark@earthtux:~$ $GDB GNU gdb (GDB) 11.2 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-keysight-linux --target=aarch64-keysight-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) target remote ffox-fluyt-npi03:2201 Remote debugging using ffox-fluyt-npi03:2201 Reading /usr/bin/mono-sgen from remote target... warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. Reading /usr/bin/mono-sgen from remote target... Reading symbols from target:/usr/bin/mono-sgen... Reading /usr/bin/.debug/mono-sgen from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug//usr/bin/mono-sgen from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/usr/bin//mono-sgen from remote target... Reading target:/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/usr/bin//mono-sgen from remote target... (No debugging symbols found in target:/usr/bin/mono-sgen) Reading /lib/ld-linux-aarch64.so.1 from remote target... Reading /lib/ld-linux-aarch64.so.1 from remote target... Reading symbols from target:/lib/ld-linux-aarch64.so.1... Reading /lib/.debug/ld-linux-aarch64.so.1 from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug//lib/ld-linux-aarch64.so.1 from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/lib//ld-linux-aarch64.so.1 from remote target... Reading target:/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/lib//ld-linux-aarch64.so.1 from remote target... (No debugging symbols found in target:/lib/ld-linux-aarch64.so.1) 0x0000fffff7fd9cc0 in ?? () from target:/lib/ld-linux-aarch64.so.1 (gdb) b MSDriver_CreateDriver Function "MSDriver_CreateDriver" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (MSDriver_CreateDriver) pending. (gdb) c Continuing. Reading /lib/libz.so.1 from remote target... Reading /lib/libm.so.6 from remote target... Reading /lib/libc.so.6 from remote target... Reading /lib/libz.so.1.2.11 from remote target... Reading /lib/.debug/libz.so.1.2.11 from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug//lib/libz.so.1.2.11 from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/lib//libz.so.1.2.11 from remote target... Reading target:/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/lib//libz.so.1.2.11 from remote target... Reading /lib/.debug/libm.so.6 from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug//lib/libm.so.6 from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/lib//libm.so.6 from remote target... Reading target:/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/lib//libm.so.6 from remote target... Reading /lib/.debug/libc.so.6 from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug//lib/libc.so.6 from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/lib//libc.so.6 from remote target... Reading target:/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/lib//libc.so.6 from remote target... Reading /usr/lib/../lib/libmono-native.so from remote target... Reading /usr/lib/../lib/libmono-native.so.0.0.0 from remote target... Reading /usr/lib/../lib/.debug/libmono-native.so.0.0.0 from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug//usr/lib/../lib/libmono-native.so.0.0.0 from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/usr/lib/../lib//libmono-native.so.0.0.0 from remote target... Reading target:/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/usr/lib/../lib//libmono-native.so.0.0.0 from remote target... Reading /lib/libpthread.so.0 from remote target... Reading /lib/.debug/libpthread.so.0 from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug//lib/libpthread.so.0 from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/lib//libpthread.so.0 from remote target... Reading target:/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/lib//libpthread.so.0 from remote target... Reading /tmp/test/libmsdriver.so from remote target... Reading /usr/lib/libstdc++.so.6 from remote target... Reading /lib/libgcc_s.so.1 from remote target... Reading /usr/lib/libstdc++.so.6.0.29 from remote target... Reading /usr/lib/.debug/libstdc++.so.6.0.29 from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug//usr/lib/libstdc++.so.6.0.29 from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/usr/lib//libstdc++.so.6.0.29 from remote target... Reading target:/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/usr/lib//libstdc++.so.6.0.29 from remote target... Reading /lib/.debug/libgcc_s.so.1 from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug//lib/libgcc_s.so.1 from remote target... Reading /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/lib//libgcc_s.so.1 from remote target... Reading target:/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-keysight-linux/usr/lib/aarch64-keysight-linux/debug/lib//libgcc_s.so.1 from remote target... [New Thread 32464.32470] [New Thread 32464.32471] Thread 1 "mono" hit Breakpoint 1, MSDriver_CreateDriver () at /home/dwstark/VisualGDB/ffox-2/native/msdriver/msdriver.cpp:18 18 msdriver::MSDriver* p = new msdriver::MSDriver(); (gdb) c Continuing. warning: Temporarily disabling breakpoints for unloaded shared library "target:/tmp/test/libmsdriver.so" [Inferior 1 (process 32464) exited normally] (gdb)
I have a related issue where I see the same failure, but the reproduction is different. I installed 5.5.7.3685 (still VS2017), and enabled the diagnostics console.
The reproduction is to load the .sln with the .vgdbcmake project. Then run the shortcut that copies files. SysprogsSync is set up. It works. Then, reboot the target machine. Once it comes back up. Re-run the shortcut. It fails. See attached log vgdb_dump1.txt. I then try testing the SSH connection to my target, which works, and re-run the shortcut. It fails in the same way. I then unload/reload the .vgdbcmake project in my .sln, and re-run the shortcut. It works (log in vgdb_dump2.txt). That log shows some similar failures, but the shortcut reports success in the GUI and it does work
Hopefully this can help identify why rebooting the target breaks the copying shortcut until one reloads the visual gdb project.
sshd is pretty recent.
root@ff:/tmp# sshd –version
OpenSSH_7.9p1, OpenSSL 1.1.1g 21 Apr 2020I was able to run:
$ ssh root@ff “ln -s /usr/lib/mytargetname.so.1.2 /tmp/mylinkname.so”
successfully from a MINGW64 bash shell against the target machine. So… sshd seems OK with ssh command mode. Not sure why VisualGDB’s ssh client cannot do the same?
I can verify that an executable shell script /tmp/test can be run with a shortcut
Command: /tmp/test
Directory: /tmp
and it successfully runs the script that creates the link.
Thanks.
I went through the manual SysprogsSync setup process since I was getting prompted about that – apparently with the directory deploys. After setting that up, so far no issues. Fingers crossed. Not sure why *not* setting that up was causing this issue, though.
Build 3009 works better, but now the deploy of my managed exe doesn’t seem to work, failing with a LIBSSH2_ERROR_SCP_PROTOCOL error.
The output window shows:
VisualGDB: Executing predebug actions VisualGDB: Copy file C:\tf\ws1\cmaketest\VS15Linux\ManagedExe\Debug\ManagedExe.exe on local computer to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/ManagedExe.exe on wilvm1 VisualGDB: Copy file /usr/bin/../libShared/libShared.so on wilvm1 to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/libShared.so on wilvm1 VisualGDB: Error: LIBSSH2_ERROR_SCP_PROTOCOL while trying to download /usr/bin/../libShared/libShared.so VisualGDB: Executing postdebug actions VisualGDB: Executing predebug actions VisualGDB: Copy file C:\tf\ws1\cmaketest\VS15Linux\ManagedExe\Debug\ManagedExe.exe on local computer to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/ManagedExe.exe on wilvm1 VisualGDB: Copy file /usr/bin/../libShared/libShared.so on wilvm1 to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/libShared.so on wilvm1 VisualGDB: Error: LIBSSH2_ERROR_SCP_PROTOCOL while trying to download /usr/bin/../libShared/libShared.so VisualGDB: Executing postdebug actions VisualGDB: Executing predebug actions VisualGDB: Copy file C:\tf\ws1\cmaketest\VS15Linux\ManagedExe\Debug\ManagedExe.exe on local computer to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/ManagedExe.exe on wilvm1 VisualGDB: Copy file /usr/bin/../libShared/libShared.so on wilvm1 to /tmp/VisualGDB/dwstark/cmaketest/VisualGDB/Debug/libShared.so on wilvm1 VisualGDB: Error: LIBSSH2_ERROR_SCP_PROTOCOL while trying to download /usr/bin/../libShared/libShared.so VisualGDB: Executing postdebug actionse output window shows:
Not sure why SSH would not work for these pre-debug copy actions. I can delete the directory on the Linux VM, and VGDB will automatically replace the files for the synchronized directory, so it clearly has SSH access.
Any suggestions?
Also, with your updated build, if I do try to debug by right-clicking the mono target -> Debug -> Start new instance, I get an error (attachment) that references the “Visual GDB Launcher output” window, but that window is not there (attachment). I have seen this type of error previously, and there was a window with actual output before. Some somehow it is not hooked up in this build for for this particular error. (this is using the 3006 and 3008 builds)
I installed your updated version, and then followed steps 1 and 2. At step 3, the VS project properties for my /usr/bin/mono solution tree node that was added in step 1 (under the .vgdbcmake project node) does not have any properties in it (attached).
I think this is the properties box you mean… I don’t see anyplace else to put in command line arguments…
A bit more detail… My “test” setup has a single VisualGDB (.vgdbcmake) “project” that has a native EXE and native .so being built by VisualGDB. The solution has a managed C# EXE project as well that I want to use as the test-harness for the .so. The native EXE is just there as a test to be sure I can do all-native debugging of my .so (this works great).
I did finally get this to work by doing the following:
- using custom debug steps (before launching debugger) to
- copy my managed EXE to my Linux Target
- copy my native .so to the same directory
- Set the debug settings to:
- Use mono as the debugged executable.
- Sets the managed EXE as the argument (at the location I copied it to)
Then I have to right-click on the .so node in the .vgdbcmake project and choose Debug-> Start New Instance. Then I get a message that says “The project debug settings are not configured to debug the startup or selected target. Do you want to fix the debug settings? (Yes/No)” If you say ‘yes’ here, my settings above are overwritten . So “No”. Then I see: “The project debug settings are not configured to inherit the per-target working directory/program arguments specified via VS Properties. Do you want to fix the debug settings? (Yes/No). Again, “No” for the same reason.
Then it does start up and hit my breakpoint in the .so.
But… this is a bit of a painful startup procedure!
If I remove the native EXE (as VisualGDB seems to really want to use that as the startup EXE), then when I do the Debug->Start New Instance on the .so, I see: “No startup target defined for CMake project. Please define a startup target by right-clicking on it. (“OK”). And then nothing.
- using custom debug steps (before launching debugger) to
