Re: [patch] ia64: Fix breakpoints memory shadow

[Joel Brobecker <brobecker@adacore.com>]

> According to ISO C90 6.5.7 such a static array is (was) initialized to zeroes.

Ah - I actually looked at the draft document I have, but I cannot
seem to be able to navigate this document just yet, so I didn't
find anything that confirmed this. From outside, it did look like
the logic was broken, which is why I pointed this out. As you said,
it was already broken before, so thanks for fixing it.

> 2008-11-11  Jan Kratochvil  <jan.kratochvil@redhat.com>
> 
> 	Fix automatic restoration of breakpoints memory for ia64.
> 	* ia64-tdep.c: New #if check on BREAKPOINT_MAX vs. BUNDLE_LEN.  
> 	(ia64_memory_insert_breakpoint): New comment part for SHADOW_CONTENTS
> 	content.  Remova variable instr.  New variable cleanup.  Force
                  ^^^^^^ Typo: Remove

> 	automatic breakpoints restoration.  PLACED_SIZE and SHADOW_LEN are now
> 	set larger, to BUNDLE_LEN - 2.  Variable `bundle' type update.
> 	(ia64_memory_remove_breakpoint): Rename variables bundle to bundle_mem
> 	and instr to instr_saved.  New variables bundle_saved and
> 	instr_breakpoint.  Comment new reasons why we need to disable automatic
> 	restoration of breakpoints.  Assert PLACED_SIZE and SHADOW_LEN.  New
> 	check of the original memory content.
> 	(ia64_breakpoint_from_pc): Implement the emulation of permanent
> 	breakpoints compatible with current bp_loc_is_permanent.
> 	(template_encoding_table): Make it `const'.
> 	* breakpoint.c (bp_loc_is_permanent): Support unsupported software
> 	breakpoints.  New variables `cleanup' and `retval' to protect
> 	target_read_memory by make_show_memory_breakpoints_cleanup.

For the future, I think that the second sentence is unnecessarily
precise, so you can save yourself a little bit. But that's OK too.

> 	* monitor.c (monitor_insert_breakpoint): Remove unused variable `bp'.

This one should really have been a separate change. It also qualifies
as obvious, so you could have checked it in immediately.

> +/* Our caller bp_loc_is_permanent uses plain memcmp expecting byte ranges of
> +   the instructions.  We provide the extended range as described for
> +   ia64_memory_insert_breakpoint simulating a placed breakpoint there - memcmp
> +   will return true iff there was already a breakpoint (and so we returned the
> +   original memory).  We just take care of preserving the `break' instruction
> +   21-bit (or 62-bit) parameter as the memcmp match would fail otherwise.  */

I don't think it's a good idea to refer to the caller in the description
of a routine. We might add more in the future...  What you could say is
that this function implements the semantics of the breakpoint_from_pc
gdbarch method, and then proceed to explain the way you did why this
function is tricky to implement on ia64.

> +  /* 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?) and
the conclusion that you are reaching. I tend to have simplistic
views of the real situation, so this may be a little too simple
to be acurate, but I would have just said that we need to be able
to read the original memory location to produce the breakpoint
sequence.

> +  /* We need to keep the possible `break' instruction parameter value intact.
> +     Opcode with cleared all the bits (except the parameter value) is `break'.

It took me a long while to understand this, and it's probably because
it's getting for me. But could it also be due to pure English. IIUC,
I propose instead (in my own broken English ;-):

  A break instruction has its all its opcode bits cleared except for
  the parameter value.

> +     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:

> +  instr_fetched = slotN_contents (bundle, slotnum);
> +  instr_fetched &= 0x1003ffffc0;
> +  replace_slotN_contents (bundle, instr_fetched, slotnum);

> +# This is a testcase specifically for the `start' GDB command.  For regular
> +# stop-in-main goal in the testcases please use `runto_main' instead.
                                       ^^^^^^^^^^^^
Can you just change the wording to "consider using"? It's softer.
There might be some cases in the future where gdb_start_cmd might
be more useful than using runto_main.

Overall, the patch looks good is and is pre-approved once the
observations above are addressed.

Thanks,
-- 
Joel