This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] register_modified_event


Hi,

Here's another event fallout from Apple's MI work. This defines a new event (and adds two notifications for it), register_modified_event, which is sent whenever a register is modified (usually by a user in the command line, but could be via MI or varobj, etc).

As expected, this causes no regressions in the testsuite. I have tests for this, but I can't commit any of them until all my MI stuff is complete, since event notifications in MI are quite new (and still in approval process).

Keith

PS. FYI, I would have named it register_changed_event, just like the hook, but there is a name conflict with register_changed in regcache.c.
Keith,

I don't the register_modified (the changelog called it register_update) is correct. Trying to supply a register number, for instance, is just misleading.

See:
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=469

There is also a number of postings to gdb@ about this (I think it was JimI last major posting).

enjoy,
Andrew



ChangeLog
2002-08-18 Keith Seitz <keiths@redhat.com>

* gdb-events.sh: Add selected_frame_level_changed event.
* gdb-events.c: Regenerated.
* gdb-events.c: Regenerated.
* valops.c (value_assign): Add register_update event notification
for lval_register and lval_reg_frame_relative.

Patch
Index: gdb-events.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdb-events.sh,v
retrieving revision 1.13
diff -p -r1.13 gdb-events.sh
*** gdb-events.sh 16 Aug 2002 16:09:07 -0000 1.13
--- gdb-events.sh 19 Aug 2002 22:11:13 -0000
*************** f:void:tracepoint_create:int number:numb
*** 65,70 ****
--- 65,71 ----
f:void:tracepoint_delete:int number:number
f:void:tracepoint_modify:int number:number
f:void:architecture_changed:void
+ f:void:register_modified:int regno:regno
#*:void:annotate_starting_hook:void
#*:void:annotate_stopped_hook:void
#*:void:annotate_signalled_hook:void
*************** f:void:architecture_changed:void
*** 87,93 ****
#*:void:readline_begin_hook:char *format, ...:format
#*:char *:readline_hook:char *prompt:prompt
#*:void:readline_end_hook:void
- #*:void:register_changed_hook:int regno:regno
#*:void:memory_changed_hook:CORE_ADDR addr, int len:addr, len
#*:void:context_hook:int num:num
#*:int:target_wait_hook:int pid, struct target_waitstatus *status:pid, status
--- 88,93 ----
Index: valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.66
diff -p -r1.66 valops.c
*** valops.c 1 Aug 2002 17:18:33 -0000 1.66
--- valops.c 19 Aug 2002 22:11:41 -0000
*************** value_assign (struct value *toval, struc
*** 678,683 ****
--- 678,686 ----
VALUE_CONTENTS (fromval), TYPE_LENGTH (type));
#endif
}
+ + register_modified_event (VALUE_REGNO (toval));
+ /* Assigning to the stack pointer, frame pointer, and other
(architecture and calling convention specific) registers may
cause the frame cache to be out of date. We just do this
*************** value_assign (struct value *toval, struc
*** 765,770 ****
--- 768,774 ----
if (register_changed_hook)
register_changed_hook (-1);
+ register_modified_event (regno);
}
break;




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]