Petr Tesarik <[EMAIL PROTECTED]> writes:
> Anyway, I'm not familiar enough with the Wine protocol to write such
> code, not at least without much help from you. So, should I try it,
> or is it easy enough for you to code it yourself?
Well, it's not a trivial fix, I don't think I'll have time to
On 06/03/27 at 18:19:44 (+0200), Alexandre Julliard wrote:
> Petr Tesarik <[EMAIL PROTECTED]> writes:
>
> > That means that Windows XP creates a new thread in the given process
> > and breaks it at DbgBreak().
> >
> > Does this mean that we may avoid sending SIGTRAP altogether?
>
> Creating a new
Petr Tesarik <[EMAIL PROTECTED]> writes:
> That means that Windows XP creates a new thread in the given process
> and breaks it at DbgBreak().
>
> Does this mean that we may avoid sending SIGTRAP altogether?
Creating a new thread is probably even harder, but yes we can
certainly avoid SIGTRAP. On
--- Begin Message ---
Dne 03/27/06 v 17:16:50 (+0200), Alexandre Julliard napsal(a):
> The thing is that all of this is necessary because you want to handle
> a SIGTRAP sent with kill(). But obviously no Windows application is
> going to send us a SIGTRAP; the only way this will happen is when we
>
Dne 03/27/06 v 08:13:23 (-0700), Vitaliy Margolen napsal(a):
> >There is no other way to detect a hardware breakpoint than to look
> >at DR6. Additionally, since the bits would get stuck for all
> >subsequent SIGTRAPs, we need to clear them.
>
> [skip]
>
> Please don't forget here tha
Petr Tesarik <[EMAIL PROTECTED]> writes:
> Oh, I forgot to mention another thing. I didn't start all this for
> nothing. I made my changes to raise_trap_exception() to make an
> existing application (Kindler Lexikon) work.
Sure, I'm not saying you did this for no reason. I just have the
feeling
Dne 03/27/06 v 16:49:13 (+0200), Alexandre Julliard napsal(a):
> Petr Tesarik <[EMAIL PROTECTED]> writes:
>
> > In my opinion, the solution is reasonable because if any application
> > is really interested in the DR6 register (i.e. it is a debugger), it
> > will clear the status register (DR6) any
Monday, March 27, 2006, 7:58:38 AM, Petr Tesarik wrote:
> Dne 03/27/06 v 16:05:15 (+0200), Alexandre Julliard napsal(a):
>> Petr Tesarik <[EMAIL PROTECTED]> writes:
>>
>> > No, Windows need not do things like that, because the Windows kernel
>> > knows very well, whether it got INT1 or INT3... Som
Dne 03/27/06 v 16:05:15 (+0200), Alexandre Julliard napsal(a):
> Petr Tesarik <[EMAIL PROTECTED]> writes:
>
> > No, Windows need not do things like that, because the Windows kernel
> > knows very well, whether it got INT1 or INT3... Some UNIX kernels do
> > not give us that information reliably.
>
Petr Tesarik <[EMAIL PROTECTED]> writes:
> In my opinion, the solution is reasonable because if any application
> is really interested in the DR6 register (i.e. it is a debugger), it
> will clear the status register (DR6) anyway, since the processor never
> clears the bits and unless you clear the
Dne 03/27/06 v 16:05:15 (+0200), Alexandre Julliard napsal(a):
> Petr Tesarik <[EMAIL PROTECTED]> writes:
>
> > No, Windows need not do things like that, because the Windows kernel
> > knows very well, whether it got INT1 or INT3... Some UNIX kernels do
> > not give us that information reliably.
>
Petr Tesarik <[EMAIL PROTECTED]> writes:
> 2. The x86 spec states that a single-step interrupt (INT 1) is
>generated if the TF bit was set when the execution of the
>instruction BEGAN. This means that if the instruction changes the
>TF bit (e.g. popf), there is an INT 1, but the TF bi
12 matches
Mail list logo
