[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] scripts/qemugdb: support coroutine backtrace in
Re: [Qemu-devel] [PATCH] scripts/qemugdb: support coroutine backtrace in coredumps
Thu, 27 Dec 2018 17:36:04 +0000
23.04.2018 16:28, Pedro Alves wrote:
> On 04/23/2018 02:37 AM, Simon Marchi wrote:
>> On 2018-04-09 10:08 PM, Stefan Hajnoczi wrote:
>>> I wonder what the point of select-frame is then...
>>> I have CCed the GDB mailing list. Maybe someone can help us. Context:
>>> QEMU implements coroutines using jmpbuf. We'd like to print coroutine
>>> call stacks in GDB and have a script that works when a process is being
>>> debugged (it sets the registers).
>>> Now we'd like to extend the script to work on core dumps where it's not
>>> possible to set registers (since there is no process being debugged).
>>> Is there a way to backtrace an arbitrary call stack in a core dump?
>> Not that I know of. The "frame <stack-addr> <pc-addr>" form of the frame
>> command sounds like it should be usable to achieve that, but it doesn't
>> seem to work in that way. I really wonder if it's working as it was
>> intended initially. I guess using that form of the frame command should
>> override/mask the real current values of $sp and $pc?
> Yeah, "frame <args>" has a lot of problems.
> This series was working toward sorting out the "frame" command:
> Follow the urls there for more background.
> To me, the important questions to answer are here:
> Unfortunately, I don't think the series moved past that point.
> Pedro Alves
Hmm, returned to this topic. I've spent this day digging in gdb code, and found
more difficult than qemu)..
I've failed to find something like
create_frame_with_registers, or create_thread_with_registers.. Looks like
from some register caches, backed by different sources of registers or
something like this.
So, I'd like to ask several questions:
1. Any news on the topic since April?
2. Can you propose a simple (maybe hacky) way (with or without patching gdb) to
achieve the behavior like
set $rsp = ...
set $rbp = ...
set $rip = ...
bt #prints bt, starting from the frame corresponding to register values set
fr 5 #goes to frame in this bt, and allow to examine local variables
for debugging core-dumps?
May be, we can allow set registers while debugging core-dump? Why we can't set
them? We have
same register caches, and anyway we can move between threads and frames and
registers are changed...
May be, we can somehow add separate thread with given registers from user, like
they are created from
For me, still, the simplest way is to add additional note segments to coredump
file, to specify needed frames..
But it is not very comfortable, to recreate and reopen core file, when found
|[Prev in Thread]
||[Next in Thread]|
- Re: [Qemu-devel] [PATCH] scripts/qemugdb: support coroutine backtrace in coredumps,
Vladimir Sementsov-Ogievskiy <=