* [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