From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22302 invoked by alias); 14 Oct 2003 00:44:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22295 invoked from network); 14 Oct 2003 00:44:56 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 14 Oct 2003 00:44:56 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h9E0iuM11762 for ; Mon, 13 Oct 2003 20:44:56 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h9E0itr20997; Mon, 13 Oct 2003 20:44:55 -0400 Received: from localhost.localdomain (vpn50-39.rdu.redhat.com [172.16.50.39]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h9E0isDb024704; Mon, 13 Oct 2003 20:44:54 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h9E0ing24764; Mon, 13 Oct 2003 17:44:49 -0700 Date: Tue, 14 Oct 2003 00:44:00 -0000 From: Kevin Buettner Message-Id: <1031014004448.ZM24763@localhost.localdomain> In-Reply-To: Michael Snyder "Re: [PATCH] TARGET_ADJUST_BREAKPOINT_ADDRESS - patch 4 of 4" (Oct 7, 4:00pm) References: <1031004065453.ZM25497@localhost.localdomain> <3F83458B.7020709@redhat.com> To: Michael Snyder Subject: Re: [PATCH] TARGET_ADJUST_BREAKPOINT_ADDRESS - patch 4 of 4 Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00436.txt.bz2 On Oct 7, 4:00pm, Michael Snyder wrote: > My first feedback is that "count" should be set to a const > rather than to 8 -- since we've seen it change from 4 to 8 > just recently, and who knows when it will change again. > That'll also provide an opportunity to explain (via the > name of the const, if nothing else) what 'count' is. Thanks for the feedback. I've added ``max_instrs_per_bundle'' along with a comment about what this is. > Maybe "bpaddr - 4" could also be "bpaddr - sizeof (something)". I hear alarm bells go off in my head whenever I see sizeof() used in target specific code. (Sometimes it's perfectly okay, but I hear them just the same.) So, what I've done instead is to define ``frv_instr_size'' and use that constant instead of 4 in frv_gdbarch_adjust_breakpoint_address(). The same constant could also be used in the prologue scanning code. (I'll prepare a separate patch...) Here's what I've committed: * frv-tdep.c (max_instrs_per_bundle, frv_instr_size): New constants. (frv_gdbarch_adjust_breakpoint_address): New function. (frv_gdbarch_init): Initialize ``gdbarch_adjust_breakpoint_address'' method. Index: frv-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/frv-tdep.c,v retrieving revision 1.53 diff -u -p -r1.53 frv-tdep.c --- frv-tdep.c 19 Sep 2003 16:22:38 -0000 1.53 +++ frv-tdep.c 14 Oct 2003 00:26:39 -0000 @@ -37,6 +37,7 @@ static gdbarch_init_ftype frv_gdbarch_in static gdbarch_register_name_ftype frv_register_name; static gdbarch_breakpoint_from_pc_ftype frv_breakpoint_from_pc; +static gdbarch_adjust_breakpoint_address_ftype frv_gdbarch_adjust_breakpoint_address; static gdbarch_skip_prologue_ftype frv_skip_prologue; static gdbarch_deprecated_extract_return_value_ftype frv_extract_return_value; static gdbarch_deprecated_extract_struct_value_address_ftype frv_extract_struct_value_address; @@ -271,6 +272,51 @@ frv_breakpoint_from_pc (CORE_ADDR *pcptr return breakpoint; } +/* Define the maximum number of instructions which may be packed into a + bundle (VLIW instruction). */ +static const int max_instrs_per_bundle = 8; + +/* Define the size (in bytes) of an FR-V instruction. */ +static const int frv_instr_size = 4; + +/* Adjust a breakpoint's address to account for the FR-V architecture's + constraint that a break instruction must not appear as any but the + first instruction in the bundle. */ +static CORE_ADDR +frv_gdbarch_adjust_breakpoint_address (struct gdbarch *gdbarch, CORE_ADDR bpaddr) +{ + int count = max_instrs_per_bundle; + CORE_ADDR addr = bpaddr - frv_instr_size; + CORE_ADDR func_start = get_pc_function_start (bpaddr); + + /* Find the end of the previous packing sequence. This will be indicated + by either attempting to access some inaccessible memory or by finding + an instruction word whose packing bit is set to one. */ + while (count-- > 0 && addr >= func_start) + { + char instr[frv_instr_size]; + int status; + + status = read_memory_nobpt (addr, instr, sizeof instr); + + if (status != 0) + break; + + /* This is a big endian architecture, so byte zero will have most + significant byte. The most significant bit of this byte is the + packing bit. */ + if (instr[0] & 0x80) + break; + + addr -= frv_instr_size; + } + + if (count > 0) + bpaddr = addr + frv_instr_size; + + return bpaddr; +} + /* Return true if REG is a caller-saves ("scratch") register, false otherwise. */ @@ -1114,6 +1160,7 @@ frv_gdbarch_init (struct gdbarch_info in set_gdbarch_skip_prologue (gdbarch, frv_skip_prologue); set_gdbarch_breakpoint_from_pc (gdbarch, frv_breakpoint_from_pc); + set_gdbarch_adjust_breakpoint_address (gdbarch, frv_gdbarch_adjust_breakpoint_address); set_gdbarch_frame_args_skip (gdbarch, 0); set_gdbarch_frameless_function_invocation (gdbarch, frv_frameless_function_invocation);