On 7/31/2020 6:07 AM, Daniel P. Berrangé wrote:
> On Thu, Jul 30, 2020 at 02:11:19PM -0400, Steven Sistare wrote:
>> On 7/30/2020 12:20 PM, Eric Blake wrote:
>>> On 7/30/20 10:14 AM, Steve Sistare wrote:
>>>> Provide the -pause command-line parameter and the QEMU_PAUSE environment
>>>> variable to briefly pause QEMU in main and allow a developer to attach gdb.
>>>> Useful when the developer does not invoke QEMU directly, such as when using
>>>> libvirt.
>>>
>>> How would you set this option with libvirt?
>>
>> Add -pause in the qemu args in the xml.
>>
>>> It feels like you are trying to reinvent something that is already
>>> well-documented:
>>>
>>> https://www.berrange.com/posts/2011/10/12/debugging-early-startup-of-kvm-with-gdb-when-launched-by-libvirtd/
>>
>> Too many steps to reach BINGO for my taste. Easier is better. Also, in our
>> shop we start qemu
>> in other ways, such as via services.
>
> A "sleep" is a pretty crude & unreliable way to get into debugging
> though. It is racy for a start, but also QEMU has a bunch of stuff
> that runs via ELF constructors before main() even starts.
>
> So I feel like the thing that starts QEMU is better placed to provide
> a way in for debugging.
>
> eg the service launcher can send SIGSTOP to the child process immediately
> before the execve(qemu) call.
>
> Now user can attach with the debugger, allow execution to continue,
> and has ability to debug *everything* right from the ELF constructors
> onwards into main() and all that follows.
>
> Regards,
> Daniel
That is a nice solution for the launchers we can modify.
We could use your idea in place of the sleep in main,
kill(getpid(), SIGSTOP);
Not quite as good as being able to debug the elf constructors, but still
helpful.
- Steve
