Conference turris::debug

1833.0. "Question on exe$read_process()" by KMOOSE::CMCCUTCHEON (Charlie McCutcheon) Mon Feb 03 1997 17:35

The following is a question from ACT, who is writing Ada '95 for OpenVMS
Alpha V7.0.  I'll admit that I know little about the issue, but am hoping
that Debug folk can answer this, if they use this routine.  If not, any
help that could be given would be appreciated.  (gdb is a "rival" debugger
with many Ada '95 specific features...)

I sent mail to Mary Dieter on this (and have gotten no answer ;-)

Please mail me if you have any help.

Charlie

From:	US2RMC::"rupp@gnat.com" "Douglas B. Rupp"  3-FEB-1997 00:20:33.79
To:	begin::cmccutcheon (Charlie McC)
CC:	rupp@gnat.com (Douglas B. Rupp)
Subj:	read_process says nonexistent process

I really need this function for gdb.  Of the 3 recent problems
I've reported, this is by far the most urgent.  Any ideas?

I've tried everything I can think of to get this to work.  I found
the sources to exe$read_process() on the cdrom and studied them and read
all the documentation I can find.  I'm about ready to conclude it's just
plain broken.

Here's a test program, before compiling you will need to change the ipid
variable to some known process id.  For me, it always returns:
%SYSTEM-W-NONEXPR, nonexistent process.  I even put in a loop a try
all pids between 0 and 100000, same result.

You will need the cmkrnl privelege, and you must link with /sysexe.

extern long exe$read_process ();

main ()
{
  unsigned long ipid = 0x99;               /* some known process id */
  unsigned long buffer_size = 8;           /* 8 bytes */
  unsigned long target_address = 0;        /* Register 0 */
  unsigned long local_address [2] = {0,0}; /* Storage for 8 bytes */
  unsigned long target_address_type = 2;   /* Read registers */
  unsigned long ast_counter_address;       /* Some address */
  unsigned long status;
  int i;

  unsigned long args [7];

  args [0] = 6;
  args [1] = ipid;
  args [2] = buffer_size;
  args [3] = target_address;
  args [4] = (unsigned long) &local_address [0];
  args [5] = target_address_type;
  args [6] = (unsigned long) &ast_counter_address;

  status = sys$cmkrnl (exe$read_process, args);

  if ((status & 1) != 1) 
    lib$signal (status);

  printf ("data: %d,%d\n", local_address[0], local_address[1]);
}

$ cc test2
$ link/sysexe test2
$ run test2
%SYSTEM-W-NONEXPR, nonexistent process
%TRACE-W-TRACEBACK, symbolic stack dump follows
  image    module    routine             line      rel PC           abs PC
 TEST2  TEST2  main                        27 0000000000000108 0000000000020108
 TEST2  TEST2  __main                       0 0000000000000054 0000000000020054
                                            0 FFFFFFFF81D14914 FFFFFFFF81D14914
data: 0,0


% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail13.digital.com by us2rmc.zko.dec.com (5.65/rmc-22feb94) id
AA19633; Mon, 3 Feb 97 00:14:31 -0500
% Received: from nile.gnat.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id
AAA23987; Mon, 3 Feb 1997 00:05:28 -0500 (EST)
% Received: by nile.gnat.com (5.0/1.20) id AA24306; Sun, 2 Feb 97 23:58:10 EST
% From: rupp@gnat.com (Douglas B. Rupp)
% Message-Id: <9702030458.AA24306@nile.gnat.com>
% Subject: read_process says nonexistent process
% To: begin::cmccutcheon (Charlie McC)
% Date: Sun, 2 Feb 1997 23:58:09 -0500 (EST)
% Cc: rupp@gnat.com (Douglas B. Rupp)
% X-Mailer: ELM [version 2.4 PL25]
% Mime-Version: 1.0
% Content-Type: text/plain; charset=US-ASCII
% Content-Transfer-Encoding: 7bit

   Your customer is aware that the Internal PID or IPID is different from
   the External PID or EPID, and it is the EPID that is normally refered
   to as the PID...
   
   exe$read_process() is a (semi-documented) kernel-mode routine and
   is not likely accessable via the standard debugger.

   Try a "SHOW KEYWORD/FULL EXE$READ_PROCESS" over in NOTED::HACKERS,
   and see 1371.* in VAXAXP::NOTES$ARCHIVE:ALPHANOTES_V1 -- you'll
   get pointers to other documentation, too -- including to the OpenVMS
   documentation for this particular routine.

   Also try a "SHOW KEYWORD/FULL  EXE_STD$CVT_XPID_TO_XXX over there,
   too -- you'll get pointers to the PID-related conversion routines.

Right.  OpenVMS DEBUG, as of today, is a strictly user-mode application.  It
does not make use of any privleged functions/services like exe$read_process.

In the OpenVMS debugger's default or multiprocess configuration, there are
2 (soon to be 3...the GUI and main are moving into the client/server separate
process domain) debugger processes, main and kernel.  Debug main runs in its
own separate process and in its multiprocess mode can connect to up to 8
debug kernels.  Debug kernel runs in the user application process and thus
has full access to the user application's memory, registers, stack, etc.
The only special feature that this debugger uses, in this regard, is the
ability to signal from one process to another, i.e. cross process signal.
This allows debugger main to interrupt an off and running user process thus
giving that process's debug kernel control and thus allowing the debugger
main and kernel images to go about their business, i.e. examines, deposits,
manipulate events like breakpoints, etc.

At any rate, we will be taking this off line...i.e., we will be communicating
directly with ACT.

Lon