Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [commit] new observer.[hc] files
@ 2003-02-28  7:38 Joel Brobecker
  2003-02-28 15:22 ` Daniel Jacobowitz
  0 siblings, 1 reply; 5+ messages in thread
From: Joel Brobecker @ 2003-02-28  7:38 UTC (permalink / raw)
  To: gdb-patches

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

As requested by Andrew in:
http://sources.redhat.com/ml/gdb-patches/2003-02/msg00773.html

I checked the attached files in. There have slightly been modified from
the file originally sent: added the copyright headers, some documentation,
introduced the notion of subject from the "Design Patterns" book, added
a missing "static" keyword for an internal function, etc.

2003-02-27  J. Brobecker  <brobecker@gnat.com>

        * observer.h, observer.c: New file.

And ARGH, of course I just noticed AFTER the check in that I forgot
to update the comments for my last minute parameter renamings...
So I then committed the following change:

2003-02-27  J. Brobecker  <brobecker@gnat.com>

        * observer.c: Minor comments edits.

The attached files reflect the lastest (corrected) version.

The changes to the Makefile will shortly follow as an RFA (should be
pretty straightforward, but an extra pair of eyes shouldn't hurt).

-- 
Joel

[-- Attachment #2: observer.h --]
[-- Type: text/plain, Size: 1206 bytes --]

/* GDB Notifications to Observers.
   Copyright 2003 Free Software Foundation, Inc.

   This file is part of GDB.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 59 Temple Place - Suite 330,
   Boston, MA 02111-1307, USA.  */

#ifndef OBSERVER_H
#define OBSERVER_H

struct observer;

/* normal_stop notifications.  */

typedef void (observer_normal_stop_ftype) (void);

extern struct observer *
  observer_attach_normal_stop (observer_normal_stop_ftype *f);
extern void observer_detach_normal_stop (struct observer *observer);
extern void observer_notify_normal_stop (void);

#endif /* OBSERVER_H */

[-- Attachment #3: observer.c --]
[-- Type: text/plain, Size: 6201 bytes --]

/* GDB Notifications to Observers.
   Copyright 2003 Free Software Foundation, Inc.

   This file is part of GDB.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 59 Temple Place - Suite 330,
   Boston, MA 02111-1307, USA.  */

/* An observer is an entity who is interested in being notified when GDB
   reaches certain states, or certain events occur in GDB. The entity being
   observed is called the Subject. To receive notifications, the observer
   attaches a callback to the subject. One subject can have several
   observers.

   This file implements an internal generic low-level event notification
   mechanism based on the Observer paradigm described in the book "Design
   Patterns".  This generic event notification mechansim is then re-used
   to implement the exported high-level notification management routines
   for all possible notifications.

   The current implementation of the generic observer provides support
   for contextual data. This contextual data is given to the subject
   when attaching the callback. In return, the subject will provide
   this contextual data back to the observer as a parameter of the
   callback.

   FIXME: The current support for the contextual data is only partial,
   as it lacks a mechanism that would deallocate this data when the
   callback is detached. This is not a problem so far, as this contextual
   data is only used internally to hold a function pointer. Later on,
   if a certain observer needs to provide support for user-level
   contextual data, then the generic notification mechanism will need
   need to be enhanced to allow the observer to provide a routine to
   deallocate the data when attaching the callback.

   This file is currently maintained by hand, but the long term plan
   if the number of different notifications starts growing is to create
   a new script (observer.sh) that would generate this file, and the
   associated documentation.  */

#include "defs.h"
#include "observer.h"

/* The internal generic observer.  */

typedef void (generic_observer_notification_ftype) (const void *data,
						    const void *args);

struct observer
{
  generic_observer_notification_ftype *notify;
  /* No memory management needed for the following field for now.  */
  void *data;
};

/* A list of observers, maintained by the subject.  A subject is
   actually represented by its list of observers.  */

struct observer_list
{
  struct observer_list *next;
  struct observer *observer;
};

/* Allocate a struct observer_list, intended to be used as a node
   in the list of observers maintained by a subject.  */

static struct observer_list *
xalloc_observer_list_node (void)
{
  struct observer_list *node = XMALLOC (struct observer_list);
  node->observer = XMALLOC (struct observer);
  return node;
}

/* The opposite of xalloc_observer_list_node, frees the memory for
   the given node.  */

static void
xfree_observer_list_node (struct observer_list *node)
{
  xfree (node->observer);
  xfree (node);
}

/* Attach the callback NOTIFY to a SUBJECT.  The DATA is also stored,
   in order for the subject to provide it back to the observer during
   a notification.  */

static struct observer *
generic_observer_attach (struct observer_list **subject,
			 generic_observer_notification_ftype * notify,
			 void *data)
{
  struct observer_list *observer_list = xalloc_observer_list_node ();

  observer_list->next = *subject;
  observer_list->observer->notify = notify;
  observer_list->observer->data = data;
  *subject = observer_list;

  return observer_list->observer;
}

/* Remove the given OBSERVER from the SUBJECT.  Once detached, OBSERVER
   should no longer be used, as it is no longer valid.  */

static void
generic_observer_detach (struct observer_list **subject,
			 const struct observer *observer)
{
  struct observer_list *previous_node = NULL;
  struct observer_list *current_node = *subject;

  while (current_node != NULL)
    {
      if (current_node->observer == observer)
	{
	  if (previous_node != NULL)
	    previous_node->next = current_node->next;
	  else
	    *subject = current_node->next;
	  xfree_observer_list_node (current_node);
	  return;
	}
      previous_node = current_node;
      current_node = current_node->next;
    }

  /* We should never reach this point.  However, this should not be
     a very serious error, so simply report a warning to the user.  */
  warning ("Failed to detach observer");
}

/* Send a notification to all the observers of SUBJECT.  ARGS is passed to
   all observers as an argument to the notification callback.  */

static void
generic_observer_notify (struct observer_list *subject, const void *args)
{
  struct observer_list *current_node = subject;

  while (current_node != NULL)
    {
      (*current_node->observer->notify) (current_node->observer->data, args);
      current_node = current_node->next;
    }
}

/* normal_stop notifications.  */

static struct observer_list *normal_stop_subject = NULL;

static void
observer_normal_stop_notification_stub (const void *data,
					const void *unused_args)
{
  observer_normal_stop_ftype *notify = (observer_normal_stop_ftype *) data;
  (*notify) ();
}

struct observer *
observer_attach_normal_stop (observer_normal_stop_ftype *f)
{
  return generic_observer_attach (&normal_stop_subject,
				  &observer_normal_stop_notification_stub,
				  (void *) f);
}

void
observer_detach_normal_stop (struct observer *observer)
{
  generic_observer_detach (&normal_stop_subject, observer);
}

void
observer_notify_normal_stop (void)
{
  generic_observer_notify (normal_stop_subject, NULL);
}

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [commit] new observer.[hc] files
  2003-02-28  7:38 [commit] new observer.[hc] files Joel Brobecker
@ 2003-02-28 15:22 ` Daniel Jacobowitz
  2003-02-28 16:10   ` Andreas Schwab
  2003-02-28 16:14   ` Andrew Cagney
  0 siblings, 2 replies; 5+ messages in thread
