Re: gdbstub initial code

* Roland McGrath [2010-07-12 22:59:05]: > > When I had posted a prototype of a gdbstub which Frank and I had > > worked on. http://lkml.org/lkml/2009/11/30/173, Peter and Ingo > > showed a preference for a combined gdbstub in kernel, i.e kgdb and the > > newer stub should use only one stub in ke

Re: gdbstub initial code

> Hello. > > Please see the attachment. Don't take this code seriously, this is > the early prototype and everything should be rewritten. It barely > uses utrace, only to stop the target. > > (gdb) file /path/to/binary > (gdb) target extended-remote /proc/ugdb > (gdb) attach PID

Re: gdbstub initial code

Hi Oleg, > Hello. > > Please see the attachment. Don't take this code seriously, this is > the early prototype and everything should be rewritten. It barely > uses utrace, only to stop the target. > > (gdb) file /path/to/binary > (gdb) target extended-remote /proc/ugdb > (gdb)

Re: linux-next: add utrace tree

* Linus Torvalds [2010-01-27 02:43:39]: > > > On Wed, 27 Jan 2010, Peter Zijlstra wrote: > > > > Right, so you're going to love uprobes, which does exactly that. The > > current proposal is overwriting the target instruction with an INT3 and > > injecting an extra vma into the target process's

Re: [RFC] [PATCH 0/7] UBP, XOL and Uprobes [ Summary of Comments and actions to be taken ]

Here is a summary of the Comments and actions that need to be taken for the current uprobes patchset. Please let me know if I missed or misunderstood any of your comments. 1. Uprobes depends on trap signal. Uprobes depends on trap signal rather than hooking to the global die notifier. It

Fw: Re: linux-next: add utrace tree

Hi Roland, Oleg, Would it be a good idea to probably start looking at user space api for utrace? By doing that we would get usecases that maintainers in LKML are looking for and start looking at its usefulness. Currently its probably a egg and chicken case where they look at what end customers ar

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

> > > >What does the code in the jumped-to vma do? > > 1. Write a trace entry into shared memory, trap into the kernel on overflow. > 2. Trap if a condition is satisfied (fast watchpoint implementation). > > >Is the instrumentation code > >that corresponds to the uprobe handlers encoded in an ad

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

* Frederic Weisbecker [2010-01-19 19:06:12]: > On Tue, Jan 19, 2010 at 09:47:45AM -0800, Jim Keniston wrote: > > > > What does the code in the jumped-to vma do? Is the instrumentation code > > that corresponds to the uprobe handlers encoded in an ad hoc .so? > > > Once the instrumentation is

Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

* Avi Kivity [2010-01-18 14:17:10]: > On 01/18/2010 02:13 PM, Pekka Enberg wrote: > >So how big chunks of the address space are we talking here for uprobes? > > That's for the authors to answer, but at a guess, 32 bytes per probe > (largest x86 instruction is 15 bytes), so 32 MB will give you a

Re: [RFC] [PATCH 4/7] Uprobes Implementation

> > > > Furthermore it requires stopping and resuming tasks and nonsense like > > > that, that's unwanted in many cases, just run stuff from the trap site > > > and you're done. > > > > I don't know what you mean exactly. A trap already stopped task. > > utrace merely allows various clients to i

Re: [RFC] [PATCH 4/7] Uprobes Implementation

* Peter Zijlstra [2010-01-15 11:33:27]: > > > Uprobes layer would need to be notified of process life-time events > > like fork/clone/exec/exit. > > No so much the process lifetimes as the vma life times are interesting, > placing a hook in the vm code to track that isn't too hard, > > > It

Re: [RFC] [PATCH 3/7] Execution out of line (XOL)

* Peter Zijlstra [2010-01-15 10:07:35]: > On Thu, 2010-01-14 at 14:43 -0800, Jim Keniston wrote: > > > > Yeah, there's not a lot of context there. I hope it will make more > > sense if you read section 1.1 of Documentation/uprobes.txt (patch #6). > > Or look at get_insn_slot() in kprobes, and u

Re: [RFC] [PATCH 4/7] Uprobes Implementation

Hi Peter, > > > > > > > My reply in > > http://lkml.indiana.edu/hypermail/linux/kernel/1001.1/02483.html > > addresses this. > > Right, so all that need be done is add the multiple probe stuff to UBP > and its a sane interface to use on its own, at which point I'd be > inclined to call that up

