Re: gcc/sdbout.c and char parameters

[Jim Wilson <wilson@cygnus.com>]

	I rather think that we should tell gdb (and sdb) that the parameter has type
	`char', to avoid displaying of actually not used bits when showing the numerical
	value, and to allow automatic displaying of the ASCII representation.

I agree that the current behaviour is not ideal.  However, my argument is
essentially that the sdb format is so limited that we can't emit ideal
debug info.

I believe that gcc already says that the parameter has type `char' if
you compile without optimization.  Is this what you are seeing?

I also believe that gcc will say the parameter has type `int' when optimizing,
but that there is no practical way to fix this in the sdbout format.  Is
this the only thing you are complaining about?

	E.g., look at the code generated for the following small testcase, 
	In both the `ansi' and the `kr' functions, to build a `short' from the `char'
	parameter, one does a sign-extension of the `char' parameter, not a
	truncation of the promoted `int' parameter.

If you look at the RTL dumps, you can see that the parameter is an int, that
gets truncated to a char, and then sign-extended to a short.  Gcc believes
that the value being passed in is an int, it just isn't taking advantage of
this fact to generate faster code.  Gcc is instead generating more portable
code.  I believe that you will get the faster code if a port defines
PROMOTE_FUNCTION_ARG, but this will result in subtle incompatible ABI changes
which is why it is not the default.  I believe that the changes you suggest
would cause gcc to emit incorrect debug info for ports that do define this
macro unless we explicitly checked for it.  There may also be other
complications.

Jim