From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 28 Aug 2002 10:57:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 28 Aug 2002 10:57:10 -0400 Received: from dell-paw-3.cambridge.redhat.com ([195.224.55.237]:55798 "EHLO executor.cambridge.redhat.com") by vger.kernel.org with ESMTP id ; Wed, 28 Aug 2002 10:57:08 -0400 To: torvalds@transmeta.com Cc: linux-kernel@vger.kernel.org Subject: advanced tracing API User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Wed, 28 Aug 2002 16:01:23 +0100 Message-ID: <13022.1030546883@warthog.cambridge.redhat.com> From: David Howells Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org I've written an advanced tracing API as a potential replacement for ptrace. It isn't quite complete yet, but sufficient functionality should exist to implement strace. It works by adding a new system call that deals with file descriptors with "special" files attached (much as sysvipc shm does). The fds are, however, exposed and can be polled. Each fd manages a thread group. It has full support for threads created with CLONE_THREAD. Documentation is included in the trace-2532 patch. Comments would be appreciated. It is available as a pair of patches to 2.5.32 plus a test/demo program: ftp://infradead.org/pub/people/dwh/orn-2532.diff.bz2 ftp://infradead.org/pub/people/dwh/trace-2532.diff.bz2 ftp://infradead.org/pub/people/dwh/trctl2.c Apply the orn-2532 and then the trace-2532 patches to a 2.5.32 kernel, build and install. The trctl2 program needs access to the header files from the patched kernel at the moment. Run trctl2 under the patched kernel. It will fork off an "inferior" process and begin trapping and displaying certain events from it. The inferior process will then create a set of threads which will then also be managed by the "debugger". These threads can be hit with signals to make events happen. David