This is the mail archive of the archer@sourceware.org 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 ideas


> -> linux_nat_has_pending_sigint -> maybe_clear_ignore_sigint
> 
> http://sourceware.org/ml/gdb-patches/2005-04/msg00041.html
> 
> without it single CTRL-C gets reported for each process in a process group:

That is a correct and true report of what actually happens.  When you hit
C-c, each process in the process group does get a SIGINT and can handle it
independently.  I can't see wanting anything different for the test case
you show (except perhaps more sophisticated 'handle' commands to say I
wanted something more automagic).

The old mailing list thread you cited talks about the LinuxThreads case.
That's a case where the user perception of the program is that it's one
process with multiple threads, but the implementation has the kernel
semantics of many processes that just share the memory address space and
not much else.  That is quite a different situation than several normal
processes in a process group, as we encounter today (where the only kind of
multithreadedness is NPTL).

> > The point of using waitid is that you can see the new si_tgid field, and
> > hence receive both the thread-specific ID and the process-wide TGID for a
> > tracee that you haven't seen before.
> 
> GDB has linux_proc_get_tgid :-) but only to workaround nptl/5983 fixed by you,
> again reading "/proc/%d/status", for "Tgid".

Sure, there is old stuff.  The point of the si_tgid/waitid hack is to
relieve GDB of the need to do that ungainly open+read+parse work when just
dealing with the "new normal" of low-overhead multithread tracing.  What
you need to tell us is whether it is worthwhile to GDB that we add such
features or not.  If it's not a problem for GDB to use the crufty old /proc
mechanism when faced with the wait result of an unknown ID, then we won't
bother with the si_tgid changes in the kernel.  I had been thinking it
would be another scaling constraint and/or unpleasant corner case to have
to deal with that.  Perhaps it's really not a problem, since you only have
to do that work when a thread actually stops and thus everything is slowing
down anyway.  You tell us.

> PTRACE_O_INHERIT cannot be used for fork/vfork with `set detach-on-fork on'
> (the default mode, so that it is not multi-inferior) as GDB needs to remove
> software breakpoints.  But the goal is multi-inferior `set detach-on-fork off'
> anyway so in that mode PTRACE_O_INHERIT could apply even for fork/vfork.

Ok.  So that sounds like PTRACE_O_INHERIT as I described (applying to all
kinds of clones) is indeed the useful way to define the feature.

> `stopped_pids' tracks tasks which got reported as stopped before the parent's
> PTRACE_EVENT_{CLONE,FORK,VFORK} has been seen.
> 
> With multi-inferior `set detach-on-fork off', with no
> PTRACE_O_TRACE{CLONE,FORK,VFORK} and using PTRACE_O_INHERIT it could apply for
> both clones and forks/vforks, couldn't it?  There is no longer any need to
> track `stopped_pids'.

This seems to be a question about gdb internals and I can't answer it for
you.  In the status quo, the only case where you can see an unexpected
tracee is the race between parent and new child reporting, when the child
reports first.  There you can immediately do another blocking wait and be
sure that you will see the parent report soon and can make the correlation.

With the proposed new situation, you could see an unexpected new tracee
that is a fork/vfork (or any non-CLONE_THREAD clone) and have no reliable
way whatsoever to know where that new child came from.  You can attempt to
look up its ppid in /proc/pid/status and correlate that with some other
tracee, but it's possible that its ppid is already 1 when the parent has
died, so you won't know.  (It's also possible that its ppid is another
tracee you don't yet know about, so you'd have to iterate on the /proc
lookup to follow the lineage back to one you know.)

The question is, do you care?  I am guessing that you have to care, because
you need to know what known tracee was the proximate ancestor to know what
breakpoints are already inserted in the new child.  But it's for you to
tell us.

> PTRACE_O_TRACEEXEC still needs to stop the inferior as GDB needs to reinsert
> all the software breakpoints to their newly computed addresses.

Indeed.  The PTRACE_O_INHERIT idea only attempts to relieve the need to use
PTRACE_O_TRACE{CLONE,FORK,VFORK} when you don't want those events to be
reported with stops.  It has no bearing on other kinds of event stops you
do want.


Thanks,
Roland


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