Re: "previous frame inner to this frame" error when unwinding fibers

[Tom Tromey <tom@tromey.com>]

>>>>> "Andrey" == Andrey Turkin <andrey.turkin@gmail.com> writes:

Andrey> Re stopping the unwind for green threads - callback makes sense I
Andrey> think; I guess most users would want to chop off some useless tail
Andrey> there. But also custom unwinders might want to have some clean way to
Andrey> do the same for whatever reason. I currently just do
Andrey> create_unwind_info() without filling any registers; that works but
Andrey> results in an ugly error message.

For unwinders I think we could add a more principled way to signal the
end of the stack.

Andrey> Re inner-than thing - this is orthogonal to green threads. This is
Andrey> something that happens because of unwinder stitching together
Andrey> different stacks; it doesn't have to be due to green threads. In fact,
Andrey> with the green threads support it might not be necessary to do the
Andrey> stiching; we might get away with doing several bts for the threads we
Andrey> want shown together, or something like a custom command to switch
Andrey> between callee/caller contexts etc. But anyway, if this is to be
Andrey> implemented, it seems to me this belongs to the unwinders domain.

I see what you mean, though stitching together stacks from different
threads is maybe a questionable procedure in gdb.

One issue is that the frame cache is global -- not per-thread.  So,
switching threads will flush it and cause it to be repopulated.  As long
as the inferior doesn't run, this will be "invisible" to the user,
though it may show up as a performance problem.

It'd be nice to fix this but there's some tricky business involving
vfork IIRC.  I think there's a bug open about it.

Also when stitching together stacks, I wonder about the semantics of
things like "finish".  But... maybe as long as selecting a frame also
selects its underlying thread, it could kinda work.

Andrey> Re PoC implementation on GH - I tried it out.

Thank you.

Andrey> There was an obvious bug (see attached patch),

I applied this to my branch.

Andrey> I can switch to it etc, but the registers don't get fetched
Andrey> and bt, info frame etc shows information of a native thread with id 1

I am not sure but I suspect this was this problem in a few methods in
green_thread_target -- they checked the green thread's ptid, but they
should have checked if the green thread has an underlying thread.

The idea here is that when a green thread is currently running on a
native thread, registers should simply come from that; but if the green
thread is inactive, then the Python code should be used.

I made this change on my branch & pushed it again, in case you want to
give it another try.

Tom