public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Phil Muldoon <pmuldoon@redhat.com>
To: Mark Wielaard <mark@klomp.org>
Cc: frysk@sourceware.org
Subject: Re: [SCM]  master: Implement hasWatchpointTriggered in abstract,  	and sub-classes.
Date: Wed, 02 Apr 2008 08:53:00 -0000	[thread overview]
Message-ID: <47F34972.8080403@redhat.com> (raw)
In-Reply-To: <1207122509.4953.27.camel@cc1341701-a.deven1.ov.home.nl>

Mark Wielaard wrote:
> debugStatus & (1L << index)) != 0;
>
> where debug status is the debug status register,  and index is the 
> watchpoint to check.
>   
>
> I think this is a little too architecture specific and a little error
> prone in usage. Code using this now has to iterate over all the possible
> watchpoint indexes for a particular architecture. Maybe this is small
> and trivial on all architectures, but it would feel more natural imho if
> there was just a method to query which watchpoint index was triggered if
> any. Something like:
>
> public abstract int watchpointTriggered(Task task);
>   

Originally I did have something like this, but it does not answer the 
scenario of what happens when a sigtrap is delivered that denotes 
multiple watchpoints being triggered? There's no real clean way to do 
this per architecture. Could return an array of .. perhaps booleans 
denoting each register as being triggered, or maybe a list of .. same 
again, what? As there already is a general function implemented:

int getWatchpointCount()

the user can iterate over the watchpoints themselves in a simple loop.  
If you can make watchpointTriggered work so it accounts for multiple 
watchpoints hit, I'll be happy ;)

Regards

Phil

>>  Should the bit be reset in hasWatchpointTriggered? 
>> Or in a separate function function called as a separate API?
>>     
>
> A separate method is cleaner. The problem I had with that (in the
> stepping flag) is that it then becomes somewhat harder to know when to
> clear the status flags. Since the state machine is guaranteed to check
> the status before any state transitions it is somewhat easier to make it
> a check-and-clear-status method:
> http://sourceware.org/ml/frysk/2007-q1/msg00024.html
> If you have a separate method you can either call it directly after
> checking the status, or in the Running.sendContinue() method. I
> introduced this to have one point in the ptrace state machine where a
> Task is set running again:
> http://sourceware.org/ml/frysk/2007-q2/msg00329.html
> We also already discussed basing the stepping flag on this new
> infrastructure: http://sourceware.org/ml/frysk/2007-q3/msg00324.html
> (And I agreed it would be somewhat cleaner than what is done now.)
>
>   

Ok I'll look at what goes on here. The second half of the question is, 
how and by what mechanism do you allow the user to continue a task. By 
default the task is stopped and will stay stopped until such a time that 
the user is done inspecting the environment. How will the user restart 
the task?

Thanks!

Regards

Phil
> Cheers,
>
> Mark
>
>   

  reply	other threads:[~2008-04-02  8:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080401204912.27374.qmail@sourceware.org>
2008-04-01 20:58 ` Phil Muldoon
2008-04-02  7:52   ` Mark Wielaard
2008-04-02  8:53     ` Phil Muldoon [this message]
2008-04-02 10:54       ` Mark Wielaard

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=47F34972.8080403@redhat.com \
    --to=pmuldoon@redhat.com \
    --cc=frysk@sourceware.org \
    --cc=mark@klomp.org \
    /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).