lkml.org 
[lkml]   [2004]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: ptrace single-stepping change breaks Wine
    Jesse Allen a écrit :
    > On Sun, Nov 21, 2004 at 10:23:41PM -0800, Linus Torvalds wrote:
    >
    >>Ok, how about this patch?
    >>
    >>It does basically two things:
    >>
    >> - it makes the x86 version of ptrace be a lot more careful about the TF
    >> bit in eflags, and in particular it never touches it _unless_ the
    >> tracer has explicitly asked for it (ie we set TF only when doing a
    >> PTRACE_SINGESTEP, and we clear it only when it has been set by us, not
    >> if it has been set by the program itself).
    >>
    >> This patch also cleans up the codepaths by doing all the common stuff
    >> in set_singlestep()/clear_singlestep().
    >>
    >> - It clarifies signal handling, and makes it clear that we always push
    >> the full eflags onto the signal stack, _except_ if the TF bit was set
    >> by an external ptrace user, in which case we hide it so that the tracee
    >> doesn't see it when it looks at its stack contents.
    >>
    >> It also adds a few comments, and makes it clear that the signal handler
    >> itself is always set up with TF _clear_. But if we were single-stepped
    >> into it, we will have notified the debugger, so the debugger obviously
    >> can (and often will) decide to continue single-stepping.
    >>
    >>IMHO, this is a nice cleanup, and it also means that I can actually debug
    >>my "program from hell":
    >>
    >> [torvalds@evo ~]$ gdb ./a.out
    >> GNU gdb Red Hat Linux (6.1post-1.20040607.41rh)
    >> Copyright 2004 Free Software Foundation, Inc.
    >> GDB is free software, covered by the GNU General Public License, and you are
    >> welcome to change it and/or distribute copies of it under certain conditions.
    >> Type "show copying" to see the conditions.
    >> There is absolutely no warranty for GDB. Type "show warranty" for details.
    >> This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols
    >> found)...Using host libthread_db library "/lib/tls/libthread_db.so.1".
    >>
    >> (gdb) run
    >> Starting program: /home/torvalds/a.out
    >> Reading symbols from shared object read from target memory...(no debugging
    >> symbols found)...done.
    >> Loaded system supplied DSO at 0xffffe000
    >> (no debugging symbols found)...(no debugging symbols found)...
    >> Program received signal SIGTRAP, Trace/breakpoint trap.
    >> 0x08048480 in main ()
    >> (gdb) signal SIGTRAP
    >> Continuing with signal SIGTRAP.
    >>
    >> Program received signal SIGTRAP, Trace/breakpoint trap.
    >> 0x08048487 in main ()
    >> (gdb) signal SIGTRAP
    >> Continuing with signal SIGTRAP.
    >>
    >> Program received signal SIGTRAP, Trace/breakpoint trap.
    >> 0x08048488 in smc ()
    >> (gdb) signal SIGTRAP
    >> Continuing with signal SIGTRAP.
    >> Copy protected: ok
    >>
    >> Program exited with code 01.
    >> (gdb)
    >>
    >>which I think is a sign that this patch actually fixes ptrace.
    >>
    >>Does this help with wine? I dunno. Maybe some wine people can comment..
    >>
    >
    >
    >
    > For the wine app in question, it does make a difference. However, there is
    > a new problem. The program gets stuck at the loading screen at 100% CPU.
    > It's making a call to select, timing out, and then tries select again,
    > repeats. It's waiting for something that seems to never happen.
    >
    > I've captured a log, "loop.log.bz2", and shortened to have only the relevent
    > information after the CMS32_MUTEX is created. Look for occurances of
    > "select()" -- I think the second one is where it starts. It's on my ftp if
    > anyone wants to take a look. It probably can be compared to the working-
    > version log where this doesn't occur, but it might be a pain to spot the
    > working particular instance.

    Hi Jesse
    Any network issue on your side? I tried to traceroute resnet.disp.net, but no avail.
    So I cannot have a look to you newest trace.

    A+

    -
    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:4.035 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site