Hi,

Teresa tripped over the limitation of the LogicalMemoryBuffer that made
the buffer read-only. This prevented changing the value static variables
found at a specific memory locations as described in bug #5201. I
changed LogicMemoryBuffer to allow writing to locations that don't have
a breakpoint instruction installed. This should cover almost all cases
we use now since code and variables live at different locations
normally, so it should never happen that you put a breakpoint
instruction on some code location and that same location also is the
address of a memory variable. Luckily there were already tests written
for this, so I only had to enable them for LogicMemoryBuffer.

2007-10-20  Mark Wielaard  <mwielaard@redhat.com>

    Fixes bug #5201
    * LogicalMemoryBuffer.java (poke): Allow poke when no breakpoints
    in the way.
    * TestByteBuffer.java: Enable LogicalMemoryBuffer write tests.

For the general case of changing code while the core might have a
breakpoint installed on top of the code to be changed I opened a new bug
report http://sourceware.org/bugzilla/show_bug.cgi?id=5202

        Currently when trying to poke code which has breakpoint
        installed through the LogicalMemoryBuffer will fail. You can
        only change memory which the core isn't using itself at the
        moment. When changing memory on which the core has put software
        breakpoint instructions the set-aside memory of the Instruction
        should be changed (so that if the breakpoint is removed or
        stepped the new code is used).
        
        This is a little tricky to change. When a Breakpoint is found
        installed the underlying Instruction class should be altered
        (but Instruction is currently a immutable class). Care should be
        taken if the Breakpoint is currently stepped, or if the memory
        is changed asynchronous from the event thread (which means it
        could intersect with a breakpoint being placed right at the same
        time).
        
Cheers,

Mark