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


On Tue, 20 Aug 2002, Andrew Cagney wrote:

> It can be fixed two ways:
> 
> - like you suggest, provide the name/number table (straight forward)
> 
> - have mi renumber things so that the holes are eliminated (Arrgtg....)

I'll submit my patch to get the numbering, since I've done that already. 
We will see if anyone jumps out wanting to do it otherwise then.

> Yes, but just call target_changed_event() directly.

Done.

> (I wonder if it would be better to add it to store_register() and 
> target_write_memory()?  I suspect the problem will be that it will also 
> trigger on breakpoints :-(.  Suggest filing a bug report about this.)

gdb/665

For the record, here is what I committed:

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

        * gdb-events.sh: Add target-changed event.
        * gdb-events.c: Regenerated.
        * gdb-events.c: Regenerated.
        * valops.c (value_assign): Add target-changed event notification
        to inlval_register, lval_memory, 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	21 Aug 2002 15:33:39 -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:target_changed:void
  #*:void:annotate_starting_hook:void
  #*:void:annotate_stopped_hook:void
  #*:void:annotate_signalled_hook:void
*************** f:void:architecture_changed:void
*** 87,94 ****
  #*: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
  #*:void:call_command_hook:struct cmd_list_element *c, char *cmd, int from_tty:c, cmd, from_tty
--- 88,93 ----
Index: valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.67
diff -p -r1.67 valops.c
*** valops.c	19 Aug 2002 23:19:53 -0000	1.67
--- valops.c	21 Aug 2002 15:33:40 -0000
*************** value_assign (struct value *toval, struc
*** 633,638 ****
--- 633,639 ----
  	write_memory (changed_addr, dest_buffer, changed_len);
  	if (memory_changed_hook)
  	  memory_changed_hook (changed_addr, changed_len);
+ 	target_changed_event ();
        }
        break;
  
*************** value_assign (struct value *toval, struc
*** 678,683 ****
--- 679,687 ----
  			      VALUE_CONTENTS (fromval), TYPE_LENGTH (type));
  #endif
  	}
+ 
+       target_changed_event ();
+ 
        /* 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 ****
--- 769,775 ----
  
  	if (register_changed_hook)
  	  register_changed_hook (-1);
+ 	target_changed_event ();
        }
        break;
  


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