On Fri, 31 Dec 2004, Davide Libenzi wrote:
>
> I don't think that the Wine problem resolution is due to the POPF
> instruction handling. Basically Linus patch does a nice cleanup plus POPF
> handling, so maybe the patch can be split.
The popf part is very nice in that it allows you to single-
On Fri, 31 Dec 2004, Daniel Jacobowitz wrote:
>
> Lots, I like it. The syscall trap will always be delivered before the
> single-step trap, right, because signal delivery won't run until we
> return to userspace?
Yes. Although I've not actually tested it.
Before, it used to show up as one eve
On Fri, 31 Dec 2004, Andi Kleen wrote:
>
> > - you couldn't even debug signal handlers, because they were _really_
> >hard to get into unless you knew where they were and put a breakpoint
> >on them.
>
> Ok I see this as being a problem. But I bet it could be fixed
> much simpler wit
On Fri, 31 Dec 2004, Daniel Jacobowitz wrote:
>
> Well, you put SIGTRAP|0x80 in si_code. Coincidentally, 0x80 is
> SI_KERNEL. So testing for SI_KERNEL | 0x80 is probably OK in the
> signal path, since most of its other arbitrary values would be either
> negative or not include SI_KERNEL.
Some
On Fri, 31 Dec 2004, Andi Kleen wrote:
>
> Just looking at all this complexiy and thinking about
> making it work on x86-64 too doesn't exactly give a good
> feeling in my spine.
>
> Not to belittle your archivement Linus but it all looks
> very overengineered to me.
Ehh, do you have any _alte
On Thu, 30 Dec 2004, Daniel Jacobowitz wrote:
>
> does not look right to me. Before, we'd get an 0x80|SIGTRAP result
> from wait. Now, you've moved the 0x80 to live only inside the siginfo.
> This is accessible to the debugger via ptrace, but only very recently
> (late 2.5.x). So this will pr
On Thu, 30 Dec 2004, Jesse Allen wrote:
>
> Well I tried this patch and it works.
Goodie. Are there other known problems with silly copy-protection
schemes? It migth be worth testing.
However:
> Since I cannot spot any issue, the patch looks good. Are there any
> other test cases?
Yes. I
On Thu, 30 Dec 2004, Linus Torvalds wrote:
>
> Working on a patch for this right now, I'll send something out soonish
> (and I'll test it on my test-case before sending it, so that it at least
> has some chance of working).
Ok, here's a patch that may or may no
On Thu, 30 Dec 2004, Jesse Allen wrote:
>
> Using the latest version of the patch on do_syscall_trace(), it still
> doesn't work unless I remove this test. If indeed it's supposed to
> fall through to receive the proper signal, (ie to single step properly
> after an int op), then removing it is
On Thu, 30 Dec 2004, Davide Libenzi wrote:
>
> This might explain what they were seeing, but OTOH it seems that the real
> cause of their problems is related to something else (according to other
> emails on this thread).
There's two different problems: the one seen by Thomas (the Xilinx FPGA
On Wed, 29 Dec 2004, Davide Libenzi wrote:
>
> I think same. My test simply let the function processing to let thru and
> reach the fake signal sending point.
No, your test-case doesn't even send a signal at all, because your
test-program just uses a PTRACE_SINGLESTEP without any "send signal"
On Wed, 29 Dec 2004, Linus Torvalds wrote:
>
> So the updated patch would look something like the appended.
.. no, I see what's up. System call returns _are_ special for
single-stepping. I'll think about it..
Linus
On Wed, 29 Dec 2004, Linus Torvalds wrote:
>
> .. no, I see what's up. System call returns _are_ special for
> single-stepping. I'll think about it..
Ok, I think I know what's up.
It's literally the bogus fake signal that do_syscall_trace() sends. I
thi
On Thu, 30 Dec 2004, Thomas Sailer wrote:
>
> No joy with
> linux-2.6.10
> patch-2.6.10-ac1
> 01-ptrace-reverse.diff
> sigtrap-reverse.diff
>
> Below is the seh trace output. In the working case (2.6.8) there is no
> trace:seh: output at this point.
I have no idea what "seh" is in wine-speak, b
On Wed, 29 Dec 2004, Davide Libenzi wrote:
>
> That test went in to be able to have ptrace single step, to see even the
> instruction following the #int instruction (this was the target of the
> patch itself). I just verified that, in 2.6.8 that does not have such test
> anymore, the single-s
On Wed, 29 Dec 2004, Jesse Allen wrote:
> >
> > So instead of removing the setting of TIF_SINGLESTEP in set_singlestep(),
> > can you test whether removing the _testing_ of it in do_syscall_trace()
> > makes things happier for you? Hmm?
> >
>
> Yes, doing that does work. But I still have to r
On Wed, 29 Dec 2004, Jesse Allen wrote:
>
> >
> > So does removing the conditional TF clear make everything work again?
> >
>
> Yes, as long as TIF_SINGLESTEP is not set in set_singlestep().
That may be a clue, if only because that makes absolutely _zero_ sense.
Setting TIF_SINGLESTEP sho
On Wed, 29 Dec 2004, Mike Hearn wrote:
>
> I can't see if he CCd anybody from the archives but Jesse Allen posted a
> nice analysis of the remaining problem here:
>
> http://www.winehq.org/hypermail/wine-devel/2004/12/0691.html
Ok, I don't remember the context from the Wine lists (and it's not
On Mon, 22 Nov 2004, Eric Pouech wrote:
>
> For the linux folks, here a small comparison of what happens in the working
> (old) case and in the non-working (new) case:
>
> In both case
>
> - Wine gets a first SIGTRAP (in it's sig_trap handler)
> + Wine converts it into a Windows excepti
On Mon, 22 Nov 2004, Mike Hearn wrote:
>
> this is where signals are converted to SEH exceptions (w-exceptions as
> Eric called them):
>
> dlls/ntdll/signal_i386.c
Looks like it clears TF there already:
if (context->EFlags & 0x100)
{
context->EFlags &= ~0x100;
On Mon, 22 Nov 2004, Andreas Schwab wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > IMHO, this is a nice cleanup, and it also means that I can actually debug
> > my "program from hell":
>
> Does it also work when trying to single step over i
On Sun, 21 Nov 2004, Davide Libenzi wrote:
>
> I'd agree with Linus here. A signal handler is part of the application, so
> it should be single stepped in the same way other application code does.
> My original patch simply reenabled the flag before returning to userspace,
> and this had the
On Sun, 21 Nov 2004, Linus Torvalds wrote:
>
> I'm by no means 100% sure that we should encourage the kind of programming
> "skills" I showed with that example program, so in that sense this may not
> be worth worrying about. That said, I do hate the notion of
On Sun, 21 Nov 2004, Davide Libenzi wrote:
>
> You know you're sick, don't you? Making traps inc's to get you in the
> correct opcode to move function in edx->fnp, is indeed fruit of a sick
> mind :=)
I prefer "creative" over "sick". It's so much less judgemental.
I thought it was a fun way
On Sun, 21 Nov 2004, Davide Libenzi wrote:
>
> So it seems it did not work even before, the gdb-SIGTRAP stepping. In
> 2.6.8 I get a straight segfault just for running it.
Ok, that at least means it's not a regression, although it may be that the
altered behaviour is enough to make some progr
On Mon, 22 Nov 2004, Andreas Schwab wrote:
>
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > Now, try to "strace" it, or debug it with gdb, and see if you can repeat
> > the behaviour.
>
> You'll always have hard time repeating that under st
On Fri, 19 Nov 2004, Daniel Jacobowitz wrote:
>
> I'm getting the feeling that the question of whether to step into
> signal handlers is orthogonal to single-stepping; maybe it should be a
> separate ptrace operation.
I really don't see why. If a controlling process is asking for
single-steppi
On Fri, 19 Nov 2004, Eric Pouech wrote:
>
> wine mixes both approches, we have (to control what's generated inside the
> various exception) to ptrace from our NT-kernel-like process (the ptracer) to
> get the context of the exception. Restart from the ptracer is done with
> PTRACE_SINGLESTEP.
28 matches
Mail list logo
