>> 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
On Mon, Mar 14, 2022 at 02:30:16PM -0600, Tom Tromey wrote:
> 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
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
>> 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
* Tom Tromey:
> 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
On Mon, Mar 07, 2022 at 10:49:47AM +, Pedro Alves wrote:
> On 2022-03-03 11:22, Stefan Hajnoczi wrote:
> > Hi,
> > The QEMU emulator uses coroutines with separate stacks. It can be
> > challenging to debug coroutines that have yielded because GDB is not
> > aware of them (no thread is
On Mon, Mar 07, 2022 at 05:18:12PM +, Pedro Alves wrote:
> On 2022-03-07 16:58, Tom Tromey wrote:
> >> "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
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
> "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
On 2022-03-07 16:58, Tom Tromey wrote:
>> "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
* Stefan Hajnoczi via Gdb:
> The QEMU emulator uses coroutines with separate stacks. It can be
> challenging to debug coroutines that have yielded because GDB is not
> aware of them (no thread is currently executing them).
>
> QEMU has a GDB Python script that helps. It "creates" a stack frame
On 2022-03-03 11:22, Stefan Hajnoczi wrote:
> Hi,
> The QEMU emulator uses coroutines with separate stacks. It can be
> challenging to debug coroutines that have yielded because GDB is not
> aware of them (no thread is currently executing them).
>
> QEMU has a GDB Python script that helps. It
Hi,
The QEMU emulator uses coroutines with separate stacks. It can be
challenging to debug coroutines that have yielded because GDB is not
aware of them (no thread is currently executing them).
QEMU has a GDB Python script that helps. It "creates" a stack frame for
a given coroutine by
13 matches
Mail list logo
