------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <968.804650644.1@gandalf.sigmasoft.com>

>    > 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.
> 
>    Oops.  Should have read it a bit more carefully, that way I, too, would see
>    that proc has a p_sigacts pointing into user's u_sigacts...
> 
> Actually, you're right.  B-)

Oh wow! :)

> I still don't know of any code in GDB to support that, though, and we
> could just as easily provide another ptrace(2) function to get that
> info.

But gdb does know which signals the process has trapped, does it not?  Or
is that something only "ups" seems to know about?  And yes, that is the
_only_ thing "ups" needs from the user structure now that we have 
PT_{GET,SET}REGS.  We are missing PT_{GET,SET}FPREGS too, btw.

> Another thing (suggested by Roland) that would be useful is to have a
> set of signals which are passed directly to the child without telling
> the debugger about it.  This would be particularly useful for programs
> that use SIGIO (like Emacs).

Ie. a way to say that there should not be a trap into the debugger on
some specified signals...  I can certainly see how that might be useful.

> Did I hear you volunteer?

Err..  I am not sure I want to do that level of kernel hacking just
yet...

Thorsten

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <968.804650644.2@gandalf.sigmasoft.com>
Content-Description: Signature

--
Thorsten Lockert        | postmaster@sigmasoft.com | Universe, n.:
1262 Golden Gate Avenue | hostmaster@sigmasoft.com |         The problem.
San Francisco, CA 94115 | tholo@sigmasoft.com      |

------- =_aaaaaaaaaa0--