Ok, this screams of a malignant back-end or similar problem. If the UI
doesn't even do screen updates, then I can pretty much guarantee that
the back-end code for your target is locking the UI out (blocked in a
system call). This happens rather more frequently than I wished. I get
reports of this every few months. [However, you're using a standard
"remote" target, and this should not happen, so something else must be
amiss.]
The problem is that gdb has several event loops. Insight further burdens
the debugging model by adding yet another one. Let me quickly clarify.
The two main event loops in gdb are the target event loop (where the
target code is waiting for debug messages from the target) and the UI
(or mi or cli) event loop, where the user interface is waiting for input
from the user.
Unfortunately, gdb and insight don't share the same event loops for
these things, and they probably never will until all target event loops
go async. In the meantime, we came up with a hack: have the target code
periodically call out to the UI to allow it to run it's event loop. This
is the evil "ui_loop_hook" that is in gdb.
For example, one of the little nasty things that is done (for which I am
regrettably responsible many years ago) involves breaking up serial and
network read requests into small chunks. Instead of waiting N seconds
for a reply from the target, gdb will wait 1 second, N times. After
every second, it calls the ui_loop_hook to update the UI (in this case,
only insight needs to register a hook callback).
So, now for your problems, the question is: why isn't the ui_loop_hook
being called? Better yet, why isn't the connect command completing and
returning control to gdb-proper?
To answer these questions may not be too difficult with a little
diligence on your part.
So, here are some questions/comments:
1) Let's see if we cannot get gdb/Insight to timeout after the connect
and return control to the UI. Before connecting to the target, can you
open a console and enter the command "set remote timeout 1". Now try
connecting. Does it ever return control to you, i.e., does the UI update
at all?
2) I believe you said you were using a remote tcp target, right? Hmm.
Looking over src/gdb/ser-tcp.c, I see calls to ui_loop_hook. Well, to
check this, we have no choice: you're going to have to load insight into
gdb and set a breakpoint on "x_event" in gdbtk-hooks.c. When you attach
to the target, does it ever stop at the breakpoint and run the hook?
3) The easy way: Run insight on gdb. Connect to your target (where the
hang occurs), and interrupt insight and get a backtrace of where it
stopped. Demonstrate anything? Blocked in a system call?
4) The hard way: If all else fails, you're going to have to set a break
in remote_open in remote.c and follow it through to the protocol level
(for tcp, that's in ser-tcp.c). Does it do the N 1-second timeouts,
calling ui loop hook? Or is it blocked?
5) The really hard way: Use strace to find out what's going on.
6) Can you remind me what version of gdb/insight you're using? (Show
complete output of "insight -v".)
Keith