Re: GDB 5.2 or GDB 5.1.1?

Re: GDB 5.2 or GDB 5.1.1?

[Michael Elizabeth Chastain]

Andrew Cagney writes:
> Just a postscript to this.   Because the FSF would like to be able to 
> spin out a manual based on a current release but are currently fixing 
> things I'll very likely end up spinning out a 5.1.1 or 5.1.0.2 (ulgh) 
> anyway.  The latter is far far easier.

Another constraint: 5.1.0.2 would be unable to debug -gdwarf-2 code
with gcc-HEAD, which is going to become gcc 3.1 eventually.

(I'm bummed because my overnight test run got stuck in the configuration
of gdb 5.1, gcc HEAD, -gdwarf-2, so I had to kludge around that and
start the test script again).

Michael C

Re: GDB 5.2 or GDB 5.1.1?

[Andrew Cagney]

> Andrew Cagney writes:
> 
>> Just a postscript to this.   Because the FSF would like to be able to 
>> spin out a manual based on a current release but are currently fixing 
>> things I'll very likely end up spinning out a 5.1.1 or 5.1.0.2 (ulgh) 
>> anyway.  The latter is far far easier.
> 
> 
> Another constraint: 5.1.0.2 would be unable to debug -gdwarf-2 code
> with gcc-HEAD, which is going to become gcc 3.1 eventually.
> 
> (I'm bummed because my overnight test run got stuck in the configuration
> of gdb 5.1, gcc HEAD, -gdwarf-2, so I had to kludge around that and
> start the test script again).


The sole purpose of 5.1.0.x (1) was to fix copyright problems in the 
documentation.  Turns out it it still contains problems (I didn't pull a 
change into the branch and that wasn't noticed).  5.1.0.2 would be the same.

Yes it doesn't help the normal user that is more worried about a working 
GDB.

enjoy,
Andrew

GDB 5.2 or GDB 5.1.1?

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

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

[-- Attachment #2: TODO --]
[-- Type: text/plain, Size: 2934 bytes --]

		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.

Re: GDB 5.2 or GDB 5.1.1?

[Daniel Jacobowitz]

On Wed, Jan 09, 2002 at 04:57:12PM -0500, Andrew Cagney wrote:
> 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.

Well, we got GCC 3.0 ABI support off the New features list.  ObjC/C++
would push us back a long ways, and I don't remember what the
complications with readline4.2 were.

I wouldn't be averse to a quick 5.2 release from the trunk, otherwise. 
There's a few things it would be nice to have done first - I have more
C++ fixes, and the profiling patch has not AFAICR been committed yet. 
But there should be time.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: GDB 5.2 or GDB 5.1.1?

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Wed, Jan 09, 2002 at 04:57:12PM -0500, Andrew Cagney wrote:
 > > 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.
 > 
 > Well, we got GCC 3.0 ABI support off the New features list.  ObjC/C++
 > would push us back a long ways, and I don't remember what the
 > complications with readline4.2 were.

None, I just didn't get a chance to do the import.

Elena


 > 
 > I wouldn't be averse to a quick 5.2 release from the trunk, otherwise. 
 > There's a few things it would be nice to have done first - I have more
 > C++ fixes, and the profiling patch has not AFAICR been committed yet. 
 > But there should be time.
 > 
 > -- 
 > Daniel Jacobowitz                           Carnegie Mellon University
 > MontaVista Software                         Debian GNU/Linux Developer

Re: GDB 5.2 or GDB 5.1.1?

[Andrew Cagney]

> On Wed, Jan 09, 2002 at 04:57:12PM -0500, Andrew Cagney wrote:
> 
>> 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.
> 
> 
> Well, we got GCC 3.0 ABI support off the New features list.  ObjC/C++
> would push us back a long ways, and I don't remember what the
> complications with readline4.2 were.


There is also multi-arching all the targets.  I should probably note 
that even if I didn't propose this I would have probably scrubbed the 
5.2 list clean.


> I wouldn't be averse to a quick 5.2 release from the trunk, otherwise. 
> There's a few things it would be nice to have done first - I have more
> C++ fixes, and the profiling patch has not AFAICR been committed yet. 
> But there should be time.


Ah, sooner than that :-) A best case senario puts the schedule at: 
announce branch 2002-01-16; branch 2002-01-23; release 2002-02-06.

People have often said that GDB should be released more often.  Looks 
like it might happen.

enjoy,
Andrew

Re: GDB 5.2 or GDB 5.1.1?

[Andrew Cagney]

> 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.


Just a postscript to this.   Because the FSF would like to be able to 
spin out a manual based on a current release but are currently fixing 
things I'll very likely end up spinning out a 5.1.1 or 5.1.0.2 (ulgh) 
anyway.  The latter is far far easier.

However I do still have a preference for cutting 5.2 rather than spend 
lots of effort getting fixes into the 5.1 branch.

I guess the question I'm asking here is, how much stuff has been added 
to the 5.1 branch that might break things making a fast 5.1.1 a high 
risk activity.

Andrew

Re: GDB 5.2 or GDB 5.1.1?

[Andrew Cagney]

> 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.
> 
> 
> Just a postscript to this.   Because the FSF would like to be able to spin out a manual based on a current release but are currently fixing things I'll very likely end up spinning out a 5.1.1 or 5.1.0.2 (ulgh) anyway.  The latter is far far easier.
> 
> However I do still have a preference for cutting 5.2 rather than spend lots of effort getting fixes into the 5.1 branch.
> 
> I guess the question I'm asking here is, how much stuff has been added to the 5.1 branch that might break things making a fast 5.1.1 a high risk activity.


For lack of opinion other than Daniel (thanks for the comments).  I'm 
going to:

Roll out 5.1.1 on ~24rd of Jan GMT (~23 in US).  I need to do something 
to address the (C) issues and I think this has the greatest benefit. 
Please don't rush to put things onto that branch.

Branch 5.2 ~23 Feb

Release 5.2 ~23 Mar

--

The numbers aren't totally made up.  5.1 was branched July and released 
November (4 months).  The above cuts the branch life down to one month 
so ...

Andrew

Re: GDB 5.2 or GDB 5.1.1?

[Andrew Cagney]

> For lack of opinion other than Daniel (thanks for the comments).  I'm going to:


Sorry.  An apology to Michael Chastain is in order.

Michael has gone through the 5.1 branch and confirmed it is far from 
regressing.  A 5.1.1 will definitly be more useable than 5.1.

http://www.shout.net/~mec/sunday/2002-01-14/index.html

Andrew