lkml.org 
[lkml]   [2004]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: ptrace single-stepping change breaks Wine
    On Fri, Nov 19, 2004 at 01:53:38PM -0800, Linus Torvalds wrote:
    >
    >
    > 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-stepping, then it damn well should get it. It it doesn't want to
    > single-step through a signal handler, then it could decide to just put a
    > breakpoint on the return point (possibly by modifying the signal handler
    > save area).
    >
    > It's not like single-stepping into the signal handler in any way removes
    > any information (while _not_ single-stepping into it clearly does).
    >
    > With the patch I just posted (assuming it works for people), Wine should
    > at least have the choice. The behaviour now should be:
    >
    > - if the app sets TF on its own, it will cause a SIGTRAP which it can
    > catch.
    > - if the debugger sets TF with SINGLESTEP, it will single-step into a
    > signal handler.
    > - it the app sets TF _and_ you ptrace it, you the ptracer will see the
    > debug event and catch it. However, doing a "continue" at that point
    > will remove the TF flag (and always has), the app will normally then
    > never see the trap. You can do a "signal SIGTRAP" to actually force
    > the trap handler to tun, but that one won't actually single-step (it's
    > a "continue" in all other senses).
    >
    > It sounds like the third case is what wine wants.
    >
    > Linus


    So an app running through wine could set TF on it's own? It would be a
    good idea to find out what it is doing in the first place. There has to be
    a reason why War3 is so picky after the original change was introduced and
    a reason why the latest changes don't seem to fix it.

    I've built a kernel 2.6.10-rc2 with the new ptrace patch. The program still
    says "please insert disc". I haven't been able to get winedbg to tell me
    anything useful -- the program never crashes anyways. So I went ahead and I
    captured a debug log.

    the command:
    WINEDEBUG=+all wine war3/Warcraft\ III.exe -opengl >& war3_and_2.6.10-rc2.log

    I scanned for the part right before it calls up to display the error. I found
    that after loading advapi32.dll, the thread 000c creates a mutex and wakes up
    000a. Then 000c gets killed and right after that starts calling up the
    resources for the "insert disc" message box. I put the log up on my ftp, and
    the interesting part in a seperate file:
    ftp://resnet.dnip.net/

    Any clue on what may be happening here? Or maybe another idea on where else to search?


    Jesse

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:08    [W:6.291 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site