This is the mail archive of the gdb-testers@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.


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

Re: gcc/sdbout.c and char parameters


Thanks for your quick answer.

> 
> 	For the following testcase, gcc does not produce the right debugging info
> 	on m68k-motorola-sysv (a COFF system using sdbout.c).  Basically, it says
> 	the 'c' parameter is 'int' while it should say it is 'char', and change
> 	the address accordingly.
> 
> Gcc says the parameter is an `int' because, as far as gcc and gdb are
> concerned, it really is an `int'.

That is not exactly what I see.  What I see is that a `char' parameter
takes as much memory as an int on the stack, and that if the called function 
was declared as requiring an `int', but was called with a `char' it must work
as if the function was called with the `char' parameter promoted to `int'
by the caller.  But if the called function expects a `char' parameter,
then the called function will discard all but the `char' part of the
parameter it is called with.

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.

short s;

ansi(char c)
        {
        s = c;
        }

kr(c)
char c;
        {
        s = c;
        }

ansi:
        link.w %fp,&0
        mov.b 11(%fp),%d0
        ext.w %d0
        mov.w %d0,s
        unlk %fp
        rts
kr:
        link.w %fp,&0
        mov.b 11(%fp),%d0
        ext.w %d0
        mov.w %d0,s
        unlk %fp
        rts
        comm s,2
> 
> This particular problem is that function parameters really have two types
> associated with them, the user specified type, and the type that the compiler
> promotes it to.  It is not possible to specify both types in the SDB format.
> This is one of the many fundamental flaws with SDB.  If you want better debug
> info, you have to use a different debug info format.  Since we can only
> represent one of these types, we should choose the one that makes gdb (and
> the native debugger) work best, and as far as I know, in this case, it is
> the promoted type `int'.

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.

Philippe