On Thu, 13 Nov 2008 06:31:00 +0100, Joel Brobecker wrote:
> > +  /* It may be currently unreachable breakpoint which is never permanent.  */
> > +  if (val != 0)
> > +    return NULL;
> 
> I am not sure I understand the relationship between the fact that
> the memory is unreachable (do we know when this might happen?)

Originally I called there error() in the case of failed target_read_memory()
as being done in score_breakpoint_from_pc().  But it broke the testsuite for:
FAIL: gdb.cp/cp-relocate.exp: break *'int func<1>(int)'
FAIL: gdb.cp/cp-relocate.exp: break *'int func<2>(int)'

One can reproduce it more easily by simple `b *0':
echo 'int main (void) { return 0; }' >mainx.c; gcc -o mainx mainx.c -Wall -ggdb2; ./gdb -nx -ex start -ex 'b *0' ./mainx

> I would have just said that we need to be able to read the original memory
> location to produce the breakpoint sequence.

It currently depends on `set breakpoint always-inserted'.  In the default mode
it broke the testsuite.  Found `return NULL' as a minimal regression-free
solution.


> > +     For L+X slot pair we are at the X slot (3) so we should not touch the
> > +     L slot - the upper 41 bits of the parameter.  */
> 
> Not being extremely familiar with the ia64 chip, I think I'll trust you
> with how the above translates into the code below:

There exist these templates (volume 3, rev 2.2, page 284/986):
  MII MII MLX --- MMI MMI MFI MMF MIB MBB --- BBB MMB --- MFB ---
In the MLX template case slot 1 contains the opcode + 21 data bits and
slot 2 contains 41 data bits (slot 2 is used whole as a data field).

Updated my '(3)' (meaning 3rd slot).  Intel uses naming `slot {0,1,2}' while
GDB had there naming `{2nd,3rd} slot'.  Unified it to `slot {0,1,2}'.


Thanks,
Jan