>> You can play with this if you want. It's on 'submit/green-threads' on
>> my github. Be warned that I rebase a lot.
Stefan> This looks cool! Would it be useful to see a port of QEMU's coroutine.py
Stefan> script to your green threads API?
Wouldn't hurt :)
Stefan> QEMU's coroutines aren't in
Tom> IMO this is just a longstanding hole in GDB. Green threads exist,
Tom> so it would be good for GDB to have a way to inspect them.
I took a stab at implementing this recently. It's still very rough but
it's good enough to discuss whether it's something I should try to
polish.
For testing th
>> Yes, the infamous "previous frame inner to this frame" error message. I
>> think this is primarily intended to detect stack trashing, but maybe it
>> also serves to work around bad debuginfo or bugs in the unwinders.
Florian> Is there a user-level command to disable the check manually?
I don'
Florian> I'm a bit surprised by this. Conceptually, why would GDB need to know
Florian> about stack boundaries? Is there some heuristic to detect broken
Florian> frames?
Yes, the infamous "previous frame inner to this frame" error message. I
think this is primarily intended to detect stack tras
> "Stefan" == Stefan Hajnoczi writes:
Stefan> I hoped that "select-frame address ADDRESS" could be used instead so
Stefan> this would work on coredumps too. Unfortunately "select-frame" only
Stefan> searches stack frames that GDB is already aware of, so it cannot be used
Stefan> to backtrace
> "Stefan" == Stefan Weil writes:
Stefan> Fixing problems at their source - in this
Stefan> case fixing gdb - is of course the best solution.
Could you file a gdb bug report?
Tom
