On Wed, 9 Feb 2022 at 22:12, Richard Henderson
wrote:
>
> On 2/9/22 22:22, Alex Bennée wrote:
> > linux-user wants to trap all signals in case they are related to the
> > guest. This however results in less than helpful core dumps when the
> > error is internal to QEMU. We can detect when an
On 2/9/22 22:22, Alex Bennée wrote:
linux-user wants to trap all signals in case they are related to the
guest. This however results in less than helpful core dumps when the
error is internal to QEMU. We can detect when an assert failure is in
progress by examining __glib_assert_msg and fall
On Wed, 9 Feb 2022 at 13:23, Alex Bennée wrote:
>
>
> Peter Maydell writes:
>
> > On Wed, 9 Feb 2022 at 11:35, Alex Bennée wrote:
> >> linux-user wants to trap all signals in case they are related to the
> >> guest. This however results in less than helpful core dumps when the
> >> error is
Peter Maydell writes:
> On Wed, 9 Feb 2022 at 11:35, Alex Bennée wrote:
>> linux-user wants to trap all signals in case they are related to the
>> guest. This however results in less than helpful core dumps when the
>> error is internal to QEMU. We can detect when an assert failure is in
>>
On Wed, 9 Feb 2022 at 11:35, Alex Bennée wrote:
> linux-user wants to trap all signals in case they are related to the
> guest. This however results in less than helpful core dumps when the
> error is internal to QEMU. We can detect when an assert failure is in
> progress by examining
linux-user wants to trap all signals in case they are related to the
guest. This however results in less than helpful core dumps when the
error is internal to QEMU. We can detect when an assert failure is in
progress by examining __glib_assert_msg and fall through to
cpu_abort() which will pretty