From: Daniel Jacobowitz @ 2003-02-28 15:22 UTC (permalink / raw)
  To: gdb-patches

On Thu, Feb 27, 2003 at 11:22:43PM -0800, Joel Brobecker wrote:
> As requested by Andrew in:
> http://sources.redhat.com/ml/gdb-patches/2003-02/msg00773.html
> 
> I checked the attached files in. There have slightly been modified from
> the file originally sent: added the copyright headers, some documentation,
> introduced the notion of subject from the "Design Patterns" book, added
> a missing "static" keyword for an internal function, etc.

> /* The internal generic observer.  */
> 
> typedef void (generic_observer_notification_ftype) (const void *data,
> 						    const void *args);
> 
> struct observer
> {
>   generic_observer_notification_ftype *notify;
>   /* No memory management needed for the following field for now.  */
>   void *data;
> };

> static void
> observer_normal_stop_notification_stub (const void *data,
> 					const void *unused_args)
> {
>   observer_normal_stop_ftype *notify = (observer_normal_stop_ftype *) data;
>   (*notify) ();
> }

Is this extra indirection really necessary?  Because I'm 99% sure it
won't work on several 64-bit platforms.  Function pointers and data
pointers are not required to have the same size; on IA-64 I believe
that a function pointer is 128 bits and a data pointer is 64 bits.

