PROBLEM:  (CLD HPAQ5131P)    (Patch ID: OSF440-101)
********
PROBLEM:
This patch fixes a problem in viewing a variable subrange parameter from
a pascal module while using dbx.  While trying to view a particular parameter
type, dbx truncates the address, and gives the error

        "can't read from process (address 0xffff)"  

The following Pascal program is an example that demonstrates the problem.

        PROGRAM dbx_word_err(output);
        TYPE
           word = [WORD] 0..65535;

        VAR
           chn : word;

        PROCEDURE test(VAR chan: word);
        VAR
           blah : word;

        BEGIN

           blah := 5;
           chan := blah + 100;
        END;

        BEGIN
           test(chn);
        END.

The following dbx session illustrates the problem:

        dbx dbx_work_err

        dbx version 3.11.10
        Type 'help' for help.

        DBX_WORD_ERR:  20  test(chn);
        (dbx) stop in test
        [2] stop in TEST
        (dbx) r
        [2] stopped at   [TEST:15 ,0x120001ccc]         blah := 5;
        (dbx) p chan

        can't read from process (address 0xfd00)


PROBLEM:  (52718, 74111, 61261) (PATCH ID: OSF440-391)
********


Problem 1:  Dbx stack trace is incomplete.
In certain cases, dbx's 'where' command did not produce a complete stack
trace.  This was seen when debugging at the assembly level and using the 
'stepi' command to step into a routine, or when there is a fault in some
library routines.  The following shows some instances of the problem.

Stepping into a routine with stepi ('si'), 
Getting a stack trace ('where' or 't')
Attempt to 'return'

>*[main:68, 0x1200018b0]        ldq     r27, -32568(gp)
(dbx) ni
>*[main:68, 0x1200018b4]        jsr     r26, (r27), 0x120005e60
(dbx) si
>*[_OtsMove, 0x3ff800d5e60]     amask   0x1, r19
(dbx) t
>  0 _OtsMove(0x3ff800d5bd0, 0x4, 0x120001850, 0x3, 0x4) [0x3ff800d5e60]
(dbx) return

no place to return to
(dbx) up
(dbx) t
>  0 _OtsMove(0x3ff800d5bd0, 0x4, 0x120001850, 0x3, 0x4) [0x3ff800d5e60]


Stepping into a routine until the stack is correct

>*[main:68, 0x1200018cc]        ldq     r21, 40(r8)
(dbx) ni
>*[main:68, 0x1200018d0]        bsr     r26, recurse+0x8(line 29)
(dbx) si
>*[recurse:29, 0x120001638]     ldq     r28, -16448(sp)
(dbx) t
>  0 recurse(inbox = (...)) ["crashit.c":29, 0x120001638]
(dbx) ni
>*[recurse:29, 0x12000163c]     ldq     r28, -4096(sp)
(dbx) ni
>*[recurse:29, 0x120001640]     ldq     r28, -12256(sp)
(dbx) ni
>*[recurse:29, 0x120001644]     lda     sp, -16448(sp)
(dbx) ni
>*[recurse:29, 0x120001648]     stq     r26, 8144(sp)
(dbx) t
>  0 recurse(inbox = (...)) ["crashit.c":29, 0x120001648]
(dbx) ni
>*[recurse:29, 0x12000164c]     stq     r16, 16400(sp)
(dbx) t
>  0 recurse(inbox = (...)) ["crashit.c":29, 0x12000164c]
   1 main(argc = 3, argv = 0x11ffffce8) ["crashit.c":68, 0x1200018d0]




Problem 2:  Dbx cannot set a variable after viewing a non-local variable:
Dbx has several methods of looking for variables.  If the variable is not 
found in the current routine, active procedures on the stack are searched,
and then global variables are searched.  When dbx searched up the stack for
the variable, it failed to reset an internal pointer and the assignment to a
local variable failed.  

main:  52  if (argc < 3) {
(dbx) stop in justtryme
[2] stop in justtryme
(dbx) r 0 3
[2] stopped at   [justtryme:21 ,0x1200015d4]    deepend = levels;
(dbx) n
  [justtryme:23 ,0x1200015d8]   printf("Cpu %d going down, stack about %d levels
 deep\n", cpu, deepend);
(dbx) p iter    /* A variable local to the main routine
3
(dbx) assign deepend = 10
10
(dbx) p deepend
3
(dbx) q

Problem 3:  Dbx receives signal 66 on vfork:

When debugging a program that executes a vfork, dbx exhibited this:

dbx version 3.11.10
Type 'help' for help.

main:  11  signal( SIGCHLD, handler);
(dbx) r
signal [signal 66] at >*[__vfork, 0x3ff800e7968]    beq     r19, 0x3ff800e7980
(dbx)

The correct behaviour follows:

main:  11  signal( SIGCHLD, handler);
(dbx) r
New child attached.  Use switch to gain access to process 5774
child: 5774
(dbx)

PROBLEM: (TKTBC0129, 74469) (PATCH ID: OSF440-565)
********
This patch fixes problems with the dbx kernel debug option
when used on kernel core files from wildfire and other
large memory systems.