[comp.unix.wizards] any comp.dbx.wizards out there?

jlh@loral.UUCP (The Happy Hacker) (12/15/87)

From dbx, when 'foo_type' is a typedef'd structure, and foo is a foo_type,
if I tell dbx to print foo, where does it gets it's information as to
where the fields are in foo?  To be more specific, I've got the following:

typedef struct {
	int	array1[BIG_NUM];
	char	a, b, c, d, e;
	int	array2{BIG_NUM];
} foo_type;

foo_type foo;

So now lets say I want to see what a, b, c, d, and e are, so I say
'print foo'.  Dbx prints out array1, the stuff I want to see, then array2.
This is all well and good except that I want to go get coffee while
foo is being printed and the info of interest scrolled off the screen by
array2.  So I change foo_type to put array2 right after array1 and recompile
everything.  Type 'print foo'.  Hey, guess what?  It still thinks
the structure has a-e sandwiched between the 2 arrays.  But by looking
at the data it was stored in the structure at the right place.  For
example, if all entries of both arrays were 0 and a-e were 1, then
'print foo' it says array1 is all 0's, which is correct, a-e are 0,
which is not correct, then all of array2 is 0 except for the last 5
entries, which are 1.  The correct answer is that array1 is all
zeros, array2 is all zeros, and a-e are all 1.

If I say 'whatis foo' and 'whatis foo_type' I get the correct
answers.  If I say 'print foo.e' I get the correct answer.  It's only
when I try to print out the entire structure the wierdness shows up.
I've deleted all the objects and recompiled everything, I've checked
the include file with foo typedef'ed back into RCS and tried again, to
no avail.  Note that foo_type is a stripped down example, the real
structure has several large arrays with from between 512 and 2048
entries apiece in them.  The data of interest (a to e) is actually
about 15 individual fields.  Any ideas out there?

While I'm on the subject, I find that a lot of the time I just want
to see array1[10] to array1[15].  Short of either typeing out
print commands for each of these fields, or typeing out the entire
array, is there a way to just print part of a large array from dbx with
one print command?  Thanks.


							Jim


Jim Harkins 
Loral Instrumentation, San Diego
{ucbvax, ittvax!dcdwest, akgua, decvax, ihnp4}!sdcsvax!sdcc6!loral!jlh

"The opinions expressed in this article accurately reflect those held
by Ronald Reagan, George Bush, Al Haig, and Jerry Fallwell.  But you
already knew that, didn't you"

-- 
Jim Harkins 
Loral Instrumentation, San Diego
{ucbvax, ittvax!dcdwest, akgua, decvax, ihnp4}!sdcsvax!sdcc6!loral!jlh

feldman%vger@gswd-vms.Gould.COM (Mike Feldman) (01/07/88)

/*
 * Question:
 * From dbx, when 'foo_type' is a typedef'd structure, and foo is a foo_type,
 * if I tell dbx to print foo, where does it gets it's information as to
 * where the fields are in foo?
 *
 * Answer:
 * dbx gets its information from the compiler through the .stab information
 * that is generated when you specify the "-g" option.  For example, in the
 * following test program:
 */

#define BIG_NUM	8

typedef struct {
	int	array1[BIG_NUM];
	char	a, b, c, d, e;
	int	array2[BIG_NUM];
} foo_type;

foo_type foo;

main(argc,argv)
 int argc;
 char *argv[];
{
	printf("hello world\n");
}

