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


	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'.

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'.

Note however that if a parameter lives someplace other than where it was
passed, then we can emit a second debug info record which uses the user
declared type.  This in fact is what happens in this case if you compile
without optimization.  If you look at the .s file, you can see that there are
two debug info records, the first which says the passed value has type int,
and the second which says the parameter after homing has type char.  The
example should work exactly as you expect without optimization, but probably
can not be made to work as you expect with optimization.

I haven't tried it, but I suspect that if you override the PROMOTE_PROTOTYPES
definition in m68k.h, then you will find that gcc uses `char' for a prototyped
function and `int' for an old-style function declaration.  This however
gives you a subtle ABI change, so it might result in some undesirable
incompatibilities.  I believe that the code you refered to exists to handle
this case.

Jim