From: Andrew Cagney <ac131313@cygnus.com>
To: "Frank Ch. Eigler" <fche@tooth.toronto.redhat.com>
Cc: cagney@redhat.com, gdb@sources.redhat.com
Subject: Re: Obsolete GDB's m32r support
Date: Tue, 18 Jun 2002 08:42:00 -0000 [thread overview]
Message-ID: <3D0F4E9E.6030407@cygnus.com> (raw)
In-Reply-To: <200206181406.g5IE6kb05361@tooth.toronto.redhat.com>
> 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
prev parent reply other threads:[~2002-06-18 15:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-17 17:25 Andrew Cagney
2002-06-18 6:11 ` Frank Ch. Eigler
2002-06-18 6:52 ` Andrew Cagney
2002-06-18 7:06 ` Frank Ch. Eigler
2002-06-18 8:42 ` Andrew Cagney [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D0F4E9E.6030407@cygnus.com \
--to=ac131313@cygnus.com \
--cc=cagney@redhat.com \
--cc=fche@tooth.toronto.redhat.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox