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] |
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