- This topic has 7 replies, 2 voices, and was last updated 2 years, 3 months ago by
.
-
Posts
-
Hi,
I’m trying to do some test with qemu, but there seems to be some problem.
My config is shown in the attachment. QEMU runs on a linux virtual machine(192.168.0.150) and listens to port 6034. The ssh port is 6022.
Firstly, when setting up the ssh connection, the “set up public key authenation” box seems not working. When clicking the terminal button on the right side, it says the public key is not working and asks me to input my password. And I can’t find a way to edit existing connections.
Then the gdb connection uses incorrect address. It puts the GDB port directly after the ssh port. Here’s the log:
-target-select remote 192.168.0.150:6022:6034
&"192.168.0.150:6022:6034: cannot resolve name: No such host is known. \n"
192.168.0.150:6022:6034: No such file or directory.Also, I’m confused about the “working directory”. Does visual gdb copy the binary to the working directory? Or I need to copy it manually?
Thanks
Hi,
If the public key authentication is not working with a specific machine, it is likely disabled on the SSH server side. You can troublehsoot it by verifying your SSH server configuration/logs.
Indeed, the “Custom GDB Stub” mode does not strip the port from the host name. As a workaround, please try using the “Full-custom mode”. It allows defining the target selection command explicitly.
The “working directory” setting refers to the directory where the custom command is started and does not affect anything else. If you would like to automatically copy any files before debugging, you can explicitly add a custom pre-debug action via VisualGDB Project Properties -> Custom Debug Steps.
Hi,
The public key is caused by ssh server config. And it’s working now.
For the target selection command, I’m still having trouble with “full-custom mode”. The target is always “local computer”. If I change it to SSH, it reverts to local computer when I click “Apply”.
Thanks
The target is the machine where you would like to physically run gdb and is usually to the build machine to avoid confusion (there is a checkbox on the Project Settings page to override it). In this case, it should be the local machine. In order to manually connect to QEMU, please try entering “target remote <host>:<port>” into the target selection command field.
Seems that in full-custom mode I have to launch QEMU by myself or by some script since it only runs gdbstub on local computer.
But anyway, I’ve solved the problem by changing the SSH port to 22, so I can connect without the port in host name.
It is hard to say why it wouldn’t work without the full context, as VisualGDB should normally automatically strip the custom port from the host name. If setting the SSH port to 22 works, it should be a reasonable workaround.
If not (or if anyone else encounters a similar issue), please feel free to share the repro steps per our problem reporting guidelines and we will investigate this further.
Hi,
My problem can be solved by using port 22.
The following is my environment.
Visual GDB version is 5.6R8
I’m using Embedded project, with a custom BSP. But the problem can be reproduced from regular STM32 BSP.
QEMU is the latest source code built with
../configure –enable-debug –disable-werror –target-list=”arm-softmmu” –without-default-features –enable-user
The config for remote gdb stub is in the first floor.
And here’s a video of the steps to reproduce the issue.
Thanks for the detailed video. Indeed, the logic for automatically stripping the SSH port worked for the Linux projects, but not for the embedded projects (building the project locally while debugging it with a remote stub running on a target with a custom SSH port is an extremely rare scenario).
We have fixed it in the following build: VisualGDB-5.6.108.4714.msi
- You must be logged in to reply to this topic.