From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Andrew Cagney Cc: Jim Blandy , Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [RFC/RFA] gdb extension for Harvard architectures Date: Wed, 03 Oct 2001 16:13:00 -0000 Message-id: References: <3BB4D843.A92818B9@cygnus.com> <3BB512A9.6050801@cygnus.com> <3BB5195F.6050603@cygnus.com> <3BBA2DC9.5060500@cygnus.com> <3BBB6C50.50207@cygnus.com> X-SW-Source: 2001-10/msg00071.html Andrew Cagney 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.