Obsolete GDB's m32r support

Obsolete GDB's m32r support

[Andrew Cagney]

[Reply-to: set to gdb at sources redhat com]

Hello,

The m32r target, currently included in GDB, has been identified as a 
candidate for obsolesence.  This target does not use GDB's multi-arch 
framework and all such targets are either being obsoleted or multi-arched.

If you have any reservations over GDB's move to obsolete the m32r please 
contact the gdb@ discussion list (reply-to set).

Andrew Cagney
GDB Adminstrator
http://www.gnu.org/software/gdb/

Re: Obsolete GDB's m32r support

[Frank Ch. Eigler]

cagney wrote:

> [...] This target does not use GDB's multi-arch framework and all
> such targets are either being obsoleted or multi-arched.  [...]

Can you summarize the technical reasons for this dichotomy of
outcomes?  In what way does the presence of old targets pose a
technical challenge to more modern multiarch'd ones?  In other words,
what technical reasons exist to not allow old targets to stick around
as they are?


- FChE

Re: Obsolete GDB's m32r support

[Andrew Cagney]

> cagney wrote:
> 
> 
>> [...] This target does not use GDB's multi-arch framework and all
>> such targets are either being obsoleted or multi-arched.  [...]
> 
> 
> Can you summarize the technical reasons for this dichotomy of
> outcomes?  In what way does the presence of old targets pose a
> technical challenge to more modern multiarch'd ones?  In other words,
> what technical reasons exist to not allow old targets to stick around
> as they are?

The rationale for this move has been discussed on a number of occasions 
in the past, can I recommend a quick search through the e-mail archives 
and a review of that previous debate.

Andrew

Re: Obsolete GDB's m32r support

[Frank Ch. Eigler]

Hi -

> > Can you summarize the technical reasons for this dichotomy of
> > outcomes?  In what way does the presence of old targets pose a
> > technical challenge to more modern multiarch'd ones?  In other words,
> > what technical reasons exist to not allow old targets to stick around
> > as they are?
>
> The rationale for this move has been discussed on a number of occasions 
> in the past, can I recommend a quick search through the e-mail archives 
> and a review of that previous debate.

A quick search resulted only in (valid) descriptions of multi-arch
superiority, and dicta that old targets shall convert or die.  It
didn't answer my question above.  Perhaps you could spare time for
a more specific pointer?


- FChE

Re: Obsolete GDB's m32r support

[Andrew Cagney]

> Hi -
> 
> 
>> > Can you summarize the technical reasons for this dichotomy of
>> > outcomes?  In what way does the presence of old targets pose a
>> > technical challenge to more modern multiarch'd ones?  In other words,
>> > what technical reasons exist to not allow old targets to stick around
>> > as they are?
> 
>>
>> The rationale for this move has been discussed on a number of occasions 
>> in the past, can I recommend a quick search through the e-mail archives 
>> and a review of that previous debate.
> 
> 
> A quick search resulted only in (valid) descriptions of multi-arch
> superiority, and dicta that old targets shall convert or die.  It
> didn't answer my question above.  Perhaps you could spare time for
> a more specific pointer?

Interesting.  I didn't say the search would be easy.

Of the top of my head:

Each GDB target incures overhead.  Old, non-multi-arch targets, incure 
greater overhead then newer multi-arch ones (hint, how long is a 
multi-arch rebuild).  By either obsoleting or multi-arching a target, 
the overall maintenance overhead of GDB is reduced.

Non multi-arch targets rely on deprecated mechanisms and those mechanims 
are being be deleted from GDB.  Rather than putting targets relying on 
such mechanisms on life support (applying untested bandaid patches) GDB 
is eliminating those targets.  There is no benefit in retaining a broken 
target (the old code is always available in CVS).

The option of blindly multi-arching non- multi-arch targets was 
considered (i.e. convert the code but not test the result).  It was 
concluded that, there was little benefit.  You would end up with a 
broken multi-arch target that no one is interested in maintaining.

The targets being obsoleted show no evidence of life (your use of the 
word old was unfortunate).  The vax has been multi-arched, the z8k is 
going to be multi-arched, the !*&^$#*&@!$ PA RISC will need to be 
multi-arched, I suspect that even the 88k will get multi-arched!

enjoy,
Andrew