From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16160 invoked by alias); 15 Jul 2004 18:18:59 -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 16145 invoked from network); 15 Jul 2004 18:18:56 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 15 Jul 2004 18:18:56 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i6FIIue3008371 for ; Thu, 15 Jul 2004 14:18:56 -0400 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i6FIIr002299; Thu, 15 Jul 2004 14:18:55 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id A5C1E2B9D; Thu, 15 Jul 2004 14:18:55 -0400 (EDT) Message-ID: <40F6CA8F.5000504@gnu.org> Date: Thu, 15 Jul 2004 18:18:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Sherry Samuel Cc: gdb-patches@sources.redhat.com Subject: Re: [Patch H8/300] : Fix for crashing of gdb with" info f" command References: <4A1BE23A7B777442B60F4B4916AE0F130218AAA5@sohm.kpit.com> In-Reply-To: <4A1BE23A7B777442B60F4B4916AE0F130218AAA5@sohm.kpit.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00185.txt.bz2 > Hi > Reference:http://sources.redhat.com/ml/gdb-patches/2004-06/msg00428.html > > In the latest GDB(gdb+dejagnu-20040630) snap shot, the "info f" problem described in the above link is fixed. Referring through the links you have suggested, it is evident that h8300 target is not in the list of the new GDB frame structure. Is it possible to know what should be done from our side to update H8300 targets to the new frame work? Can you suggest how to go about it? > > Thanks in advance. Right, A very simplistic cookbook is as follows: - #if 0 all the set_gdbarch_deprecated ... lines - build gdb - try gdb on a simple program break main, info registers, stepi, nexti, ... - fix an internal error due to missing method - repeat eventually you'll get gdb kind of working, at that point repeat the above using the testsuite. It turns out that for architectures like this that use all the old deprecated methods, its quicker / easier to clear the deck and implement a new (borrowing heavily from the old code of course). It also turns out that basic operations (break main; run, stepi, info registers) don't even need a frame unwinder - so that can be left as a separate pass. For the unwinder, you need to convert the frame_saved_regs code into the frame_unwind_cache code (seen in more up-to-date architectures). As for contributing this, perhaphs we can just incrementally submit the above in realtime? Andrew