>>> On 30.03.17 at 19:09, wrote:
> If you do have an external debugger attached, you don't need embedded
> int3's to start with, and you'd still hit the debugger_trap_*() calls
> before dying.
Well, my experience (on other OSes with a better debugger) is
different - there are occasions where it i
On 30/03/17 13:08, Jan Beulich wrote:
On 30.03.17 at 13:56, wrote:
>> On 20/03/17 11:50, Jan Beulich wrote:
>> On 20.03.17 at 11:58, wrote:
...rather than leaving fragments of old instructions in place. This
reduces
the chances of something going further-wrong (as the de
>>> On 30.03.17 at 13:56, wrote:
> On 20/03/17 11:50, Jan Beulich wrote:
> On 20.03.17 at 11:58, wrote:
>>> ...rather than leaving fragments of old instructions in place. This reduces
>>> the chances of something going further-wrong (as the debug trap will be
>>> caught
>>> and terminate th
On 20/03/17 11:50, Jan Beulich wrote:
On 20.03.17 at 11:58, wrote:
>> ...rather than leaving fragments of old instructions in place. This reduces
>> the chances of something going further-wrong (as the debug trap will be
>> caught
>> and terminate the guest) in a cascade-failure where we en
>>> On 20.03.17 at 11:58, wrote:
> ...rather than leaving fragments of old instructions in place. This reduces
> the chances of something going further-wrong (as the debug trap will be
> caught
> and terminate the guest) in a cascade-failure where we end up executing the
> instruction fragments.
...rather than leaving fragments of old instructions in place. This reduces
the chances of something going further-wrong (as the debug trap will be caught
and terminate the guest) in a cascade-failure where we end up executing the
instruction fragments.
Before:
(XEN) d2v0 exception 6 (ec=