Why not require all observer functions to take the same arguments
instead?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [commit] new observer.[hc] files
  2003-02-28 15:22 ` Daniel Jacobowitz
@ 2003-02-28 16:10   ` Andreas Schwab
  2003-02-28 16:14   ` Andrew Cagney
  1 sibling, 0 replies; 5+ messages in thread
From: Andreas Schwab @ 2003-02-28 16:10 UTC (permalink / raw)
  To: gdb-patches

Daniel Jacobowitz <drow@mvista.com> writes:

|> Is this extra indirection really necessary?  Because I'm 99% sure it
|> won't work on several 64-bit platforms.  Function pointers and data
|> pointers are not required to have the same size; on IA-64 I believe
|> that a function pointer is 128 bits and a data pointer is 64 bits.

Function pointer are still 64 bits on ia64 (and ppc64).  They do not point
to the code itself, but to a descriptor which contains the actual code
pointer and the gp value.  But I agree that mixing function pointer and
object pointers should be avoided.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [commit] new observer.[hc] files
  2003-02-28 15:22 ` Daniel Jacobowitz
  2003-02-28 16:10   ` Andreas Schwab
@ 2003-02-28 16:14   ` Andrew Cagney
  2003-02-28 16:39     ` Daniel Jacobowitz
  1 sibling, 1 reply; 5+ messages in thread
From: Andrew Cagney @ 2003-02-28 16:14 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: gdb-patches

> static void
>> observer_normal_stop_notification_stub (const void *data,
>> 					const void *unused_args)
>> {
>>   observer_normal_stop_ftype *notify = (observer_normal_stop_ftype *) data;
>>   (*notify) ();
>> }
> 
> 
> Is this extra indirection really necessary?  Because I'm 99% sure it
> won't work on several 64-bit platforms.  Function pointers and data
> pointers are not required to have the same size; on IA-64 I believe
> that a function pointer is 128 bits and a data pointer is 64 bits.

Like the PowerABI?  That has a 32 bit pointer but a 64 bit function 
descriptor.  void* ends up containing the address of the function 
descriptor.  Anyway, "defs.h" has the comment:

/* NOTE: cagney/2000-03-04: This typedef is strictly for the
    make_cleanup function declarations below. Do not use this typedef
    as a cast when passing functions into the make_cleanup() code.
    Instead either use a bounce function or add a wrapper function.
    Calling a f(char*) function with f(void*) is non-portable. */
typedef void (make_cleanup_ftype) (void *);

Once the code gets converted into a SED script, it can always be changed 
to something more strict.

> Why not require all observer functions to take the same arguments
> instead?

Per the original thread, it is to ensure strongly typed interfaces.

Andrew



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [commit] new observer.[hc] files
  2003-02-28 16:14   ` Andrew Cagney
@ 2003-02-28 16:39     ` Daniel Jacobowitz
  0 siblings, 0 replies; 5+ messages in thread
From: Daniel Jacobowitz @ 2003-02-28 16:39 UTC (permalink / raw)
  To: gdb-patches

On Fri, Feb 28, 2003 at 11:17:10AM -0500, Andrew Cagney wrote:
> >static void
> >>observer_normal_stop_notification_stub (const void *data,
> >>					const void *unused_args)
> >>{
> >>  observer_normal_stop_ftype *notify = (observer_normal_stop_ftype *) 
> >>  data;
> >>  (*notify) ();
> >>}
> >
> >
> >Is this extra indirection really necessary?  Because I'm 99% sure it
> >won't work on several 64-bit platforms.  Function pointers and data
> >pointers are not required to have the same size; on IA-64 I believe
> >that a function pointer is 128 bits and a data pointer is 64 bits.
> 
> Like the PowerABI?  That has a 32 bit pointer but a 64 bit function 
> descriptor.  void* ends up containing the address of the function 
> descriptor.  Anyway, "defs.h" has the comment:
> 
> /* NOTE: cagney/2000-03-04: This typedef is strictly for the
>    make_cleanup function declarations below. Do not use this typedef
>    as a cast when passing functions into the make_cleanup() code.
>    Instead either use a bounce function or add a wrapper function.
>    Calling a f(char*) function with f(void*) is non-portable. */
> typedef void (make_cleanup_ftype) (void *);
> 
> Once the code gets converted into a SED script, it can always be changed 
> to something more strict.
> 
> >Why not require all observer functions to take the same arguments
> >instead?
> 
> Per the original thread, it is to ensure strongly typed interfaces.

OK, that makes good sense.  Anyway, my concerns about casting a
function pointer to void* seem to have be moot; we can eliminate some
of the grossness when/if this becomes a generated file.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-02-28 16:39 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-02-28  7:38 [commit] new observer.[hc] files Joel Brobecker
2003-02-28 15:22 ` Daniel Jacobowitz
2003-02-28 16:10   ` Andreas Schwab
2003-02-28 16:14   ` Andrew Cagney
2003-02-28 16:39     ` Daniel Jacobowitz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox