From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30809 invoked by alias); 10 Feb 2014 15:53:34 -0000 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 Received: (qmail 30790 invoked by uid 89); 10 Feb 2014 15:53:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Feb 2014 15:53:32 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1AFrTlJ016777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Feb 2014 10:53:31 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1AFU27C031782; Mon, 10 Feb 2014 10:30:03 -0500 Message-ID: <52F8F07A.5060600@redhat.com> Date: Mon, 10 Feb 2014 15:53:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yoshinori Sato CC: Mark Kettenis , gdb-patches@sourceware.org Subject: Re: [PATCH] h8300 "info registers" broken References: <8738k3j95o.wl%ysato@users.sourceforge.jp> <52F14184.9020803@redhat.com> <878utpfnxs.wl%ysato@users.sourceforge.jp> <201402051759.s15Hx0JB002993@glazunov.sibelius.xs4all.nl> <877g95fo46.wl%ysato@users.sourceforge.jp> In-Reply-To: <877g95fo46.wl%ysato@users.sourceforge.jp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-02/txt/msg00313.txt.bz2 On 02/08/2014 06:36 PM, Yoshinori Sato wrote: > #10 0x00000000005b954e in frame_unwind_register (frame=, > regnum=13, buf=) at ../../gdb/frame.c:1064 Hard to reason about an optimized build... Please try with "-g3 -O0". I don't have a h8300-elf toolchain handy, and the h8300-linux toolchain I found doesn't seem to want to link executables, but I managed to try something by building an .o file, and debugging that. I don't see a crash, but instead GDB complains CCR is unavailable. (gdb) info target Symbols from "/home/pedro/h8300-main.o". simulator: Attached to sim running program /home/pedro/h8300-main.o #instructions executed 0 #cycles (v approximate) 0 #real time taken 0.0000 #virtual time taken 0.0000 #compiles 0 #cache size 1024 While running this, GDB does not access memory from... Local exec file: `/home/pedro/h8300-main.o', file type elf32-h8300. Entry point: 0x0 0x00000000 - 0x00000024 is .text 0x00000024 - 0x00000024 is .data 0x00000024 - 0x00000024 is .bss (gdb) b *0 Breakpoint 1 at 0x0: file main.c, line 4. (gdb) r Starting program: /home/pedro/h8300-main.o Breakpoint 1, foo (i=0x0 ) at main.c:4 4 { (gdb) info registers r0 0x0000 0 r1 0x0000 0 r2 0x0000 0 r3 0x0000 0 r4 0x0000 0 r5 0x0000 0 r6 0x0000 0 sp 0x0000 0 Register 13 is not available (gdb) info registers ccr Register 13 is not available The problem seems to me that the h8300 port does not define a register_sim_regno gdbarch hook, and thus when fetching registers off of the sim, we end up in legacy_register_sim_regno trying to figure out the sim register number for the raw CCR register: int legacy_register_sim_regno (struct gdbarch *gdbarch, int regnum) { /* Only makes sense to supply raw registers. */ gdb_assert (regnum >= 0 && regnum < gdbarch_num_regs (gdbarch)); /* NOTE: cagney/2002-05-13: The old code did it this way and it is suspected that some GDB/SIM combinations may rely on this behavour. The default should be one2one_register_sim_regno (below). */ if (gdbarch_register_name (gdbarch, regnum) != NULL && gdbarch_register_name (gdbarch, regnum)[0] != '\0') return regnum; else return LEGACY_SIM_REGNO_IGNORE; } And because the raw ccr register does not have a name, that returns LEGACY_SIM_REGNO_IGNORE. Which means that we never actually read the ccr raw value. Before the support, this must have meant that ccr was _always_ read as 0... At least, I'm not seeing how this ever worked. Looking at sim/h8300/sim-main.h, it seems like the sim's register numbers are compatible with gdb's. This patch below "works" for me, as in, I can now print CCR, but that's about all I tested (and am willing to test) myself. Look me know how this looks to you. --- gdb/h8300-tdep.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/gdb/h8300-tdep.c b/gdb/h8300-tdep.c index ffffbc9..ac34a9b 100644 --- a/gdb/h8300-tdep.c +++ b/gdb/h8300-tdep.c @@ -939,6 +939,20 @@ h8300h_return_value (struct gdbarch *gdbarch, struct value *function, static struct cmd_list_element *setmachinelist; +static int +h8300_register_sim_regno (struct gdbarch *gdbarch, int regnum) +{ + /* Only makes sense to supply raw registers. */ + gdb_assert (regnum >= 0 && regnum < gdbarch_num_regs (gdbarch)); + + /* We hide the raw ccr from the user by making it nameless. Because + the default register_sim_regno hook returns + LEGACY_SIM_REGNO_IGNORE for unnamed registers, we need to + override it. The sim register numbering is compatible with + gdb's, so there isn't anything to do. */ + return regnum; +} + static const char * h8300_register_name (struct gdbarch *gdbarch, int regno) { @@ -1230,6 +1244,8 @@ h8300_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches) gdbarch = gdbarch_alloc (&info, 0); + set_gdbarch_register_sim_regno (gdbarch, h8300_register_sim_regno); + switch (info.bfd_arch_info->mach) { case bfd_mach_h8300: -- 1.7.11.7