This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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



Andrew Cagney <ac131313@cygnus.com> writes:
> > - doesn't change the meaning of any valid C expressions
> 
> Is this a valid C expression?
> 
> 	int foo();
> 	char *c = foo;
> 
> I.e. does ISO C define its semantics?

No, it's not a valid C expression.  It's a declaration, followed by a
definition with an initializer.  :)

The expression:

        (int *) &func

is a valid C expression.  Its meaning is unspecified by ISO C, but
every compiler does assign some meaning to it.  The same applies to
your example.

If I understand you correctly, you would like GDB to evaluate that
expression in a way which yields a pointer to an int in code space.
You argue that, since this expression's meaning is not fixed by the
standard, GDB is free to interpret it in whatever way is most helpful
to the user.  Is that correct?

While the expression's meaning is not fixed by the standard, the
compiler does assign some meaning to it.  I feel it is important that
GDB should produce the same value for an expression that the compiler
would.  So I feel that GDB is not, in fact, free to make the
interpretation you suggest.

You've said that the compiler's interpretation is useless.  Probably
so.  But what if the user's bug is that they have cast a function
pointer to a data pointer, and tried to use it to fetch the
instructions?  If they try their expression in GDB, they should get
the same (unexpected!) answer that GCC gives them.  This consistency
is, in fact, critical to them finding their bug!

So, what I meant by the assertion quoted by you at the top of this
message is: our proposal does not require GDB to evaluate any
expressions differently than the compiler would.  It is strictly an
extension of the language accepted by the compiler.  Your suggested
change would assign expressions like `(int *) &func' a meaning
different from the one the compiler would.  This is, to my mind, a
serious point against it.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]