Re: [RFC/RFA] gdb extension for Harvard architectures

[Jim Blandy <jimb@zwingli.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.