SDB problems

[utzoo!decvax!duke!unc!mcnc!rlgvax!guy]

The "sdb" and "pcc" supplied with 4.1BSD (and probably, therefore, the ones
supplied with System III) have several very serious defects in the organization
of the symbolic-debugger symbol table.

The first is that register parameters appear in the symbol table twice; once
as the automatic variable on the stack and once as the register variable.
The register variable appears first, followed by the automatic.  Unfortunately,
for what seem like sensible reasons, "sdb" searches the symbol table in
reverse order; thus, it always sees the automatic variable.  As such, any
attempt to print the value of such a parameter will always give its value
at the time the routine was entered.

The second is that structure member names are treated as being global.  All
very well and good, except that in UNIX 3.0 the C language was changed so that
structure member names were NOT global.  Two structures can have members with
the same name, but different types and/or offsets.  This means that in a
construct like p->member, "p" MUST be a pointer to a structure which contains
a member called "member"; the type of the pointer "p" is required to determine
which "member" to use.  Unfortunately, the symbol table does not record the
various structure types as units, and therefore cannot declare a given var-
iable as being "struct foo".  As such, foo.member cannot be disambiguated by
"sdb", and which "member" you get is pot luck.

The third is that length information is not properly handled; this means
that if you declare

struct foo *p;

any reference to "p[0]" will work, but a reference to "p[1]" will refer to
the object n bytes after p[0], where n is the number of bytes in a pointer.
This goes along with the (documented) non-support of multi-dimensional arrays.

A look at the documentation on the UNIX 5.0 "sdb" indicates that multi-
dimensional arrays are supported, so the third problem may have been corrected.
I can't determine from a quick reading whether the first or second problem
has been corrected.

I'm sure all the above could be fixed (and may have been, either by somebody
out there or in UNIX 5.0).  Unfortunately, it looks like more work to fix than
I can find time to do right now; has anybody fixed them?  Does anybody know
if 5.0 fixes them?

					Guy Harris
					RLG Corporation
					...!decvax!mcnc!rlgvax!guy