Re: ptrace and thread

From: Robert Watson (rwatson_at_freebsd.org)
Date: 01/14/04

  • Next message: Robert Watson: "Re: Request for Comments: libarchive, bsdtar" 
    Date: Wed, 14 Jan 2004 17:03:29 -0500 (EST)
To: Julian Elischer <julian@elischer.org>

    On Wed, 14 Jan 2004, Julian Elischer wrote:

    > On Wed, 14 Jan 2004, David Xu wrote:
    >
    > > I am current working on debug support for KSE thread program, however I
    > > found
    > > ptrace interface is not thread-aware, in a threaded program, I need to
    > > get/set registers
    > > set for individual threads, current ptrace can not support that
    > > features, there are two
    > > ways to support these requirements:
    >
    > Yes I tried to address this a bit around the time when I added the
    > single ttreading code. Ialso made several posts looking for advice from
    > gdb/ptrace experts but got very little response.. As you noticed, the
    > ptrace facility is almost completely useless WRT threads..
    >
    > it is possible to imagine an extension where you select a single thread
    > of interest but you would have to decide whether you want all the other
    > threads to be left running or left suspended.. (you may need both
    > possibilities to correctly debug a problem)
    >
    > The problem is that the thread becomes invisible to the kernel when it
    > crosses over to userland so the UTS needs to take an active part,
    > (unless the kernel can recognise when the thread has yielded and the UTS
    > has been enterred. (possible I guess) at which time single stepping
    > would be turned off allowing the UTS to run at full speed.
    >
    > The UTS would hav eto co-operate by using a method of re-enterring the
    > thread that allows the kernel to re-start single stepping..
    >
    > What the other threads are doing in teh meanwhile is unknown.

    Apparnelty one common model is to get the application's (or threading
    package's) help in the debugging process. Teach gdb to talk to libkse,
    and have libkse provide the information on threading to gdb, as well as do
    the scheduling/assert control.

    FWIW, I think ptrace/procfs are in a somewhat broken state following KSE
    -- stuff like gdb works, but strace is known to hang. Part of the problem
    appears to be slightly different models for stopping the process -- p_step
    vs p_stop(). I'm still getting my head around the details of the
    debugging facilities, which is complicated by the fact that procfs is a
    lot more capable than the man page claims :-). I hope to dig more into
    the problem next week.

    Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
    robert@fledge.watson.org Senior Research Scientist, McAfee Research

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Robert Watson: "Re: Request for Comments: libarchive, bsdtar"

    Relevant Pages