Can't communicate from Qt Creator to remote gdbserver
-
I posted to Stack Overflow yesterday - replicating here. To view the pictures, follow the link to SO (https://stackoverflow.com/questions/47560895/qt-creator-4-5-beta-cant-make-connection-to-gdbserver)
I've been setting up remote debugging for an embedded Linux target. I've tested that I have the correct combination of gdbserver running on the target and gdb client running on my workstation. I can start the server and on the workstation side run:
(gdb) target remote 10.28.22.226:2345
and I can list source and step just fine.
In Qt Creator I have configured a device. In that window I specify the GDB server executable: gdbserver (see pic).
Devices setup
I also configure the cross debugger in the 'Build & Run' Debuggers tab as shown below:
Build & Run Debuggers setup
In this case, I have manually started the gdbserver with my executable on the target with port 2345. To start debugging with Qt Creator, I choose the Debug->Start Debugging->Attach to running Debug server pulldown menu. It gives me the prompt shown below, where I enter the server port (2345). I give it the appropriate kit and local executable (copy of the executable on the remote target).
Start Debugger dialog
After I hit OK, it seems to run the gdb client locally with a few commands, then times out trying to communicate with the gdbserver. I have debug logging turned on with the server, so I know the server never sees anything from the client run from Qt Creator. Additionally, I did Window->Views->Debugger Log to help me get a better idea of what was going on. The log shows the correct IP address and port for my device, but I don't see anything that looks like a 'target remote IP:port' call.
I'm looking for a hint or reference here. I seem to be a bit stuck at the moment. Thanks!
EDIT: additional information - I've verified that my gdb client has support for python compiled in. I see that Qt Creator requires python support. I also have further support that nothing ever goes out on the wire from Qt Creator. I did a wireshark capture and don't see anything going to port 2345 on the target.
Alternately, if anyone would share their Qt Creator debugger-log output with me so I can compare, that would be helpful.
-
I posted to Stack Overflow yesterday - replicating here. To view the pictures, follow the link to SO (https://stackoverflow.com/questions/47560895/qt-creator-4-5-beta-cant-make-connection-to-gdbserver)
I've been setting up remote debugging for an embedded Linux target. I've tested that I have the correct combination of gdbserver running on the target and gdb client running on my workstation. I can start the server and on the workstation side run:
(gdb) target remote 10.28.22.226:2345
and I can list source and step just fine.
In Qt Creator I have configured a device. In that window I specify the GDB server executable: gdbserver (see pic).
Devices setup
I also configure the cross debugger in the 'Build & Run' Debuggers tab as shown below:
Build & Run Debuggers setup
In this case, I have manually started the gdbserver with my executable on the target with port 2345. To start debugging with Qt Creator, I choose the Debug->Start Debugging->Attach to running Debug server pulldown menu. It gives me the prompt shown below, where I enter the server port (2345). I give it the appropriate kit and local executable (copy of the executable on the remote target).
Start Debugger dialog
After I hit OK, it seems to run the gdb client locally with a few commands, then times out trying to communicate with the gdbserver. I have debug logging turned on with the server, so I know the server never sees anything from the client run from Qt Creator. Additionally, I did Window->Views->Debugger Log to help me get a better idea of what was going on. The log shows the correct IP address and port for my device, but I don't see anything that looks like a 'target remote IP:port' call.
I'm looking for a hint or reference here. I seem to be a bit stuck at the moment. Thanks!
EDIT: additional information - I've verified that my gdb client has support for python compiled in. I see that Qt Creator requires python support. I also have further support that nothing ever goes out on the wire from Qt Creator. I did a wireshark capture and don't see anything going to port 2345 on the target.
Alternately, if anyone would share their Qt Creator debugger-log output with me so I can compare, that would be helpful.
I'm pretty sure this is a bug/regression. I did pretty much the same thing using QtC 4.3.1 and got it to work. Unfortunately, 4.3.1 has a super-annoying bug related to cmake projects that forced me to move forward to 4.5.
-
I'm pretty sure this is a bug/regression. I did pretty much the same thing using QtC 4.3.1 and got it to work. Unfortunately, 4.3.1 has a super-annoying bug related to cmake projects that forced me to move forward to 4.5.
-
I'm pretty sure this is a bug/regression. I did pretty much the same thing using QtC 4.3.1 and got it to work. Unfortunately, 4.3.1 has a super-annoying bug related to cmake projects that forced me to move forward to 4.5.
@rhvonlehe Hi, then please report your bug at bugreports.qt.io (maybe search first if it's already reported).
Thats the best way to get an information if a workaround exists and to get the thing fixed.
Thanks
-
@rhvonlehe Hi, then please report your bug at bugreports.qt.io (maybe search first if it's already reported).
Thats the best way to get an information if a workaround exists and to get the thing fixed.
Thanks
-
@aha_1980 I created a bug report, and subsequently found that a newer version of Qt Creator did not have the same issue. I think it would be OK to freeze or remove this topic.
QTCREATORBUG-19392
Thanks for filing the bug report. However, in general those bug report related topics are not being removed nor closed in the forum. They are seen as first start to find more about an issue, in case someone has a similar problem.
Also it is good to have a direct link to the bug report here for fast reference. This may attract also more votes for a bug report and providing aort of promotion that the bug report may be solved earlier.
