public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Vara Prasad <prasadav@us.ibm.com>
To: Mathieu Lacage <Mathieu.Lacage@sophia.inria.fr>
Cc: "Frank Ch. Eigler" <fche@redhat.com>, systemtap@sources.redhat.com
Subject: Re: user kprobes vs debuggers
Date: Fri, 03 Feb 2006 16:12:00 -0000	[thread overview]
Message-ID: <43E380D0.3000905@us.ibm.com> (raw)
In-Reply-To: <1138953635.3886.85.camel@chronos>

Mathieu Lacage wrote:

>On Thu, 2006-02-02 at 22:37 -0800, Vara Prasad wrote:
>
>  
>
>>I think this mechanism should handle applications that have breakpoints 
>>builtin as well because i am thinking they are going to use ptrace 
>>interface as well to register the breakpoint, is that correct.
>>    
>>
>
>No, such applications (at least, mine) are going to insert int3 by hand
>in the code (yes, I know, this is evil but it is possible).
>  
>
I did a cursory glance of the code that handles the signals looks like 
in this case OS thinks there is no process tracing and there will be no 
probes hence code will work as of today which is to deliver the signal 
to the process who put the int3.

The only complication is if a user wants to add a userspace probe at 
this address then we need to check if the instruction being replaced is 
int3 in which case we don't really need to replace the instruction 
instead we should just record there are multiple breakpoints one for 
userspace probes and one for userspace application. After we run the 
userspace probes handler we need to deliver the signal to the 
application, there may be some complications in making a clean code to 
achieve this but i have not spent enough time to address this at this time.

Mathieu, do you know what behavior you get today if you try to put a breakpoint using gdb at the same address you have added int3?


>If you are interested, it is some sort of profiler/tracer available from
>there: http://www-sop.inria.fr/dream/personnel/Mathieu.Lacage/bozo-
>profiler/
>
>regards,
>Mathieu
>  
>


  reply	other threads:[~2006-02-03 16:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-02 19:22 Frank Ch. Eigler
2006-02-03  6:37 ` Vara Prasad
2006-02-03  8:04   ` Mathieu Lacage
2006-02-03 16:12     ` Vara Prasad [this message]
2006-02-06  9:58 ` Ananth N Mavinakayanahalli
2006-02-09 13:59   ` Richard J Moore
2006-02-03 17:43 Stone, Joshua I
2006-02-03 18:39 ` Vara Prasad
2006-02-03 20:29 Stone, Joshua I
2006-02-03 21:08 ` James Dickens
2006-02-03 22:00 ` Vara Prasad

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43E380D0.3000905@us.ibm.com \
    --to=prasadav@us.ibm.com \
    --cc=Mathieu.Lacage@sophia.inria.fr \
    --cc=fche@redhat.com \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).