Post GDB 6.2, require new frame code

Post GDB 6.2, require new frame code

[Andrew Cagney]

GDB's new frame infrastructure was introduced more than a year ago
(dwarf2-frame added May '03) and then included in the 6.0 and 6.1
releases.  Since that introduction, we've seen:

	alpha ARM AVR CRIS d10v FRV
	PA-RISC i386 ia64 m32r m68hcll
	m68k m88k mips ppc s390 sh4
	sparc vax

all updated to this new framework.  Unfortunately, though, we're still
left with a few architectures relying on the old framework.

We're now faced with the problem of what to do with the remaining
architectures.  The choices I see are:

- continue to support the legacy framework

- convert the remaining architectures

- phase out the remaining architectures

So as to avoid the problem of this dragging on indefinitely, we need to
establish a clear schedule by which all architectures are expected to
have been updated.  To that end:

- make GDB 6.2 the last release to support the legacy frame code

- in 6.2 NEWS, list unconverted architectures as about to be obsoleted

- Post 6.2 release, obsolete any remaining architectures

comments,
Andrew

Re: Post GDB 6.2, require new frame code

[Jim Blandy]

Andrew Cagney <cagney@gnu.org> writes:
> GDB's new frame infrastructure was introduced more than a year ago
> (dwarf2-frame added May '03) and then included in the 6.0 and 6.1
> releases.  Since that introduction, we've seen:
> 
> 	alpha ARM AVR CRIS d10v FRV
> 	PA-RISC i386 ia64 m32r m68hcll
> 	m68k m88k mips ppc s390 sh4
> 	sparc vax
> 
> all updated to this new framework.  Unfortunately, though, we're still
> left with a few architectures relying on the old framework.

For concreteness, it looks like those would be:

   h8300 mcore mn10300 ns32k sh64 v850 xstormy16

Supporting the old frame interfaces is a burden, and one that there's
no good reason to carry forever.  But listing things as obsolete in
NEWS isn't a very high-profile step; I think many, many users don't
read NEWS.  For example, remember that old discussion about obsoleting
annotate level 2?

If the intent is to provide some warning, I think it work better to
add something a user would actually see.  For example, if GDB is
configured for an obsolete architecture, it could print a one-line
message at startup, after the copyright notice, saying "Support for
the Intel 4004 will be removed after GDB 6.2; see NEWS."  The NEWS
entry would clarify, saying that it was obsolete only due to a lack of
sustaining maintenance, and that if anyone contributed modernized
code, we'd be happy to continue support for that architecture.

What I'm suggesting is that the intermediate phase between "fully
supported" and "removed" be marked with a visible behavior change in
GDB that users will be likely to notice, without reading NEWS or any
other documentation.

Re: Post GDB 6.2, require new frame code

[Andrew Cagney]

So you see no problems with the schedule?  That, given the rapidly 
aproaching 6.2 branch, is the key question here.

As for an informational message during startup, that's in line with an 
earlier proposal I put forward: alert the user of any reliance on 
deprecated mechanisms during startup.  It was rejected as it was felt 
that it would unnecessarially scare (for want of a better word) the 
users.  Here though, the message is for a very specific problem and 
clear outcome so will probably be considered ok.

Andrew

Re: Post GDB 6.2, require new frame code

[Michael Mueller]

The new frame infrastructure is dwarf2 based if I understand that 
correctly. Does that mean that all stabs support will go away after 6.2?

(I'm using gdb to debug Sun C compiled programs on Solaris/SPARC. The 
current version Sun C 5.5 can output dwarf2 but the default still is 
stabs and it seems they just have started the transition to dwarf2).

Michael


Andrew Cagney wrote:
> GDB's new frame infrastructure was introduced more than a year ago
> (dwarf2-frame added May '03) and then included in the 6.0 and 6.1
> releases.  Since that introduction, we've seen:
> 
>     alpha ARM AVR CRIS d10v FRV
>     PA-RISC i386 ia64 m32r m68hcll
>     m68k m88k mips ppc s390 sh4
>     sparc vax
> 
> all updated to this new framework.  Unfortunately, though, we're still
> left with a few architectures relying on the old framework.
> 
> We're now faced with the problem of what to do with the remaining
> architectures.  The choices I see are:
> 
> - continue to support the legacy framework
> 
> - convert the remaining architectures
> 
> - phase out the remaining architectures
> 
> So as to avoid the problem of this dragging on indefinitely, we need to
> establish a clear schedule by which all architectures are expected to
> have been updated.  To that end:
> 
> - make GDB 6.2 the last release to support the legacy frame code
> 
> - in 6.2 NEWS, list unconverted architectures as about to be obsoleted
> 
> - Post 6.2 release, obsolete any remaining architectures
> 
> comments,
> Andrew
> 
> 
> 

Re: Post GDB 6.2, require new frame code

[Jim Blandy]

Michael Mueller <m.mueller99@kay-mueller.de> writes:
> The new frame infrastructure is dwarf2 based if I understand that
> correctly. Does that mean that all stabs support will go away after
> 6.2?

No --- "GDB's new frame infrastructure" is not the same as "Dwarf 2
Call Frame Information".  The latter is just one frame unwinding
mechanism that can be plugged into the former.  "Whatever GDB always
used to do to unwind frames before Dwarf 2 CFI came along" is another
thing you can plug into the new frame infrastructure.

So, STABS support will not go away.  (STABS doesn't actually provide
unwinding information, the way Dwarf 2 does.)  But using the new frame
infrastructure means that it's trivial to make your target support
Dwarf 2 CFI when it happens to be available.

What Andrew wants to get rid of is targets that are still using
set_gdbarch_deprecated_mumble in their *_gdbarch_init and *_init_abi
functions.  STABS-based targets can be readily upgraded to leave
behind the deprecated interfaces.

Re: Post GDB 6.2, require new frame code

[Corinna Vinschen]

On Jun 18 15:28, Andrew Cagney wrote:
> So as to avoid the problem of this dragging on indefinitely, we need to
> establish a clear schedule by which all architectures are expected to
> have been updated.  To that end:
> 
> - make GDB 6.2 the last release to support the legacy frame code
> 
> - in 6.2 NEWS, list unconverted architectures as about to be obsoleted
> 
> - Post 6.2 release, obsolete any remaining architectures

Sounds like a good plan.  I just think that there should also be a clear
hint how much time is left, something along the lines of "6 months from
now" or so.


Corinna

-- 
Corinna Vinschen
Cygwin Co-Project Leader
Red Hat, Inc.