This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

GDB 5.2 or GDB 5.1.1?


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
		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 $(<header>_h) in all
dependency lists.  It isn't done in a consistent way.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]