From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2470 invoked by alias); 9 Jan 2002 21:57:25 -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 2399 invoked from network); 9 Jan 2002 21:57:12 -0000 Received: from unknown (HELO localhost.cygnus.com) (24.114.42.213) by sources.redhat.com with SMTP; 9 Jan 2002 21:57:12 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 20F163CC8 for ; Wed, 9 Jan 2002 16:57:12 -0500 (EST) Message-ID: <3C3CBCB8.90401@redhat.com> Date: Wed, 09 Jan 2002 13:57: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: gdb@sources.redhat.com Subject: GDB 5.2 or GDB 5.1.1? Content-Type: multipart/mixed; boundary="------------000708050405080906070209" X-SW-Source: 2002-01/txt/msg00069.txt.bz2 This is a multi-part message in MIME format. --------------000708050405080906070209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 499 Hello, I'm looking over all the things in my 5.1.1 folder and am beginning to think that it might be better if instead just move onto 5.2. I really don't know if it is worth all the effort (well mine and a few others) of pulling those changes onto a branch. All the C++ fixes, the HP/UX host stuff and so on. For this to work, all the proposed release criteria for 5.2 would need to be droped. thoughts? Either way, there needs to be a decision by the middle of next week. enjoy, Andrew --------------000708050405080906070209 Content-Type: text/plain; name="TODO" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="TODO" Content-length: 2934 GDB 5.2 - Fixes =============== -- GDB 5.2 - New features ====================== -- GCC 3.0 ABI support (but hopefully sooner...). -- Objective C/C++ support (but hopefully sooner...). -- Import of readline 4.2 -- GDB 5.2 - Cleanups ================== The following cleanups have been identified as part of GDB 5.2. -- Remove old code that does not use ui_out functions and all the related "ifdef"s. This also allows the elimination of -DUI_OUT from Makefile.in and configure.in. -- Compiler warnings. Eliminate warnings for all targets on at least one host for one of the -W flags. Flags up for debate include: -Wswitch -Wcomment -trigraphs -Wtrigraphs -Wunused-function -Wunused-label -Wunused-variable -Wunused-value -Wchar-subscripts -Wtraditional -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Woverloaded-virtual -Winline -- Deprecate, if not delete, the following: register[] register_valid[] REGISTER_BYTE() Replaced by, on the target side supply_register() and on core-gdb side: {read,write}_register_gen() Remote.c will need to use something other than REGISTER_BYTE() and REGISTER_RAW_SIZE() when unpacking [gG] packets. STORE_PSEUDO_REGISTER FETCH_PSEUDO_REGISTER Now handed by the methods gdbarch_{read,write}_register() which sits between core GDB and the register cache. REGISTER_CONVERTIBLE REGISTER_CONVERT_TO_RAW REGISTER_CONVERT_TO_VIRTUAL I think these three are redundant. gdbarch_register_{read,write} can do any conversion it likes. REGISTER_VIRTUAL_SIZE MAX_REGISTER_VIRTUAL_SIZE REGISTER_VIRTUAL_TYPE I think these can be replaced by the pair: FRAME_REGISTER_TYPE(frame, regnum) REGISTER_TYPE(regnum) DO_REGISTERS_INFO Replace with FRAME_REGISTER_INFO (frame, ...) REGISTER_SIM_REGNO() If nothing else rename this so that how it relates to rawreg and the regnum is clear. REGISTER_BYTES The size of the cache can be computed on the fly. IS_TRAPPED_INTERNALVAR The pseudo registers should eventually make this redundant. -- Obsolete the targets: arm*-wince-pe mips*-*-pe sh*-*-pe -- Obsolete the protocols: RDB? ``As of version 5.3, WindRiver has removed the RDB server (RDB protocol support is built into gdb).'' -- Till. -- Restructure gdb directory tree so that it avoids any 8.3 and 14 filename problems. -- Convert GDB build process to AUTOMAKE. See also sub-directory configure below. The current convention is (kind of) to use $(
_h) in all dependency lists. It isn't done in a consistent way. --------------000708050405080906070209--