From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17444 invoked by alias); 9 Sep 2002 16:01:53 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 17437 invoked from network); 9 Sep 2002 16:01:52 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 9 Sep 2002 16:01:52 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C80A43F26; Mon, 9 Sep 2002 12:01:52 -0400 (EDT) Message-ID: <3D7CC5F0.7040100@ges.redhat.com> Date: Mon, 09 Sep 2002 09:01:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marko Mlinar Cc: gdb@sources.redhat.com Subject: Re: Merging OC gdb with official gdb References: <200209041256.47379.markom@opencores.org> <3D77B310.50009@ges.redhat.com> <200209090807.04987.markom@opencores.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00053.txt.bz2 > Andrew, > > >> The current documentation is being updated (slowly). Also see the thread: >> >> http://sources.redhat.com/ml/gdb/2002-07/msg00202.html >> >> but unless your architecture is really wierd, nothing should be needed. > > no, it is very similar to PPC, it is very clean RISC implementation. Good! >> - getting it to strictly use the multi-arch framework (the exception >> being if your platform has shared libraries) > > > I don't quite understand what you mean with "if your platform has shared > libraries", can you rephrase please. Ever since 5.0, GDB has only been accepting new multi-arch targets. Ever since 5.1, GDB has only beeing accepting extensions to an existing architecture when the base architecture has been multi-arched. If a target system doesn't have shared libraries then it will be pure multi-arch (no config/CPU/tm-CPU.h file). See xstormy16. If the target system does have shared libraries then it will be almost pure multi-arch (a very small config/CPU/tm-CPU.h). See cris. > I saw multi-arch framework would require a lot of work for our target, it > would be nice if we could make it without it. Getting something converted to multi-arch is mechanical. See: http://sources.redhat.com/gdb/current/onlinedocs/gdbint_9.html#SEC78 for the recommended process. > We have following deprecated macros: > #define EXTRACT_RETURN_VALUE(TYPE, REGBUF, VALBUF) > #define STORE_RETURN_VALUE(TYPE,VALBUF) > #define EXTRACT_STRUCT_VALUE_ADDRESS(REGBUF) > Is it possible to solve them without multi-arch? Not really. GDB is a moving target. The above macro's, for instance, have been replaced with better equivalents. An ongoing task is to eliminate all existing references. I don't think it is reasonable to prolong this task by adding still more references. Remember, once you've brought this architecture up to current standards and it has been accepted into GDB, the GDB developers take on a significant part of its ongoing maintenance. All GDB developers are, for instance, expected to ensure that this new target architecture builds. >> - getting it to comply to gnu (and GDB) coding standards > > of course. You should also look through the ``Fixed'' entries listed at the bottom of: http://sources.redhat.com/gdb/current/ari/ >> - FSF paperwork > > already have it. Good! >> Otherwize it should drop in. Take a look at one of the very recent >> targets (xstormy16?). > > ok. > > thanks for your help, > Marko Andrew