Subject: Re: Compiling gdb 4.14
To: None <tholo@sigmasoft.com>
From: Charles M. Hannum <mycroft@ai.mit.edu>
List: current-users
Date: 07/01/1995 21:36:32
   > PT_READ_U and PT_WRITE_U are the 'old way' of getting and setting
   > process registers.  not particularly 'clean,' nor particularly secure.
   >
   > the new way is with PT_GETREGS and PT_SETREGS (and PT_{GET,SET}FPREGS).

   Agreed.  But you still need PT_{READ,WRITE}_U to deal with signal
   handlers and stuff, no?

In a word: Huh?

The old PT_READ_U and PT_WRITE_U certainly didn't do this, and there's
no code in GDB to support it that I'm aware of.  Furthermore, this
information is *not* kept in struct user; it's kept in another
per-process structure that hangs off struct proc.

   > Adding PT_READ_U and PT_WRITE_U to ptrace.h won't help; nothing will
   > actually be implementing them, anyway.

   But perhaps they should be implemented?

Certainly not.

   > you should change infptrace.c to use the new functions.  (If you do
   > so, you might mail the list with a copy of the diffs.)

   What functions are there to see which signal handlers a traced process
   have installed?

Currently, none.

   How can a debugger detect wether or not a signal has
   occured?

The debugger always get a SIGCHLD telling it that the child got a
signal, and has the option of passing through the signal when it does
a PT_CONTINUE, PT_KILL, or PT_DETACH, or of simply ignoring it.