sean%fiamass.ie@pucc.princeton.edu (Sean Mc grath) (01/23/91)
I an having trouble with dbx on a SPARC 4-65 running SUN OS 4.1. We use
16 bit unsigned integer datatype called UINT16. We #define it to suit the
machine we are running on. Unfortunately, when UINT16s are passed as
paramaters on the stack dbx gets confused. Here is a demo of the problem:
------ CODE starts here --------
#define UINT16 unsigned short
fred(a,b)
UINT16 a,b;
{ a = b; }
main()
{
fred (15,78);
}
------ CODE ends here ---------
I compile this with debugging on using
cc -g test.c
I run up dbx :-
dbx a.out
I set a breakpoint in fred
stop in fred
Run it
run
It stops in fred. So I print a
print a
Answer 0 - incorrect
I tried
print (UINT)a
Answer 0 - incorrect
By the way, the 386i we have gets it right. I think it must be to do with
dbx looking at the wrong 16 bits of the 32 bit integer that is stuffed on
the stack for both a and b. Any ideas???
Sean Mc Grath (sean@fiamass.ie)
12 Clarinda Park North
Dun Laoghaire
Co. Dublin
gnu@toad.com (03/19/91)
The Sun C compiler before SunOS 4.1 would output incorrect debug information about parameters shorter than an "int". The debug information claimed that the parameter was a short at offset XXX. However the parameter really was an int at offset XXX. If you wanted to treat it like a short, you would have to look at offset XXX+2. DBX apparently was able to deal with that somehow, and a kludge was added to gdb to also deal with it. They fixed the compiler in SunOS 4.1, so it now claims the short parameter is at offset XXX+2, where it really is. Perhaps DBX was not changed correspondingly. GDB can be changed to handle this by defining BELIEVE_PCC_PROMOTION in the config file (m-sun*.h). I changed GDB to handle both 4.0.x and 4.1 by offsetting the symbol if it points at an int-aligned location, and leaving it alone if it appears to have already been offset to where the parameter really is. This lets you run the same GDB binary on SunOS 4.0.x and 4.1 machines. The change (in dbxread.c) will be in some future GDB release. John Gilmore