Re: gcc/sdbout.c and char parameters

[Jim Wilson <wilson@cygnus.com>]

	Now, back to the problem : is the user interested in that intermediate
	`int' form of his parameter or rather in the `char' form when using
	gdb and friends ?

The user would prefer the `char', however, in some cases, gdb will not work
correctly unless it knows the intermediate type is `int'.  This is because
gdb works on the executable, and needs to know the type used in the
executable, whereas the user works on the source, and wants to know the
type used in the source.

Consider a target where chars are promoted to int when calling a function,
and the callee assumes that it will always be passed a promoted int on the
stack (i.e. PROMOTE_FUNCTION_ARG is defined, or the callee was not generated
by gcc).  If we say that the value is a `char', and then you use a gdb command
to modify the value
	(gdb) print c = 10
then gdb will only write a single character to the stack.  The function may
then read an entire word from the stack (because it knows it is a promoted
int) and get the wrong value.  Hence this gdb feature won't work as intended
anymore.  (Unless perhaps gdb is smart enough to know that parameters need
sign/zero extension for some targets.)

Similarly, if you have a stray pointer in your code, and the code accidentally
clobbers the upper 3 bytes of this parameter, then the program may run
incorrectly because it sees the 3 bytes of junk, but attempts to debug
the problem will be unhelpful because a simple command like this
	(gdb) print c
will only print a single byte, making the 3 bytes of junk invisible to the
user.

Similarly, there may also be problems if you try to call a function at run
time, e.g.
	(gdb) print foo (10)
depending on how gdb implements this.  If gdb thinks that it only need write
a single char to the stack, then the callee may read 3 bytes of junk and fail.
I am not sure how this part of gdb works though.  If it automatically pads
to a word boundary by appropriate sign/zero extension, then this will probably
continue to work.  It gdb just pads, without using appropriate sign/zero
extension, then we still have a problem.

There are probably related problems with local variables with ports that use
PROMOTE_MODES.  This has the same affect of making the binary representation
(that gdb cares about) different from the source representation (that the
user cares about).

There is also the question of what other debuggers will do when they see
the debug info that gcc emits.  We might need to make the change depend on
-gcoff+ if it confuses sdb.

Jim