Re: [Qemu-devel] [PATCH] scripts/qemugdb: support coroutine backtrace in coredumps

[Vladimir Sementsov-Ogievskiy <vsementsov at virtuozzo dot com>]

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:
> 
>    https://sourceware.org/ml/gdb-patches/2015-09/msg00248.html
> 
> Follow the urls there for more background.
> 
> To me, the important questions to answer are here:
>   https://sourceware.org/ml/gdb-patches/2015-09/msg00658.html
> 
> Unfortunately, I don't think the series moved past that point.
> 
> Thanks,
> Pedro Alves
> 


Hi Pedro!

Hmm, returned to this topic. I've spent this day digging in gdb code, and found it much
more difficult than qemu)..

I've failed to find something like

create_frame_with_registers, or create_thread_with_registers.. Looks like registers comes
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
coredump file..

Anything else?

***

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 new coroutine.

-- 
Best regards,
Vladimir