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.