From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18137 invoked by alias); 10 Jan 2002 23:51:41 -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 18110 invoked from network); 10 Jan 2002 23:51:40 -0000 Received: from unknown (HELO localhost.cygnus.com) (24.114.42.213) by sources.redhat.com with SMTP; 10 Jan 2002 23:51:40 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 772AD3CEF; Thu, 10 Jan 2002 18:51:39 -0500 (EST) Message-ID: <3C3E290B.7020902@cygnus.com> Date: Thu, 10 Jan 2002 15:51:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.7) Gecko/20020103 X-Accept-Language: en-us MIME-Version: 1.0 To: LeakyStain Cc: gdb@sources.redhat.com Subject: gdbint.info; Was: Obsolete m32r? References: <3C388CE9.3080102@cygnus.com> <3C392FE0.5395@redhat.com> <3C3C7CC8.4070409@cygnus.com> <3C3E1592.633CD862@erols.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg00111.txt.bz2 > It would help if the gdbint.info was updated first, to label the macros > obsolete or deprecated, and describe multi-arch more completely. Obsolete macros are deleted (when someone notices they are not in use or removes all uses). There is no pre-documented warning that this will happen however strong hints are found on http://sources.redhat.com/gdb/ari/ . The intention (discussed last year) is to more clearly identify deprecated macro's and functions by adding the prefix deprecated_....(). > I started working on a port of gdb 5.0 to the ut69r in September 2001, > and I read gdbint.info pretty thoroughly; there was only one mention of > multi-arch, and it was pretty obscure. So I implemented the macros, and > now I discover I have to change them. Prior to the 5.1 release I tried to update the internals doco so that it better represented current reality (1, 2): http://sources.redhat.com/gdb/onlinedocs/gdbint_9.html#SEC67 The introduction is correct. The misleading part is where it uses the words macro vs function. Looking at it I probably should have simply replaced all uses of the word macro with function (it is complicated because currently most architecture methods are still accessed via a macro by core-GDB :-/). The section on files points out that tm-*.h files are not needed and should not be created. Overall it could do with more work. With 5.1 I was more worried about getting the coding standard section to better reflect reality. If you're wondering about the big picture see: http://sources.redhat.com/gdb/papers/multi-arch/whatis.html http://sources.redhat.com/gdb/papers/multi-arch/real-multi-arch/ If you're wondering what you need to change see: http://sources.redhat.com/gdb/papers/multi-arch/howto.html Andrew (1) GDB currently isn't multi-arch. At this stage multi-arch just refers to implementing a target using the architecture vector. (1) Hmm, section 9.1 is completly out-of-date. GDB and the compiler's register numberings are now completly independant!