Re: [RFC] [PATCH 4/7] Uprobes Implementation

Hi Frederic, > > > So, as stated before, uprobe seems to handle too much standalone > policies such as freeing on exec, always inherit on clone and never > on fork. Such rules should be decided from uprobe clients not > from uprobe itself and that makes it not enough flexible to > be usable fo

Re: [RFC] [PATCH 4/7] Uprobes Implementation

Hi Paul, > > + > > +/* > > + * Allocate a uprobe_task object for p and add it to uproc's list. > > + * Called with p "got" and uproc->rwsem write-locked. Called in one of > > + * the following cases: > > + * - before setting the first uprobe in p's process > > + * - we're in uprobe_report_clone

[RFC] [PATCH 0/7] UBP, XOL and Uprobes

Hi, This patchset implements Uprobes which enables you to dynamically break into any routine in a user space application and collect information non-disruptively. Uprobes is based on utrace and uses x86 instruction decoder. When a uprobe is registered, Uprobes makes a copy of the probed instruc

[RFC] [PATCH 7/7] Ftrace plugin for Uprobes

ff <...>-6424 [004] 1156.853402: : 0x4004d8: A ARG 5: 0048 TODO: - use ringbuffer - Allow user to specify Nick Name for probe addresses. - Dump arguments from floating point registers. - Optimize code to use single probe instead of multiple probes for same pr

[RFC] [PATCH 6/7] Uprobes Documentation

obe hit takes about 3 +microseconds to process. Specifically, a benchmark that hits the +same probepoint repeatedly, firing a simple handler each time, reports +300,000 to 350,000 hits per second, depending on the architecture. + +Here are sample overhead figures (in usec) for x86 architecture.

[RFC] [PATCH 5/7] X86 Support for Uprobes

[PATCH] x86 support for Uprobes Signed-off-by: Jim Keniston --- arch/x86/Kconfig |1 + arch/x86/include/asm/uprobes.h | 27 +++ 2 files changed, 28 insertions(+) Index: new_uprobes.git/arch/x86/Kconfig =

[RFC] [PATCH 3/7] Execution out of line (XOL)

current vma. 3. If we cant expand the vma, allocate a new vma. Signed-off-by: Jim Keniston Signed-off-by: Srikar Dronamraju --- arch/Kconfig|4 include/linux/ubp_xol.h | 56 kernel/Makefile |1 kernel/ubp_xol.c| 644

[RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

methods. UBP currently supports both single stepping inline and execution out of line strategies. Two different probepoints in the same process can have two different strategies. You need to follow this up with the UBP patch for your architecture. Signed-off-by: Jim Keniston Signed-off-by: Srikar

[RFC] [PATCH 2/7] x86 support for UBP

x86 support for user breakpoint Infrastructure This patch provides x86 specific userspace breakpoint assistance implementation details. This patch requires "x86: instruction decoder API" patch. http://lkml.org/lkml/2009/6/1/459 Signed-off-by: Jim Keniston Signed-off-by: Srikar

Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.

> > > > I guess Christoph, Roland and Frank would be able to explain in a better > > fashion the rational and advantages of this stub over convential gdb. > > Hmm,. wouldn't it make much more sense to extend the current kgdb stub > to include userspace debugging, providing an all-in-one solution?

Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.

* Peter Zijlstra [2009-11-30 13:41:47]: > > > > This is a In-kernel gdbstub to debug user space programs. > > This stub doesnt help in debugging kernel. > > > > Hence I am not sure how to compare kgdb gdbstub with this gdbstub. > > Can you please provide more pointers on what you were referrin

Re: [RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.

* Peter Zijlstra [2009-11-30 13:09:12]: > On Mon, 2009-11-30 at 17:33 +0530, Srikar Dronamraju wrote: > > This patch implements an in-kernel gdb stub. > > It provides an interface between gdb and Linux Kernel by implementing > > the remote serial protocol. Thi

[RFC] [PATCH] In-kernel gdbstub based on utrace Infrastructure.

n) y $ pgrep zsh 8865 $ I request you to please review this and lets us know your comments. Signed-off-by: "Frank Ch. Eigler" Signed-off-by: Srikar Dronamraju --- fs/proc/base.c |4 + include/linux/utrace.h |4 + init/Kconfig | 26 +- kernel/Mak

Re: [RFC,PATCH 0/14] utrace/ptrace

Hi Christoph, > > The other thing is that this patchset really doesn't quite justify > utrace. It's growing a lot more code without actually growing any > useful functionality. What about all those other utrace killer > features that have been promised for a long time? > We are working on in

Re: [PATCH 1-13] utrace-ptrace V1, for internal review

Hi Oleg, Roland, Ananth When I get the latest set of ptrace-tests by using. cvs -d :pserver:anoncvs:anon...@sources.redhat.com:/cvs/systemtap co ptrace-tests I get errors when I run make syscall-from-clone.c: In function ‘main’: syscall-from-clone.c:127: error: storage size of ‘regs’

Re: [PATCH 5] ptrace: change tracehook_report_syscall_exit() to handle stepping

Hi Oleg, > > I don't have a powerpc machine, but I think this test-case should > see the difference: On a powerpc machine, I did verify that the below test-case differs with your patch. Without the patch it would print the message "kernel bug: status=857F shouldn't have 0x80" > > #inc

Re: [PATCH 3] ptrace: introduce user_single_step_siginfo() helper

> > +#ifdef ARCH_HAS_USER_SINGLE_STEP_INFO > +extern void user_single_step_siginfo(struct task_struct *tsk, > + struct pt_regs *regs, siginfo_t *info); > +#else > +static inline void user_single_step_siginfo(struct task_struct *tsk, > + struc

Re: [PATCH 3/7] ptrace_init_task: cleanup the usage of ptrace_link()

* Oleg Nesterov [2009-10-26 04:28:46]: > @@ -169,9 +164,9 @@ static inline void ptrace_init_task(stru > INIT_LIST_HEAD(&child->ptraced); > child->parent = child->real_parent; > child->ptrace = 0; > - if (unlikely(ptrace)) { > + if (unlikely(ptrace) && (current->ptrace &

[PATCH] For selinux sake allocate a "fake" unlinked shmem

Hi Frank, Jim, Mark, This fix is equivalent to commit a82ac1f413712a375d5e14ef7641ce0abf7a6543 in systemtap tree. -- We allocate a "fake" unlinked shmem file because anonymous memory might not be granted execute permission when the selinux security hooks have their way. Signed-off-

[PATCH 2/2] use reusable functions wherever possible.

Remove duplicate code where possible by using reusable functions. Signed-off-by: Srikar Dronamraju --- kernel/utrace-gdb.c | 272 +++ 1 files changed, 123 insertions(+), 149 deletions(-) diff --git a/kernel/utrace-gdb.c b/kernel/utrace-gdb.c

[PATCH 0/2] Code cleanup patches.

This patchset just does code cleanup and no additional bugfixes or features. After applying this patchset, checkpatch reports: total: 0 errors, 0 warnings, 0 checks, 1560 lines checked Subject: [PATCH 0/2] Code cleanup patches. File: /tmp/gdbstub-patches/4/intro Subject: [PATCH 1/2] Make gdbstub

[PATCH] Fix a race in Uprobes while removing a breakpoint

-September/msg00028.html This patch fixes the problem at breakpoint removal time. Patch adjusts instruction pointer for those threads that have executed the trap instruction but have not yet singlestepped Signed-off-by: Srikar Dronamraju --- kernel/uprobes_core.c | 41

Should SIGNAL_REPORT take preference to queued signal?

Hi Roland, Oleg I hit upon a case where a traced thread steps over a inserted breakpoint instruction, and the tracing engine requests the traced thread to be interrupted. Here the traced thread calls report_signal callback with UTRACE_REPORT_SIGNAL and later does a report_signal callback with UTRA

[PATCH 2/3] Make singlestep in uprobes more robust.

ter if we have indeed singlestepped. Signed-off-by: Srikar Dronamraju --- kernel/uprobes_core.c | 65 1 files changed, 54 insertions(+), 11 deletions(-) diff --git a/kernel/uprobes_core.c b/kernel/uprobes_core.c index 7cea30b..d784d4a 100

[PATCH 3/3] Fix a bug in defer registration patch.

keep the uprobes engine active till the thread dies. Jim Keniston's observation on uprobes lifetime made me figure out an error in defer_registration patch that I sent earlier. Signed-off-by: Srikar Dronamraju --- kernel/uprobes_core.c |8 ++-- 1 files changed, 2 insertions(+), 6 dele

[PATCH 1/3] rework report_signal callback.

) and find_gdb_connection helper functions. 5. No need to lock gdb_connections_mutex when unregistering uprobes. Signed-off-by: Srikar Dronamraju --- kernel/utrace-gdb.c | 334 +++ 1 files changed, 202 insertions(+), 132 deletions(-) diff --

[PATCH 0/3] Fixes to gdbstub, uprobes.

ches/3/verify_and_then_post_process.patch Subject: [PATCH 3/3] Fix a bug in defer registration patch. File: /tmp/gdbstub-patches/3/fix_bug_defer_reg.patch -- Thanks and Regards Srikar Dronamraju

[PATCH 2/2] Allow deferred register/unregister of uprobes.

commit 20744cb97a3e4aec63ba7b92ce4115170fd468d6 Author: Srikar Dronamraju Date: Wed Aug 19 12:26:15 2009 +0530 Use deferred registration facility for register_uprobe Signed-off-by: Srikar Dronamraju --- kernel/utrace-gdb.c | 75 +- 1

[PATCH 1/2] Defer register/unregister if thread is stopped.

Make register_uprobe/ unregister_uprobe to defer if the task having an active probe is stopped or traced Signed-off-by: Srikar Dronamraju Reviewed-by: Jim Keniston --- kernel/uprobes_core.c | 78 + 1 files changed, 72 insertions(+), 6

[PATCH 0/2] Allow deferred registration if thread is stopped.

/uc_make_defer_un_register_uprobe.patch Subject: [PATCH 2/2] Allow deferred register/unregister of uprobes. File: /tmp/gdbstub-patches/2/gs_use_deferred_register_uprobe.patch -- Thanks and Regards Srikar Dronamraju

[PATCH] Dont attach iff there is an existing gdbstub engine.

a gdbstub connection exists for a process, we shouldnt be creating a new gdbstub connection. Signed-off-by: Srikar Dronamraju --- kernel/utrace-gdb.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/kernel/utrace-gdb.c b/kernel/utrace-gdb.c index 21bf995

[PATCH] Fix missing reference count

one of my previous changes to gdbstub. Signed-off-by: Srikar Dronamraju --- kernel/ubp_xol.c |1 + kernel/uprobes_core.c |1 + kernel/utrace-gdb.c |1 + 3 files changed, 3 insertions(+), 0 deletions(-) diff --git a/kernel/ubp_xol.c b/kernel/ubp_xol.c index f0a1a10

Re: [PATCH 09] move ->ptrace == 0 checks to ptrace_attach_task()

Hi Oleg, Thanks for the clarification. > > Please note the comment, this check relies on UTRACE_ATTACH_EXCLUSIVE > above. Once we see ->ptrace = 0 after utrace_attach_task(), nobody > can change ->ptrace. However after attaching an engine exclusively, (which would mean the child is not traced o

Re: [PATCH 09] move ->ptrace == 0 checks to ptrace_attach_task()

Hi Oleg, > > --- PU/kernel/ptrace.c~09_MV_PTRACE_CK2009-08-19 16:49:25.0 > +0200 > +++ PU/kernel/ptrace.c2009-08-20 20:04:59.0 +0200 > @@ -471,35 +471,47 @@ static int ptrace_attach_task(struct tas > { > struct utrace_engine *engine; > unsigned long

[PATCH 4/4] Stop once even for multiple interrupt requests

commit bd86cff51a2f221b6cb10649212e5392aea7bcb7 Author: Srikar Dronamraju Date: Wed Aug 19 11:43:53 2009 +0530 We only need to intimate gdb once if we get multiple requests for look There can be multiple stop requests before gdb gets control. However continue from gdb can resulting in the

[PATCH 3/4] Unregister uprobes after detach gdbstub engine

commit 90cc0931707c99459aea0f6601d7f5ce2756dbd8 Author: Srikar Dronamraju Date: Wed Aug 19 10:26:00 2009 +0530 While releasing, unregister uprobes if any after detach Currently because of the way uprobes works, (register/unregister may deadlock if one of the threads of this process is

[PATCH 2/4] Fix possible double detach of engine

commit bf679f65284b834b455e8453d10616073ff58d2c Author: Srikar Dronamraju Date: Tue Aug 18 18:15:49 2009 +0530 detach fix Saw a Oops message BUG: unable to handle kernel NULL pointer dereference at 0018 IP: [] get_utrace_lock+0x43/0x115 I figured out the reason for the oops

[PATCH 1/4] Fix report signal callback to work more reliably.

. With this patch, report_signal callback has enuf intelligence to know if SIGTRAPS were occurring at the address where gdb requested for breakpoints. Now we have a dummy uprobe_handler. Signed-off-by: Srikar Dronamraju diff --git a/kernel/utrace-gdb.c b/kernel/utrace-gdb.c index 0c84afb

[PATCH 0/4] Fixes to gdbstub.

: /tmp/gdbstub-patches/1/only_stop_once.patch -- Thanks and Regards Srikar Dronamraju

Re: resume from another engine results in loss of singlestep req.

> > Aaahhh. Srikar, I spent 3 hours trying to understand > > Your code does NOT reassert SINGLESTEP. Of course, ->report_signal > is not called again, utrace_get_signal() just clears ->report when > it is called after wakeup. > > Because you forgot to add QUIESCE to utrace_set_events's m

Re: resume from another engine results in loss of singlestep req.

> > Could you show the code please? I don't really understand how it > looks with 1+2 above. > I am attaching the code. The module code is in try_utrace/probe5_a.c and try_utrace/probe5_b.c. > But, just in case... I think module_b should re-assert SINGLESTEP > from either report_quiesce/report_

Re: resume from another engine results in loss of singlestep req.

Hi Roland, Thanks for the quick patch. > I think this might be the right fix. First, we change the order so that > UTRACE_INTERRUPT prevails over UTRACE_REPORT. (I'm really not sure why I > ever had it the other way around.) Next, we keep track of not only whether > one engine wanted a report

resume from another engine results in loss of singlestep req.

Hi Roland, If we have two utrace engines for a thread with first engine requesting UTRACE_STOP and second one requesting UTRACE_SINGLESTEP, utrace correctly gives priority to UTRACE_STOP. However when the first engine detaches(or resumes) the singlestep request from the second engine is not giv

[PATCH] gdbstub/uprobes : uprobe_unregister with halted target

ecause when gdb inserts a breakpoint when using a remote protocol and gdb stub uses uprobes then its better left to uprobes. In this case, when gdbstub hits a breakpoint, it should either be handled by uprobes or passed to the program. Please do let me know if this is a wrong assumption.

Re: gdbstub/uprobes problems: uprobe_unregister with halted target

* Jim Keniston [2009-08-03 11:10:00]: > > > > > > So as per my analysis, gdb_utrace_report_signal was called, followed by > > uprobe_report_signal. Since gdb_utrace_report_signal requested for > > UTRACE_STOP as resume action for SIGTRAP, the thread got stopped. > > uprobes was waiting for eith

Re: gdbstub/uprobes problems: uprobe_unregister with halted target

> > > > The target process side is also hung: > > > > zsh D 0002 3568 1288 1259 0x0080 > > 880078c57b98 0046 00011d4a > > 88006d4b8000 880078c57f50 7fff138b0858 > > 88006d4b83b8

Re: [RESEND] [PATCH 0/7] Ubp, Ssol and Uprobes

Hi Roland, et al, Did you get a chance to review this patchset? I was planning to post to LKML after addressing comments from you. -- Thanks and Regards Srikar > Hi, > > This patchset implements uprobes over utrace. > Please review the patchset and provide your valuable comments. > These patc

Re: linux kernel gdb stub for userspace processes, prototype version 3

Hi Frank, Roland Using UTRACE_STOP as action in report_signal and report_quiesce results in utrace_stop() being called which causes the thread to be scheduled out. This results in gdb not getting control/data from the remote and results in gdb command prompt. >From looking at kgdb-stub, I feel it

Re: linux kernel gdb stub for userspace processes, prototype version 3

UTRACE_SIGNAL_REPORT before the utrace-gdb quiesce handler gets called. The patch is as below. commit eb53493b0208bc036dc570560ac3449aed450fbf Author: Srikar Dronamraju Date: Thu Jul 9 21:03:45 2009 +0530 make sure quiesce doesnt make the process to stop at the signal handler diff --git

[RESEND] [PATCH 7/7] Ftrace plugin for Uprobes.

00ed <...>-6424 [004] 1156.853401: : 0x4004d8: A ARG 4: <...>-6424 [004] 1156.853402: : 0x4004d8: A ARG 5: 0048 TODO: - use ringbuffer - Allow user to specify Nick Name for probe addresses. - Dump arguments from floating point registe

[RESEND] [PATCH 6/7] Uprobes documentation.

hit takes about 3 +microseconds to process. Specifically, a benchmark that hits the +same probepoint repeatedly, firing a simple handler each time, reports +300,000 to 350,000 hits per second, depending on the architecture. + +Here are sample overhead figures (in usec) for x86 architecture. + +x86: Int

[RESEND] [PATCH 5/7] x86 support for Uprobes

x86 support for Uprobes Signed-off-by: Jim Keniston --- arch/x86/Kconfig |1 + arch/x86/include/asm/uprobes.h | 27 +++ 2 files changed, 28 insertions(+) Index: uprobes.git/arch/x86/Kconfig =

[RESEND] [PATCH 3/7] Execution out of line (XOL)

expand the vma, allocate a new vma. Signed-off-by: Jim Keniston Signed-off-by: Srikar Dronamraju --- arch/Kconfig|4 include/linux/ubp_xol.h | 56 kernel/Makefile |1 kernel/ubp_xol.c| 627 4 files

[RESEND] [PATCH 2/7] x86 support for UBP

x86 support for user breakpoint Infrastructure This patch provides x86 specific userspace breakpoint assistance implementation details. This patch requires "x86: instruction decoder API" patch. http://lkml.org/lkml/2009/6/1/459 Signed-off-by: Jim Keniston --- arch/x86/Kconfig |

[RESEND] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)

methods. UBP currently supports both single stepping inline and execution out of line strategies. Two different probepoints in the same process can have two different strategies. You need to follow this up with the UBP patch for your architecture. Signed-off-by: Jim Keniston Signed-off-by: Srikar

[RESEND] [PATCH 0/7] Ubp, Ssol and Uprobes

I am resending this patch as people reported that they didn't receive my earlier mail. Hi, This patchset implements uprobes over utrace. Please review the patchset and provide your valuable comments. These patches have been tested on the current utrace tree(commit id cf890ad46816982f3b8b5064d2f

Running gdb and uprobes on the same program [ bug 9826 ]

Hi Roland, Here is analysis of the bug 9826. Can you please let me know your thoughts? Summary of the problem: Probing a program started by gdb causes the traced program to receive thousounds of SIGSEGV signals. Consider two engines, first engine(gdb) which hasn't inserted any breakpoints and s

Re: Running gdb and uprobes on the same program [ bug 9826 ]

* Srikar Dronamraju [2009-03-03 18:56:53]: > Hi Roland, > > Here is analysis of the bug 9826. Can you please let me know your > thoughts? > > Summary of the problem: > Probing a program started by gdb causes the traced program to receive > thousounds of SIGSEGV si

Re: Utrace in -next tree?

* Roland McGrath [2008-10-17 13:09:34]: > > What are your thoughts of getting utrace git tree into linux-next? > > That way, utrace will have more extensive visibility and testing. > > I would certainly like to. I hope that after I next post the latest utrace > patch series for more review, it

Re: abt froggy

Hi Chris, Thanks for your quick reply. I have been regularly updating from cvs. So I thought I was always on the latest copy. To confirm I checked out a new copy using cvs -z9 -d :ext:[EMAIL PROTECTED]:/cvs/systemtap co froggy and compared it the copy I update regularly and they seem to be

Git log

Hi Roland, git log is suppose to show reverse chronological listing of changes. However "git log" on utrace git is not showing reverse chronological listing of changes. Do you suggest way other than "git log" to know the last few commits that went into utrace. -- Thanks and Regards Srikar

Re: ld: drivers/media/built-in.o: No such file: No such file or directory

* Peter Teoh <[EMAIL PROTECTED]> [2008-06-17 21:19:53]: Hi Peter, I also faced a problem with compiling code in drivers/media which was resolved by applying the patch at this link http://lkml.org/lkml/2008/4/30/62 -Srikar > I got the latest error af

compile issues on utrace git tree.

Hi Roland, When I tried to do a make "allmodconfig" or make "allyesconfig" from utrace kernel tree cloned from git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git I see this error - kernel/exit.c: In function â€

Re: [RFC] [PATCH] Breakpoint assistance(SSOL) using utrace infrastructure.

* Srinivasa D S <[EMAIL PROTECTED]> [2008-04-16 11:59:39]: Hi Srinivasa, Can you please break this patch into - The actual breakpoint assistance code. - single stepping out of line (ssol). - How to use breakpoint assistance + ssol. -- Thanks and Regards Srikar > Hi > > I have been workin