This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ptrace improvement: PTRACE_O_INHERIT

> (a) GDB tracks separately  threads (libpthread-managed) and LWPs (TIDs).
>     (So the libthread_db TD_DEATH notification is offtopic for this mail.)

Then the scalability issues with thread creation and death will not be
algorithmically improved (only halved at best) by making the automatic
kernel notifications less eager.  GDB will have to stop enabling the
libthread_db event breakpoints for thread creation and death before the
stuff we are discussing really matters.

> (b) For LWPs it does not use PTRACE_O_TRACEEXIT.
>     /* Do not enable PTRACE_O_TRACEEXIT until GDB is more prepared to support
>        read-only process state.  */
>     (I do not know more regarding this comment.)

I don't know from the GDB side what the details are, but I might be able to
offer a little insight here.  At the PTRACE_EVENT_EXIT stop, you have what
looks like any other ptrace stop, where you can fetch and set the registers
and so forth.  But the tracee thread has already started exiting and it
will never return to user mode, no matter what you do.  So it's impossible
to do "jump", an inferior function call, etc.--for changing registers to
have any kind of effect (except on the contents of a core dump initiated by
another thread).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]