This is the mail archive of the
mailing list for the GDB project.
Re: [patch] ia64: Fix breakpoints memory shadow
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 12 Nov 2008 21:31:00 -0800
- Subject: Re: [patch] ia64: Fix breakpoints memory shadow
- References: <20081028172816.GA1284@host0.dyn.jankratochvil.net> <20081029210242.GA3635@adacore.com> <20081030144841.GA26606@host0.dyn.jankratochvil.net> <20081101185410.GB15606@adacore.com> <20081111131726.GA3272@host0.dyn.jankratochvil.net>
> 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 <email@example.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
> + /* 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.