Tagged: gdb remote
September 5, 2022 at 11:02 #33122
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?
Attachments:You must be logged in to view attached files.September 6, 2022 at 13:49 #33130
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.September 7, 2022 at 04:30 #33133
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”.
Attachments:You must be logged in to view attached files.September 7, 2022 at 08:17 #33138
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.September 8, 2022 at 04:08 #33145
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.September 8, 2022 at 12:15 #33150
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.September 9, 2022 at 08:41 #33164
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.September 15, 2022 at 09:34 #33197
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-126.96.36.19914.msi
You must be logged in to reply to this topic.