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 --]
next prev parent 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).