This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC/RFA] gdb extension for Harvard architectures
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: [RFC/RFA] gdb extension for Harvard architectures
- From: Jim Blandy <jimb at zwingli dot cygnus dot com>
- Date: 03 Oct 2001 16:34:29 -0500
- Cc: Michael Snyder <msnyder at cygnus dot com>,gdb-patches at sources dot redhat dot com
- References: <3BB4D843.A92818B9@cygnus.com> <3BB512A9.6050801@cygnus.com><3BB5195F.6050603@cygnus.com> <3BBB50C0.BD01BF20@cygnus.com><3BBB5391.4010001@cygnus.com>
Andrew Cagney <ac131313@cygnus.com> writes:
> Without change. My contention is that the user is almost never going to
> want to do what you just described. Why make what the user is going to
> want to do hard?
Michael's change makes what the user wants possible at all, which is
an improvement over the current situation. You are asking for an
additional improvement, which can be discussed separately from
Michael's change.
But to answer the question anyway:
Sometimes it is better to leave what the user usually wants to do
somewhat hard, because making that specific case easy makes a lot of
other stuff even weirder.
You're essentially proposing:
- that a cast expression like (T) EXPR would not result in a value of
type T, but some other type chosen to save the user's keystrokes, and
- that we make GDB evaluate expressions like `(int *) &main' differently
from the way the compiler does.
Those set off warning bells, for me. You can special-case this stuff
to make the naive user's behavior do the right thing want all you
want. If you've ever had Microsoft Word correct your capitalization
or automatically munge your paragraph formatting, you know what the
resulting systems feel like to use.
In contrast, once you do explain to someone how to do what they want
under Michael's and my proposal, it makes sense, given the
architecture. You can then correctly predict how a half-dozen other
weird things would be done. All the rules you already know about
types apply naturally to the extension.
As I see it, these architectures have a discontinuity that we're
simply not accustomed to, though people in older times wouldn't have
been so surprised. And we've provided a way to accurately describe
that sort of discontinuity; using our system, things "just work" that
can't be made to work without our system.