Re: RFC: lazily call save_current_space_and_thread

[Pedro Alves <pedro@codesourcery.com>]

On Tuesday 08 March 2011 17:49:29, Tom Tromey wrote:
> Pedro> I'm guessing you're trying all-stop.  In non-stop, I _think_
> Pedro> you'll much more rarely see a NULL selected frame here.
> 
> Nope, I do this before my test:
> 
>   set target-async on
>   set schedule-multiple on
>   set pagination off
>   set detach-on-fork off
>   set non-stop on


Okay.  In any case, what I was aluding to, is that
in non-stop mode gdb is making sure the user selected
frame is constant between events (fetch_inferior_event),
so in that case, there's a selected frame to restore back
to.  But thinking a bit more, that obviously doesn't matter
because if the user had a frame selected, then the debug info
for that frame has already been read anyway, and there's nothing
to optimize.

> I can't say that I understand everything that happens in this mode.
> 
> "run" appears to work in the background, which is mysterious to me.

Hmm.  It shouldn't.  Well, behind the scenes it does run
asynchronously, but only "run&" should work in the background,
from the user's perpective.

Boo, something's seriously broken :-/ :

[Thread debugging using libthread_db enabled]
process 2857 is executing new program: /usr/bin/iconv
Error in re-setting breakpoint 1: Cannot access memory at address 0x45e22a
Error in re-setting breakpoint 2: Cannot access memory at address 0x4e2e5a
warning: Error removing breakpoint 1
warning: Error removing breakpoint 2
warning: Error removing breakpoint 1
warning: Error removing breakpoint 2
warning: Error removing breakpoint 1
warning: Error removing breakpoint 2
warning: Error removing breakpoint 1
warning: Error removing breakpoint 2
warning: Error removing breakpoint 1
...

I suspect it's related to spawning iconv (or rather, that's
triggering some bug).

> 
> And, if I C-c gdb, I just get "Quit." back,

That just means you have the prompt, and the inferior is either
backgrounded, or not running at all.  To interrupt the target
in async/non-stop modes, we use "interrupt", not C-c.

> and then gdb is in a weird
> state (I can't "continue" any inferior and if I try "run" I get an
> internal error).
> 
> I am planning to debug these next; but if you know what is going on
> already...

Can't say I do.

-- 
Pedro Alves