/*
 * The following .stab info is generated for "foo_type" and "foo" (this can
 * be seen by running "nm -pa" on the executable file generated by the
 * compiler.  The following is a truncated list.)
 *
 * 00410410 - 00 0000    SO t3.c
 * 00000000 - 00 0000  LSYM int:t1=r1;-2147483648;2147483647;
 * 00000000 - 00 0000  LSYM char:t2=r2;0;127;
 * 00000000 - 00 0000  LSYM long:t3=r1;-2147483648;2147483647;
 * 00000000 - 00 0000  LSYM short:t4=r1;-32768;32767;
 * 00000000 - 00 0000  LSYM unsigned char:t5=r1;0;255;
 * 00000000 - 00 0000  LSYM unsigned short:t6=r1;0;65535;
 * 00000000 - 00 0000  LSYM unsigned long:t7=r1;0;-1;
 * 00000000 - 00 0000  LSYM unsigned int:t8=r1;0;-1;
 * 00000000 - 00 0000  LSYM float:t9=r1;4;0;
 * 00000000 - 00 0000  LSYM double:t10=r1;8;0;
 * 00000000 - 00 0000  LSYM void:t11=11
 * 00000000 - 00 0000  LSYM ???:t12=1
 * 00000000 - 00 0048  LSYM foo_type:t13=s72array1:14=ar1;0;7;1,0,256;a:2,256,8;b:2,264,8;c:2,272,8;d:2,280,8;e:2,288,8;array2:15=ar1;0;7;1,320,256;;
 * 00000000 - 00 0048  GSYM foo:G13
 * 00410410 - 00 0004   FUN main:F1
 * 00000060 - 00 0004  PSYM argc:p1
 * 00000064 - 00 0001  PSYM argv:p16=*17=*2
 * 00410410 - 00 000e SLINE 
 * 00410418 - 00 000f SLINE 
 * 00410434 - 00 0010 SLINE 
 * 00410218  t -lg
 *
 * The "foo_type" and "foo" stabs can be broken down as (read from
 * bottom to top):
 *
 * 00000000 - 00 0048  LSYM
   ^        ^ ^  ^     ^
   |        | |  |     |
   |        | |  |     - local symbol (from n_type field)
   |        | |  - n_desc field
   |        | - n_other field
   |        - says we have .stab info used by dbx
   - n_value field, which is the value of the symbol or its size if it's
     a common or stab offset.

 * foo_type:t13=s72
   ^        ^^ ^^^
   |        || |||
   |        || ||- size of record is 72 bytes
   |        || |- there's a record being constructed
   |        || - type definition to follow
   |        |- number associated with this new type
   |        - says this is the creation of a new type
   - name of symbol

 *   array1:14=ar1;0;7;1,0,256;
     ^      ^ ^^^^ ^ ^ ^ ^ ^
     |      | |||| | | | | |
     |      | |||| | | | | - length (in bits) of this field
     |      | |||| | | | - bit offset of this field in the record
     |      | |||| | | - the array type is type 1 (int)
     |      | |||| | - upper bound
     |      | |||| - lower bound
     |      | |||- the subscript type is type 1 (int)
     |      | ||- it has a subscript
     |      | |- this is an array
     |      | - type definition to follow
     |      - the type of this field is type 14
     - the name of this field in the record

 *   a:2,256,8;
     ^ ^ ^   ^
     | | |   |
     | | |   - length (in bits) of this field
     | | - bit offset of this field in the record
     | - type associated with this field is type 2 (char)
     - name of this field in the record
 *
 * (the next 5 elements of the record are just variations of the first 2...)
 *
 *   b:2,264,8;
 *   c:2,272,8;
 *   d:2,280,8;
 *   e:2,288,8;
 *   array2:15=ar1;0;7;1,320,256;;
 *
 * 00000000 - 00 0048  GSYM
   ^        ^ ^  ^     ^
   |        | |  |     |
   |        | |  |     - global symbol (from n_type field)
   |        | |  - n_desc field
   |        | - n_other field
   |        - says we have .stab info used by dbx
   - n_value field, which is the value of the symbol or its size if it's
     a common or stab offset.
 * foo:G13
   ^   ^^
   |   ||
   |   |- type of this symbol is 13 (foo_type)
   |   - this symbol is an external variable
   - name of symbol
 *
 */

/*
 * Question:
 * While I'm on the subject, I find that a lot of the time I just want
 * to see array1[10] to array1[15].  Short of either typeing out
 * print commands for each of these fields, or typeing out the entire
 * array, is there a way to just print part of a large array from dbx with
 * one print command?  Thanks.
 *
 * Answer:
 * Aliases come in handy for these problems.  You could do several
 * things here:
 * (1) alias foo 'print foo.array1[10], foo.array1[11], ..., foo.array1[15]'
 *       You could add this alias to your .dbxinit file and have it
 *       get initialized every time you enter dbx.  This will give
 *       you all the elements of the array you specify.
 *
 * (2) alias foo  'foo0 ; foo3 ; foo6'
 *     alias foo0 'print foo.array1[0], foo.array1[1], foo.array1[2]'
 *     alias foo3 'print foo.array1[3], foo.array1[4], foo.array1[5]'
 *     alias foo6 'print foo.array1[6], foo.array1[7]'
 *       Same thing but with different granularity.
 *
 * (3) alias foo(x) 'print foo.array1[x]'
 *       This is better when you're looking at different elements
 *       that may be scattered throughout the array.  To get foo.array1[2],
 *       just say "foo(2)".
 *
 * We've also been thinking of making an enhancement to allow you
 * to specify "foo.array1[0..4]".  However, it has to wait in the
 * enhancement queue, which follows closely behind the problem
 * queue.  (Whatever happened to "it's the thought that counts"...)
 *
 * Gerry Cullen
 * gcullen@midas
 * Gould Computer Systems, Inc.
 * Ft. Lauderdale, Florida
 */