public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Elena Zannoni <elena.zannoni@oracle.com>
Cc: frysk <frysk@sourceware.org>
Subject: Re: Minutes 20070516
Date: Wed, 16 May 2007 15:17:00 -0000	[thread overview]
Message-ID: <1179327499.4477.41.camel@dijkstra.wildebeest.org> (raw)
In-Reply-To: <464B1012.2050606@oracle.com>

[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]

Hi elena,

Thanks again for making the meeting minutes. Much appreciated.

On Wed, 2007-05-16 at 10:07 -0400, Elena Zannoni wrote:
> thread specific breakpoints? Not yet. But the mechanism is in place
> already to detect if a thread must ignore a breakpoint or not.  Right
> now: Breakpoint is hit->all tasks get notified. BP set globally in
> process space. Notify the listener, and it decides if the task is the
> one that we are interested in. There seems to have been an interface
> change at some point, can this be discussed on list? It's not clear
> what has changed. (Mark?) Bind bp to process or to task? 

I don't believe anything changed here since it was implemented. Which
doesn't mean it cannot/shouldn't be improved (now that it is implemented
I see why you want to have it setup differently, isn't that always the
case...). Here is how it currently works:

- Given a Task you call requestAddCodeObserver(TaskObserver.Code, long)
where the address is given as a long and the Code observer is the
listener that you want to be called whenever the Task hits the given
address.
- This inserts a breakpoint at the given address in the Proc associated
with the Task (the breakpoint is global since the address space is
shared between Tasks).
- Whenever the breakpoint is hit in the process by a Task that task is
temporarily suspended and frysk-core is notified about the event.
- frysk-core calls the given Code observer is called with updateHit
(Task, long) indicating the Task that tripped over the breakpoint at a
given address. Returning Action.BLOCK from that method will permanently
block that Task, returning Action.CONTINUE the Task will be resumed
(given that no other listener returned BLOCK).

> HPD has thread sets/ actionpoints (signals, etc...)

Totalview also has a task groups idea. Maybe that is also interesting to
look at as inspiration on how to define thread/task/process sets:
http://www.totalviewtech.com/Documentation/latest/html/User_Guide/CreatingGroups.html

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-05-16 14:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-16 14:44 Elena Zannoni
2007-05-16 15:17 ` Mark Wielaard [this message]
2007-05-16 21:32   ` Andrew Cagney

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=1179327499.4477.41.camel@dijkstra.wildebeest.org \
    --to=mark@klomp.org \
    --cc=elena.zannoni@oracle.com \
    --cc=frysk@sourceware.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).