From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9334 invoked by alias); 13 Nov 2008 05:31:43 -0000 Received: (qmail 9166 invoked by uid 22791); 13 Nov 2008 05:31:42 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Nov 2008 05:31:05 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id A778F2A965D; Thu, 13 Nov 2008 00:31:03 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sW-xnX9FIGf0; Thu, 13 Nov 2008 00:31:03 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 41FA92A965C; Thu, 13 Nov 2008 00:31:03 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id CF3D5E7ACD; Wed, 12 Nov 2008 21:31:00 -0800 (PST) Date: Thu, 13 Nov 2008 14:27:00 -0000 From: Joel Brobecker To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [patch] ia64: Fix breakpoints memory shadow Message-ID: <20081113053100.GL5112@adacore.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081111131726.GA3272@host0.dyn.jankratochvil.net> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00264.txt.bz2 > 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 > > 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